Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Estudo do escopo da auditoria DeFi: o que significa o número de perdas de 94%
Nas finanças descentralizadas, “auditado” é frequentemente apresentado como um veredicto sobre um projecto inteiro. Na prática, uma auditoria geralmente cobre códigos, componentes e versões nomeados em um determinado momento. Qualquer coisa adicionada, excluída ou operada em torno desse limite pode ter um nível diferente de garantia.
Uma nova pré-impressão dá um número a essa lacuna. Pesquisadores afiliados à empresa de segurança ack3 e à Universidade Técnica Tcheca em Praga examinaram 135 incidentes relatados no primeiro semestre de 2026com US$ 939,86 milhões em perdas atribuídas. Eles encontraram auditorias públicas pré-incidentes identificáveis para 68 incidentes.
Dentro desse subconjunto de 68 incidentes, os autores classificaram 46 caminhos de ataque como fora de qualquer escopo de auditoria que puderam identificar, 20 como dentro de pelo menos um escopo e dois como não resolvidos. O grupo fora do escopo representou 67,6% dos incidentes, mas 94,4% das perdas relatadas.
Essa percentagem surpreendente não é uma estimativa da eficácia da auditoria ou uma prova de que os limites de uma auditoria causaram uma perda. Descreve a distribuição das perdas em um conjunto selecionado de incidentes relatados. Dois grandes casos também o dominam: depois de excluir US$ 292 milhões no Kelp DAO e US$ 285 milhões no Drift Protocol, a parcela fora do escopo cai para 72,1% das perdas no mesmo subconjunto de incidentes auditados.
Mesmo com esses limites, o estudo expõe um problema básico de garantia. Um projeto pode dizer com sinceridade que foi auditado, deixando os usuários incapazes de saber se o sistema ativo, o caminho que contém seus fundos e os controles em torno dele foram revisados.
O que os dados realmente mostram
O conjunto de dados ack3 cobre incidentes de 1º de janeiro a 29 de junho. Seus autores classificaram 122 como confirmados e 13 como prováveis. Do conjunto completo, 35 não tinham nenhuma auditoria identificada e 32 tinham um histórico de auditoria desconhecido, portanto nenhum grupo aparece no cálculo do escopo de 68 incidentes.
Para esse grupo de 68 incidentes, os incidentes fora do âmbito representaram 680,97 milhões de dólares dos 721,24 milhões de dólares em perdas reportadas, produzindo o valor de 94,4%. A remoção do Kelp DAO e do Drift Protocol deixou US$ 103,97 milhões de US$ 144,24 milhões fora do escopo, ou 72,1%. O livro-razão legível por máquina reproduz as contagens de baldes e somas de perdas.
Os rótulos de dentro ou de fora continuam sendo os julgamentos dos pesquisadores sobre as evidências públicas. Eles pesquisaram arquivos de projetos e auditores, localizaram relatórios pré-incidentes e compararam os possíveis caminhos de ataque com códigos revisados, versões e exclusões. O trabalho é uma pré-impressão de seis páginas produzida pela editora do conjunto de dados, e dois autores são afiliados à ack3, que vende análises de segurança.
O estudo também carece de um grupo de comparação inexplorado e de uma medida de quanto tempo cada sistema ficou exposto. Ele não pode estabelecer se os protocolos auditados são mais seguros em geral, estimar a probabilidade de incidentes ou mostrar que a saída do escopo causou cada perda. Auditorias não divulgadas e incidentes privados podem estar faltando, enquanto os números de perdas relatados não são perfeitamente comparáveis.
O estudo apoia, portanto, uma conclusão limitada: o histórico de auditoria e o âmbito da auditoria são variáveis diferentes. Um contrato inteligente revisado não confere automaticamente a mesma garantia a uma atualização, chave privilegiada, front-end, retransmissor, oracle, serviço de nuvem ou processo de resposta a incidentes.
Dois incidentes ocorridos em Agosto ilustram essa distinção de maneiras diferentes. A ICON Network fornece um exemplo direto de falha de código revisado na fronteira entre duas verificações. O incidente de agosto fornece um caso contrastante porque a evidência de auditoria disponível ainda não pode ser vinculada ao caminho de tempo de execução relatado.
Na exploração de repetição da ICON Network em 27 de agosto, duas partes de um caminho de retirada interpretaram a mesma mensagem de maneira diferente.
De acordo com o Post-mortem da ICON Foundation em 30 de agostoum contrato de migração usou os bits altos do número de série de uma mensagem de retirada para decidir se ela era única. A assinatura criptográfica cobriu apenas os 256 bits. Ao alterar os bits altos não assinados, um invasor reenviou duas mensagens de retirada assinadas legitimamente 1.492 vezes em cerca de 20 minutos. ICON disse que 1.490 ligações foram bem-sucedidas.
O limite auditado ICON foi perdido
Os replays liberaram 119,866 milhões de ICX e 531.600 bilhões de dólares. No momento da análise, a ICON estimou o prejuízo líquido confirmado em cerca de 150,2 ETH mais 31.204 USDC. Ele disse que 531.600 bilhões de dólares e 1,366 milhão de SODA foram recuperados e que os depósitos, saldos e posições dos usuários não foram afetados.
A ICON disse que o contrato de migração foi submetido a uma auditoria externa e que as recomendações foram implementadas, incluindo alterações na mesma área. Ele também disse que a lógica do relé relevante recebeu uma revisão dedicada. O Arquivo de auditoria SODAX lista oito relatórios em diferentes componentes, incluindo um Auditoria de retransmissão de novembro de 2025.
No entanto, a autópsia disse que a incompatibilidade precisa entre a verificação de exclusividade e o valor assinado estava fora dessas descobertas. Um selo em nível de projeto não poderia dizer ao usuário se ambas as extremidades do caminho de retirada concordavam com o que tornava uma mensagem única.
O cronograma de resposta adiciona um segundo tipo de limite. O primeiro alerta automatizado do ICON foi disparado às 02h08 UTC, cerca de sete minutos após o início da exploração. A equipe abriu uma investigação por volta das 03h40, interrompeu o contrato afetado às 03h53 e interrompeu a rede às 06h18:54.
A ICON atribuiu o intervalo de aproximadamente 90 minutos entre o primeiro alerta e uma resposta completa ao incidente ao ajuste do alerta. A classe de alerta produziu falsos positivos durante incidentes de conectividade não relacionados e não chamou a equipe de plantão com a gravidade necessária. A fundação disse que planejou um gatilho de desligamento automático, limites mais baixos de disjuntores e uma revisão de acompanhamento focada na exclusividade das mensagens e nas proteções de repetição.
Esses controles não substituem uma auditoria. Fornecem provas para uma questão diferente: quando a prevenção falha, com que rapidez a detecção pode transformar-se em contenção?
| Garantia pública | A pergunta que os usuários ainda precisam responder |
|---|---|
| “Auditado” | Qual repositório, commit, endereço implantado e componente foram revisados? |
| “Descobertas corrigidas” | As correções foram implementadas e o que mudou depois? |
| “Monitorado” | Quais alertas chamam um ser humano ou interrompem o caminho afetado automaticamente? |
| “Fundos recuperados” | Quais ativos estão confirmados como recuperados, congelados, expostos ou ainda sob investigação? |
eu mesmo mostra por que a garantia deve permanecer atualizada
meu incidente de agosto testa o argumento de outra direção. Seu registro público descreve um comprometimento do tempo de execução e uma recuperação controlada, mas não fornece evidências suficientes para colocar o caminho dentro ou fora de uma auditoria pré-incidente específica.
A empresa anunciou uma pausa na rede em 18 de agosto. Em seu Atualização de progresso de 26 de agostoeu mesmo disse que um contrato inteligente não autorizado poderia usar parâmetros de transação para entregar assemblies e instruções .NET codificados no caminho de execução do nó.
A conta provisória vinculou o incidente a lacunas nas verificações de reflexão em tempo de execução e carregamento dinâmico, juntamente com um fraco isolamento entre a execução do contrato e nós sensíveis ou recursos de infraestrutura. Eu mesmo identifiquei 155 transações associadas e cinco conjuntos de carga útil exclusivos com recursos que incluem execução de comando de host, tentativa de comunicação de saída, acesso de chave de nó e reconhecimento de infraestrutura.
Capacidade não é o mesmo que execução confirmada. Eu mesmo disse que as cargas úteis não provaram que todos os assembly foram executados, que todas as credenciais direcionadas foram obtidas ou que dados confidenciais deixaram seus sistemas. A empresa disse que estava alternando chaves de assinatura e credenciais de infraestrutura sob um padrão de exposição potencial.
O status público permaneceu provisório em 11 de setembro: índice do blog de si mesmo não continha nenhum item específico do incidente publicado após 26 de agosto. A declaração de 26 de agosto comprometeu-se com outra atualização e uma eventual revisão final.
eu mesmo estou de pé documentação de segurança diz que seus contratos de blockchain e token ELF passaram por diversas auditorias sem problemas de segurança identificados. Mas as páginas disponíveis não conectam um relatório pré-incidente específico ao caminho de execução descrito em agosto. Chamar o incidente de falha de auditoria ou de falha fora do escopo ultrapassaria, portanto, a evidência.
Essa incerteza é em si útil. Um histórico de auditoria desatualizado pode se separar do código atual, das dependências e do estado operacional de um sistema. Os usuários precisam de um registro de garantia com controle de versão e específico o suficiente para revelar esse desvio.
Tal registro deve nomear o repositório revisado e confirmar, endereços implantados, componentes excluídos, funções privilegiadas e dependências. Ele também deve registrar atualizações desde a revisão, custódia e rotação de chaves, isolamento de tempo de execução, comportamento de alerta e disjuntor e status de recuperação datado que separa a perda confirmada da exposição congelada ou não resolvida.
Isto não reduz o valor de uma auditoria. Torna a reivindicação proporcional ao trabalho realizado e conecta esse trabalho ao sistema em operação agora.
Um crachá de auditoria não pode responder se o artefato revisado, o sistema implantado e o maquinário que responde à falha ainda compartilham o mesmo limite de segurança.
