Análise aprofundada do incidente de vulnerabilidade do Truebit: Como uma transbordamento de inteiro permitiu que hackers cunhassem 26,44 milhões de dólares sem custo

1月8日， cálculo de verificação da plataforma Truebit sofreu um incidente de segurança de grande escala. O relatório de análise da equipe de segurança SlowMist revelou a verdade por trás do evento: os atacantes exploraram uma vulnerabilidade de estouro de inteiro no contrato Purchase para cunhar tokens TRU a custos quase nulos, e posteriormente roubaram 8.535 ETH, avaliados em aproximadamente 26,44 milhões de dólares. Ainda mais preocupante, os hackers realizaram toda a lavagem de dinheiro entre 10 e 11 de janeiro via Tornado Cash, tornando a recuperação quase impossível. Isso representa não apenas uma perda econômica significativa, mas também um severo teste à consciência de segurança de todo o ecossistema de contratos inteligentes.

A essência da vulnerabilidade: o mecanismo de proteção esquecido

O que é estouro de inteiro

Estouro de inteiro é uma vulnerabilidade comum, porém perigosa, em contratos inteligentes. Simplificando, quando um cálculo numérico excede o máximo que seu tipo de dado pode representar, o sistema automaticamente “enrola” para o valor mínimo. Por exemplo, se um inteiro sem sinal de 8 bits tem valor máximo de 255, ao tentar somar 1, o resultado será 0.

No contrato Purchase do Truebit, essa vulnerabilidade foi explorada para cálculos de preço. Os atacantes, por meio de parâmetros de transação cuidadosamente construídos, fizeram com que o cálculo de preço ocorresse um estouro, permitindo que o sistema cunhasse tokens TRU a um preço extremamente baixo (próximo de zero). Isso equivale a um ataque em que uma operação que deveria custar milhões de dólares foi realizada por quase nenhum custo.

Por que essa vulnerabilidade ocorre

Segundo a análise da SlowMist, a causa fundamental foi a ausência de mecanismos de proteção contra estouro no contrato do Truebit. Essa questão é um clássico risco de segurança na linguagem Solidity.

O Truebit foi compilado com versões do Solidity anteriores à 0.8.0, o que significa que todas as operações aritméticas deveriam usar a biblioteca SafeMath para proteção. Claramente, em algum ponto do cálculo de Price, essa proteção foi omitida.

Caminho do ataque e reação do mercado

Processo do ataque pelos hackers

De acordo com monitoramentos de informações, o procedimento do ataque foi surpreendentemente eficiente:

• Primeira etapa: identificar a vulnerabilidade, construir transações maliciosas
• Segunda etapa: cunhar uma grande quantidade de tokens TRU a custos baixos
• Terceira etapa: usar os tokens cunhados para retirar ETH do pool de fundos do Truebit
• Quarta etapa: transferir rapidamente os fundos para endereços de mistura (mixers)
• Quinta etapa: lavar o dinheiro via Tornado Cash (concluído entre 10 e 11 de janeiro)

Todo o processo, desde a descoberta da vulnerabilidade até a lavagem do dinheiro, durou menos de 72 horas. O nível de profissionalismo e velocidade de execução dos hackers indica que não foi uma tentativa aleatória, mas um ataque planejado com objetivo específico.

Sinal de preocupação do mercado

O incidente gerou uma reação negativa clara no mercado. Segundo dados recentes, o preço do ETH está em US$ 3.102,47, com tendência de fraqueza: queda de 0,03% nas últimas 24 horas e queda de 2,14% em 7 dias. Embora as quedas não sejam extremas, o problema mais profundo é a desconfiança dos investidores na segurança de projetos como o Protocolo de Verificação de Cálculo (Computation Verification Protocol).

O Truebit é uma infraestrutura fundamental de verificação de cálculos no ecossistema Layer 2. Seu incidente de segurança não apenas abalou a confiança no projeto, mas também levantou preocupações na indústria sobre “quantos outros riscos semelhantes ainda existem”.

Lições para o setor: não é um caso isolado

Por que o SafeMath é tão crucial

A SlowMist recomenda claramente no relatório: para todos os contratos compilados com versões do Solidity anteriores à 0.8.0, é obrigatório usar a biblioteca SafeMath para proteger todas as operações aritméticas. Isso não é uma opção, mas uma linha de defesa essencial.

A função da biblioteca SafeMath é simples, mas fundamental: ela verifica, a cada operação aritmética, se ocorreu estouro, revertendo a transação se necessário. Embora pareça uma etapa redundante, ela previne desastres como o do Truebit.

Problemas de pontos cegos na auditoria

Curiosamente, mesmo sendo um projeto bem financiado e com equipe técnica competente, o Truebit deveria ter passado por auditoria de segurança. Ainda assim, a vulnerabilidade foi negligenciada. Isso reflete um problema na indústria:

• Equipes de auditoria podem depender excessivamente de ferramentas automatizadas
• Falta de percepção dos riscos específicos de versões antigas do Solidity
• Insuficiência na profundidade da revisão de código

Isso mostra que, mesmo após auditorias, não há garantia de segurança 100%.

A ameaça contínua dos mixers

O Tornado Cash desempenhou novamente o papel de “buraco negro” para os fundos. Após transferir os ETH para mixers, os fundos tornam-se praticamente impossíveis de rastrear ou congelar. Por isso, a perda de 8.535 ETH é considerada “quase impossível de recuperar”.

Isso nos alerta de que, mesmo identificando o endereço do hacker, se ele transferir os fundos para mixers rapidamente, as ações de aplicação da lei se tornam muito mais difíceis.

Resumo

O incidente do Truebit é, na essência, uma tragédia causada por uma proteção básica esquecida. A perda de 8.535 ETH e US$ 26,44 milhões é a superfície de um problema mais profundo:

• Escolha de versão é crucial: usar versões antigas do Solidity exige maior atenção e proteção extra
• SafeMath não é opcional: é uma linha de defesa obrigatória
• Auditorias não garantem segurança absoluta: é preciso revisão de código mais aprofundada e avaliação de riscos
• Resposta rápida é vital: a velocidade com que os hackers transferiram os fundos mostra a necessidade de mecanismos de resposta mais ágeis

Para toda a indústria, esse é um aprendizado caro. Mas, se promovermos padrões de segurança mais rigorosos, auditorias mais profundas, escolhas de versões mais seguras, esse custo pode não ser em vão.