Alerta de 680 milhões de dólares: a maioria dos ataques DeFi fica fora do âmbito das auditorias

Autor: Liam 'Akiba' Wright, cryptoslate

Compilação: Chopper, Foresight News

No setor das finanças descentralizadas, o termo "auditado" é frequentemente visto como um selo de segurança para todo o projeto. Na prática, porém, as auditorias costumam abranger apenas um momento específico, código, componentes e versões determinados. Qualquer elemento adicionado, removido ou manipulado fora desse âmbito pode ter um resultado de auditoria completamente diferente.

Um novo artigo em pré-publicação quantifica essa lacuna. Investigadores da empresa de segurança ack3 e da Universidade Técnica Checa de Praga analisaram 135 incidentes de segurança reportados no primeiro semestre de 2025, que causaram perdas de 939,86 milhões de dólares. Descobriram que 68 desses incidentes tinham registos públicos identificáveis de auditorias prévias.

Nessa amostra de 68 incidentes, os investigadores classificaram 46 vetores de ataque como totalmente fora de qualquer âmbito de auditoria verificável; 20 incidentes estavam, pelo menos em parte, dentro do âmbito de uma auditoria; e os restantes 2 não puderam ser determinados. Os incidentes fora do âmbito representaram 67,6% do total de ocorrências, mas corresponderam a 94,4% do total de perdas reportadas.

Esta proporção impressionante não é uma avaliação da eficácia das auditorias, nem prova de que as limitações do âmbito causaram as perdas. Representa apenas a distribuição de perdas na amostra selecionada de incidentes de segurança públicos. Dois eventos de grande dimensão influenciaram fortemente os dados: excluindo a perda de 292 milhões de dólares da Kelp DAO e a de 285 milhões de dólares da Drift Protocol, a percentagem de perdas causadas por ataques fora do âmbito na mesma amostra auditada cai para 72,1%.

Mesmo com estas limitações, o estudo revela um problema fundamental de confiança na segurança: um projeto pode afirmar que foi auditado, mas os utilizadores não conseguem saber se o sistema em funcionamento, os fluxos de fundos e os controlos associados foram efetivamente revistos.

O verdadeiro significado dos dados

O estudo da ack3 abrange o período de 1 de janeiro a 29 de junho de 2025, com 122 ataques confirmados e 13 suspeitos. Em toda a amostra, 35 incidentes não tinham registo de auditoria e 32 tinham histórico de auditoria desconhecido; ambos os grupos foram excluídos da estatística dos 68 incidentes acima.

Na amostra de 68 incidentes, as perdas fora do âmbito totalizaram 680,97 milhões de dólares, num total de 721,24 milhões, resultando nos 94,4%. Excluindo a Kelp DAO e a Drift Protocol, as perdas fora do âmbito foram de 103,97 milhões de dólares, num total de 144,24 milhões, ou seja, 72,1%. O ficheiro json do conjunto de dados permite reproduzir a classificação dos incidentes e os montantes das perdas.

Os rótulos "dentro/fora do âmbito da auditoria" resultam do julgamento dos investigadores com base em provas públicas. A equipa consultou arquivos de projetos e de empresas de auditoria, localizou relatórios de auditoria anteriores aos ataques e comparou o vetor de ataque final com o código auditado, as versões e as exclusões da auditoria. O estudo é um artigo de 6 páginas em pré-publicação, produzido em conjunto com os responsáveis pela publicação do conjunto de dados, e dois dos autores pertencem à empresa de auditoria de segurança ack3.

O estudo não inclui um grupo de controlo de sistemas não atacados, nem mede o tempo de exposição ao risco de cada sistema. Por isso, não prova que os protocolos auditados sejam globalmente mais seguros, não permite estimar a probabilidade de incidentes, nem confirma que "estar fora do âmbito da auditoria" tenha sido a causa direta de cada perda. Algumas auditorias não públicas e incidentes privados podem estar em falta, e os dados de perdas reportadas não são totalmente comparáveis.

Assim, o estudo só permite conclusões limitadas: o registo de auditoria e a cobertura da auditoria são dois indicadores independentes. Um contrato inteligente revisto não garante que as atualizações do contrato, as chaves privilegiadas, o frontend, os relays, os oráculos, os serviços na nuvem ou os processos de resposta a emergências tenham o mesmo nível de segurança.

Dois incidentes ocorridos em agosto ilustram esta distinção de perspetivas diferentes. O caso da ICON Network mostra de forma direta como dois trechos de código auditados falharam na fronteira entre dois pontos de verificação; já o incidente de segurança da aelf, em agosto, é outro cenário: as provas de auditoria existentes ainda não permitem mapear o percurso do ataque para o âmbito de uma auditoria prévia.

ICON Network: uma amostra de falha na fronteira da auditoria

No ataque de repetição à ICON Network, a 27 de agosto, dois módulos da cadeia de levantamento interpretaram a mesma mensagem de forma divergente.

Segundo o relatório de análise pós-incidente da ICON Foundation: o contrato de migração usava os bits de ordem superior do número de sequência da mensagem de levantamento para determinar se a mensagem era única; mas a assinatura criptográfica cobria apenas os 256 bits inferiores do número de sequência. Ao alterar os bits de ordem superior, que não estavam incluídos na verificação da assinatura, o atacante repetiu duas mensagens de levantamento com assinaturas válidas 1492 vezes em cerca de 20 minutos, das quais 1490 chamadas foram executadas com sucesso.

