A Assinatura Vazia que Quebrou o Bonzo Lend: Um Pós-Morte do Exploração de $9M na Hedera
2026/07/15 11:18:00
Na matemática e na ciência da computação, zero representa vazio — a ausência absoluta de valor. Mas no ecossistema frágil e hiperconectado da Finança Descentralizada (DeFi), um parâmetro "zero" não verificado recentemente tornou-se uma chave mestre digital. Em poucos minutos, esse único valor vazio não verificado desbloqueou e esvaziou mais de US$ 9 milhões de uma plataforma de empréstimos proeminente.
A vítima deste exploit devastador foi o Bonzo Lend, o maior protocolo de empréstimo operando na rede Hedera. Em julho de 2026, o protocolo viu seu Total Value Locked (TVL) cair em 77% em um instante. Enquanto o pânico se espalhava pela comunidade Hedera, observadores se esforçavam para encontrar a fonte do vazamento.
Importante, esse desastre não ocorreu porque o consenso da rede subjacente da Hedera falhou, nem porque os cálculos centrais de empréstimo do Bonzo Lend estavam incorretos. Em vez disso, o desastre surgiu de uma vulnerabilidade de integração fatal: uma falha crítica na validação de assinatura dentro de seu provedor terceirizado de feed de preços, Supra Oracles. Este é o pós-mortem de como uma pequena falha lógica relacionada a "nada" derrubou um gigante do DeFi.
Cronologia do Ataque: De US$ 5 para US$ 9.000.000 em segundos
A execução da exploração do Bonzo Lend foi brilhante em sua simplicidade, exigindo capital inicial mínimo e ocorrendo em apenas alguns passos transacionais.
Para iniciar o assalto, o atacante depositou uma quantia mínima e negligenciável de garantia no Bonzo Lend—especificamente, 250 tokens SAUCE. No momento do depósito, essa garantia valia apenas alguns dólares, mal suficiente para comprar uma xícara de café. Sob as regras normais do protocolo, essa pequena quantia permitiria ao usuário tomar emprestado apenas uma fração do seu valor em outros ativos digitais.
Em seguida, o atacante iniciou a exploração contornando as verificações de validação do oracle de preços. Eles criaram e enviaram uma transação de atualização de preço falsificada para o contrato de validação do oracle. Essa transação continha dados altamente maliciosos: inflou artificialmente o preço do token SAUCE em 12 ordens de grandeza — efetivamente informando ao protocolo que um único token SAUCE subitamente valia bilhões de dólares.
Para impulsionar esse preço forjado, o sistema exigia uma assinatura criptográfica de um nó oráculo autorizado. Em vez de tentar quebrar a criptografia complexa ou roubar uma chave privada, o atacante simplesmente deixou o campo de assinatura completamente em branco, enviando uma sequência de zeros no lugar de uma assinatura criptográfica.
Devido a uma falha crítica na lógica de validação, o contrato aceitou a assinatura em branco como válida. Imediatamente, o sistema de avaliação da Bonzo registrou os 250 SAUCE de colateral do atacante como um ativo de valor monumental. Explorando essa riqueza súbita e artificial, o hacker retirou rapidamente 6,63 milhões de USDC e 34,50 milhões de HBAR embrulhados (wHBAR) das piscinas de liquidez da Bonzo, esvaziando com sucesso o protocolo antes que qualquer alarme pudesse ser acionado.
Desmistificando a falha "Zero-Signature": Como o código falhou
Para entender como essa exploração foi possível, devemos desmistificar a matemática das assinaturas digitais. Em redes descentralizadas, assinaturas criptográficas atuam como selos de cera digitais. Quando um node de oracle publica uma atualização de preço, ele assina os dados usando uma chave privada. O contrato inteligente no lado receptor usa um algoritmo de verificação para confirmar que a assinatura corresponde à chave pública autorizada do node de oracle.
Normalmente, se um usuário enviar uma assinatura inválida, a biblioteca de verificação tenta processar a entrada e falha. Quando bibliotecas de verificação criptográfica encontram entradas malformadas, vazias ou totalmente zeradas, nem sempre geram um erro ativo. Em vez disso, muitas bibliotecas padrão são projetadas para produzir um valor padrão quando uma assinatura não pode ser analisada. Em contratos inteligentes, essa saída padrão é quase sempre um endereço nulo representado por uma longa sequência de zeros.
A vulnerabilidade fatal no contrato de validação do oracle residia em como ele lidava com esse endereço nulo padrão. O contrato foi programado para verificar se o assinante recuperado correspondia a um endereço de nó de oracle autorizado. No entanto, os desenvolvedores esqueceram de incluir uma regra básica: rejeitar qualquer entrada onde o comprimento da assinatura fosse zero ou o endereço recuperado retornasse um valor nulo.
Além disso, se o estado do assinante autorizado dentro do contrato estivesse desinicializado ou configurado de forma a permitir verificações nulas, o contrato comparava o endereço nulo retornado pela assinatura falha com seus parâmetros internos e declarava uma correspondência. Como a lógica de validação não conseguiu distinguir entre uma "recuperação de assinatura falha" e um "assinante autorizado válido", o contrato tratou a assinatura vazia como um sinal verde absoluto, aprovando a fonte de preço falsificada.
O Dilema do Oracle: Por que os Legos DeFi são tão fortes quanto seu elo mais fraco
DeFi é frequentemente celebrado por sua "componibilidade" — a capacidade de diferentes protocolos, tokens e ferramentas se conectarem como "Legos Financeiros" para construir aplicações financeiras complexas. Embora a componibilidade permita inovação rápida, ela também introduz fragilidade sistêmica. Uma única falha em um bloco fundamental pode derrubar toda a pilha estrutural.
A exploração do Bonzo Lend ilustra perfeitamente essa vulnerabilidade. O Bonzo Lend era um protocolo de empréstimo bem estruturado que havia passado por auditorias de segurança. No entanto, o protocolo precisava confiar em sua dependência externa de oracle para fornecer preços precisos. No momento em que o sistema de validação do oracle aceitou o preço falso, os contratos de empréstimo do Bonzo executaram exatamente como foram escritos, permitindo que o usuário "rico" fortemente garantido tomasse emprestado ativos.
A tabela abaixo detalha a distribuição das responsabilidades estruturais durante o ataque, ilustrando onde a linha defensiva colapsou:
| Componente | Função Sistêmica Prevista | Desempenho Durante a Exploração | Lição Estrutural |
| Camada de Consenso Hedera | Mantenha o estado do livro-razão seguro, ordene as transações e mantenha a disponibilidade da rede. | Executado perfeitamente, sem tempo de inatividade nem explorações ao nível da rede. | Uma camada de consenso de rede segura não garante a segurança em nível de aplicativo. |
| Supra Oracle | Forneça dados de preço de ativos assinados, criptograficamente verificados e precisos. | Falha ao rejeitar uma assinatura nula, publicando um preço corrompido. | As dependências devem ser tratadas com paradigmas de validação de confiança zero. |
| Bonzo Emprestar | Gerencie ativos de depósito, monitore as taxas de saúde dos empréstimos e processe empréstimos. | Confiou cegamente nos dados de preço entrantes, não limitando picos súbitos de preço. | Contratos inteligentes devem implementar lógica defensiva para sobreviver a falhas de dependência. |
A Intervenção do Chapéu Branco: Uma corrida de US$ 1 milhão contra o hacker
Enquanto a exploração se desenrolava no livro-razão público, um evento secundário dramático ocorreu. Em blockchains públicas, as transações são visíveis na "mempool" antes de serem finalizadas. Essa transparência permite que outros participantes, tanto maliciosos quanto éticos, analisem ataques em tempo real.
Pouco tempo após o atacante principal começar a esvaziar o protocolo, um pesquisador de segurança independente—comumente conhecido como um hacker "white hat"—detectou a exploração ativa. Reconhecendo que todo o protocolo estava prestes a ser esvaziado, o white hat executou rapidamente a mesma vulnerabilidade de assinatura zero para sacar aproximadamente US$ 1 milhão em ativos.
Essa tática, conhecida como "front-running", é uma manobra defensiva comum na segurança Web3. Ao retirar os fundos primeiro, o white hat impediu o ator malicioso de roubar essa parte do pool de liquidez.
Após a retirada bem-sucedida, o hacker de chapéu branco imediatamente entrou em contato com a equipe do Bonzo Lend. Após confirmar sua identidade e intenções, o hacker ético devolveu com segurança os US$ 1 milhão inteiro aos endereços de recuperação do protocolo. Embora o principal atacante ainda tenha fugido com a maioria dos fundos, essa intervenção rápida preservou uma parte vital dos ativos da comunidade e demonstrou a natureza única e colaborativa da segurança Web3.
Perseguindo os Milhões: Como os Fundos Roubados Sairam do Ecossistema Hedera
Após o hacker conseguir emprestar milhões de dólares em USDC e wHBAR contra sua garantia falsa, seu objetivo principal passou a ser escapar do ecossistema Hedera antes que o protocolo pudesse pausar seus contratos.
O atacante não manteve os ativos roubados em sua forma original. Usando o SaucerSwap, uma exchange descentralizada popular na Hedera, o hacker trocou rapidamente os tokens emprestados por stablecoins e ativos nativos altamente líquidos para evitar mecanismos de congelamento centralizados.
Imediatamente após trocar os tokens, o atacante utilizou pontes intercadeia, roteando especificamente os fundos através da LayerZero. Ao bridgear os ativos, o hacker transferiu mais de US$ 5 milhões em fundos roubados diretamente para o mainnet da ethereum.
Uma vez que os ativos cruzam para uma rede altamente líquida e massiva como o ethereum, rastreá-los e recuperá-los torna-se exponencialmente mais difícil. Os fundos podem ser divididos entre centenas de endereços novos, depositados em misturadores de privacidade descentralizados ou trocados por moedas de privacidade não custodiais. Essa rota de fuga rápida e automatizada destaca por que o monitoramento em tempo real e pausas de emergência imediatas são as únicas defesas viáveis contra explorações cross-chain modernas.
As Lições Difíceis: Como os Protocolos DeFi Podem Se Proteger de Desastres de Oracle
A perda de US$ 9 milhões é uma lição extremamente cara, mas fornece insights inestimáveis para desenvolvedores de contratos inteligentes que buscam proteger suas aplicações contra erros de integração futuros.
Para evitar vulnerabilidades de assinatura zero, os desenvolvedores devem adotar práticas de codificação rigorosas e defensivas. Melhorias estruturais-chave incluem:
-
Verificação explícita de endereço nulo: Nunca assuma que uma função de verificação de assinatura foi bem-sucedida. Cada rotina de validação criptográfica deve verificar explicitamente que o comprimento da assinatura é maior que zero e confirmar que o endereço de saída não é resolvido como um valor nulo (
0x00...00). Se um valor nulo for retornado, a transação deve ser imediatamente revertida. -
Arquiteturas redundantes de oráculos: Depender de um único provedor de oráculo cria um ponto único de falha. Protocolos DeFi robustos devem obter preços de ativos de múltiplas redes de oráculos independentes (como Chainlink, Pyth e Supra simultaneamente). Se um feed se desviar significativamente da mediana dos demais, o protocolo deve sinalizar a discrepância e pausar as operações automaticamente.
-
Frenos de preço on-chain: os protocolos de empréstimo devem implementar limites de taxa e faixas de desvio de preço. Mesmo que um oracle afirme que o valor de um token aumentou um trilhão de vezes em um único bloco, o freio interno do contrato inteligente deve rejeitar a atualização como uma anomalia, interrompendo quaisquer ações de empréstimo ou liquidação até que ocorra verificação administrativa manual.
O Futuro das Auditorias de Contratos Inteligentes: Por Que Devemos Testar os Limites
A exploração do Bonzo Lend expõe uma limitação crítica nas práticas atuais de auditoria Web3. Muitas auditorias de segurança se concentram fortemente em verificar se a lógica de negócios de um contrato funciona sob condições esperadas—frequentemente denominada teste de "caminho feliz".
No entanto, atacantes do mundo real não seguem o caminho ideal. Eles buscam especificamente condições de limite, estados não inicializados e entradas inesperadas. A indústria de segurança deve mudar para testes agressivos de casos extremos para descobrir falhas ocultas antes do código ir ao mainnet.
Para alcançar isso, os protocolos devem tornar metodologias avançadas de teste, como fuzzing e verificação formal, um padrão obrigatório. O fuzzing envolve o uso de ferramentas automatizadas para inundar contratos inteligentes com milhões de entradas aleatórias, malformadas e vazias — incluindo strings de bytes vazias e assinaturas nulas. Se o contrato de verificação tivesse sido submetido a um fuzzing rigoroso, a contornagem de assinatura zero teria sido detectada imediatamente.
Por fim, provedores terceirizados de oráculos também devem adotar padrões de segurança mais elevados. Como esses feeds de dados servem como base para centenas de milhões de dólares em atividade econômica, seu código de verificação deve ser tratado com o mesmo nível de escrutínio das redes de camada um que apoiam.
Conclusão: Restaurando a Confiança em um Ecossistema Sem Confiança
A exploração do Bonzo Lend é um lembrete nítido da natureza implacável dos contratos inteligentes. Na Web3, o código é lei, e a EVM não se importa com suas intenções. Uma pequena falha lógica relacionada a "nada" pode apagar instantaneamente anos de desenvolvimento e milhões de dólares em confiança dos usuários.
Após o ataque, tanto o Bonzo Lend quanto o Supra Oracles agiram rapidamente para corrigir a vulnerabilidade e proteger a infraestrutura restante. Embora o incidente tenha sido doloroso, as lições aprendidas levarão inevitavelmente a padrões de integração mais seguros em todo o ecossistema DeFi. Para desenvolvedores e investidores, a principal lição é simples: nunca dê por garantida a segurança da integração, teste os limites do seu código e sempre verifique o que acontece quando você não fornece nada aos seus sistemas.
Perguntas frequentes:
Q1: O bug "Zero-Signature" significa que a criptografia da blockchain está quebrada?
Não. Os princípios matemáticos por trás das assinaturas digitais e da criptografia de chave pública permanecem totalmente seguros. A exploração foi causada por um erro lógico de programação no contrato inteligente que manipulava a saída da biblioteca criptográfica. A biblioteca agiu corretamente ao retornar um valor nulo quando recebeu uma assinatura em branco, mas o contrato interpretou incorretamente esse valor nulo como uma verificação bem-sucedida.
Q2: Por que o Bonzo Lend confiou automaticamente em um preço tão absurdamente inflado para SAUCE?
Os protocolos de empréstimo são projetados para serem modulares, o que significa que transferem a tarefa complexa de precificação de ativos para redes oráculo dedicadas. Como o Bonzo Lend foi construído para aceitar o feed de preços do oráculo como verdade absoluta, sem quaisquer verificações de sanidade independentes ou limites de desvio de preço, ele aceitou o aumento artificial de preço em um trilhão de vezes e permitiu que a transação de empréstimo prosseguisse.
Q3: O que os usuários comuns de DeFi podem fazer para se proteger contra ataques relacionados a oráculos?
Embora os usuários não possam controlar o código de um protocolo, eles podem gerenciar seu próprio risco. Para proteger seu capital, diversifique seus ativos em várias plataformas independentes, evite protocolos que dependam de uma única fonte de oracle para ativos nichados e busque plataformas que tenham integrado publicamente sistemas de oracle de múltiplas fontes e interruptores de emergência robustos e em cadeia.
Isenção de responsabilidade: Este conteúdo é apenas para fins informativos e não constitui aconselhamento financeiro. Investimentos em criptomoedas envolvem riscos. Faça sua própria pesquisa (DYOR).
Aviso legal: Esta página foi traduzida usando tecnologia de IA para sua conveniência. Para informações mais precisas, consulte a versão original em inglês.