Este ataque de repetição libertou 119,866 milhões de ICX e 531.600 bnUSD. Na altura da publicação da análise, a ICON confirmou uma perda líquida de cerca de 150,2 ETH e 31.204 USDC. A fundação afirmou que 531.600 bnUSD e 1,366 milhões de SODA foram recuperados, e que os depósitos, saldos e posições dos utilizadores não foram afetados.

A ICON indicou que este contrato de migração tinha sido alvo de uma auditoria externa e que as recomendações da auditoria foram implementadas, incluindo alterações na mesma área do módulo; a lógica de relay correspondente também foi alvo de uma revisão específica separada. A lista de auditorias da documentação de desenvolvimento da Sodax inclui 8 relatórios que cobrem diferentes componentes, entre os quais um relatório de auditoria do relay da Sodax de novembro de 2025.

No entanto, o relatório pós-incidente afirma que esta discrepância exata entre a lógica de verificação de unicidade e o valor verificado pela assinatura não estava no âmbito das descobertas dessas auditorias. Um simples rótulo de projeto "auditado" não permite aos utilizadores saber se os dois extremos da cadeia de levantamento mantêm critérios consistentes para a "unicidade da mensagem".

A cronologia da resposta expõe ainda outro tipo de problema de fronteira. O primeiro alerta automatizado da ICON foi acionado às 02:08 UTC, cerca de 7 minutos após o início do ataque. A equipa iniciou a investigação por volta das 03:40, suspendeu o contrato afetado às 03:53 e parou toda a rede às 06:18:54.

Entre o primeiro alerta e a resposta de emergência completa decorreram cerca de 90 minutos. A ICON atribuiu este intervalo ao ajuste do mecanismo de alertas: a regra de alerta tinha gerado muitos falsos positivos em falhas de conectividade anteriores, pelo que não notificava o pessoal de serviço com prioridade elevada. A fundação planeia implementar mecanismos automáticos de paragem, reduzir os limiares de disjuntor e realizar uma revisão específica sobre unicidade de mensagens e proteção contra repetição.

Este tipo de mecanismo de controlo de risco não substitui a auditoria, mas responde a outra questão essencial: quando as medidas preventivas falham, o sistema consegue detetar e isolar rapidamente o risco?

aelf: a garantia de segurança precisa de atualização contínua

O incidente de segurança da aelf em agosto confirma esta perspetiva de outro ângulo. A informação pública descreve uma intrusão em tempo de execução e uma recuperação controlada, mas as provas existentes não permitem determinar se o vetor de ataque se enquadrava no âmbito de uma auditoria prévia específica.

O anúncio oficial do projeto indica que existia um contrato inteligente não autorizado capaz de injetar assemblies .NET codificados e instruções na cadeia de execução dos nós através de parâmetros de transação.

O relatório preliminar de investigação atribui o incidente a deficiências na validação de reflexão em tempo de execução e de carregamento dinâmico, bem como a um isolamento insuficiente entre o ambiente de execução de contratos e os nós sensíveis e recursos de infraestrutura. A aelf identificou 155 transações relacionadas e 5 assemblies de payload distintos, com capacidade para executar comandos no anfitrião, tentar comunicações externas, aceder a chaves dos nós e realizar reconhecimento de infraestrutura.

Ter capacidade não significa que todos os payloads tenham sido executados com sucesso, nem que o atacante tenha obtido todas as credenciais visadas ou que tenha havido fuga de dados sensíveis. A aelf afirmou ter procedido à rotação das chaves de assinatura e das credenciais de infraestrutura de acordo com os padrões de potencial comprometimento.

Até 11 de setembro, esta conclusão continuava a ser uma avaliação provisória. O blogue oficial da aelf não publicou qualquer atualização específica sobre este incidente depois de 26 de agosto. O anúncio de 26 de agosto prometia publicar atualizações e uma análise final posteriormente.

A documentação técnica de segurança da aelf indica que a sua blockchain e o contrato do token ELF foram alvo de várias auditorias, sem que tenham sido encontrados problemas de segurança. No entanto, as páginas públicas atuais não permitem associar o percurso em tempo de execução do ataque de agosto a qualquer relatório de auditoria anterior ao incidente. Por isso, classificar o evento como falha de auditoria ou como falha fora do âmbito carece de provas suficientes.

Esta incerteza tem, em si, valor de referência. Um relatório de auditoria com carimbo temporal vai-se desatualizando gradualmente em relação ao código atual do sistema, às bibliotecas de dependências e ao estado operacional real. Os utilizadores precisam de um registo de segurança versionado que reflita esta diferença.

Esse registo de segurança deve indicar: o repositório auditado e a versão do commit do código, os endereços dos contratos implementados, os componentes excluídos, as funções privilegiadas e as bibliotecas de dependências; deve ainda registar as atualizações de contratos após a auditoria, a custódia e o mecanismo de rotação de chaves, a política de isolamento em tempo de execução, os mecanismos de alerta e disjuntor, e o estado de recuperação de ativos com carimbo temporal, distinguindo perdas confirmadas, ativos congelados e exposições de risco ainda por resolver.

Isto não nega o valor das auditorias, mas alinha a comunicação sobre auditorias com o trabalho efetivamente realizado e com o sistema atualmente em funcionamento.

Um selo de auditoria não responde a uma questão essencial: os componentes auditados, o sistema implementado e os mecanismos de resposta a falhas continuam dentro da mesma fronteira de segurança?