~$104,6M Perdidos: Verus, RetoSwap e Mais | BlockSec Semanal

Durante a semana passada (2026/05/18 - 2026/05/24), a BlockSec identificou múltiplos incidentes de ataque em vários ecossistemas de blockchain. A tabela abaixo lista 5 incidentes notáveis com perdas totais estimadas em aproximadamente $104,6M.

Dois incidentes são selecionados para análise aprofundada:

• Verus: o atacante explorou uma falha de validação de tipo na Ponte Verus-Ethereum ao submeter uma saída de exportação suplementar artesanal que a ponte classificou erroneamente como uma exportação primária válida. A semântica de mensagens entre cadeias faz parte da superfície de ataque.
• RetoSwap: uma falha de autenticação em nível de protocolo no fluxo de negociação P2P permitiu que um atacante sequestrase o papel de árbitro ao enviar uma mensagem ACK forjada. O atacante comprometeu a criação da carteira multisig inteiramente fora da cadeia.

Destaque da Semana: Verus

Este incidente é destacado porque o atacante abusou deliberadamente de um tipo especializado de exportação entre cadeias, indicando profundo conhecimento do design interno da cadeia Verus. O exploit demonstra que os formatos de mensagens entre cadeias, incluindo campos de dados suplementares e limites de codificação, fazem parte da superfície de ataque e exigem o mesmo rigor que a verificação de provas criptográficas.

Em 18 de maio de 2026, a Ponte Verus-Ethereum, uma ponte entre cadeias conectando a cadeia L1 Verus e o Ethereum, foi explorada em aproximadamente $11,7M em ETH, tBTC e USDC [1][2]. A causa raiz foi uma falha de validação de tipo no caminho de importação do lado Ethereum: o contrato da ponte aceitou uma saída de exportação suplementar artesanal e a classificou erroneamente como uma exportação primária válida, permitindo que o atacante fornecesse dados de transferência correspondentes e drenasse fundos. Até 23 de maio, aproximadamente 75% dos fundos roubados haviam sido devolvidos.

Contexto

A Ponte Verus-Ethereum libera ativos no Ethereum após alguém provar que uma exportação qualificada do lado Verus existe sob um estado Verus notarizado. O Ethereum não observa diretamente as transações Verus; ele depende de dados de prova submetidos mais uma notarização que ancora qual estado Verus é confiável.

Três objetos da ponte são relevantes para este incidente: uma exportação primária, que é o objeto que o Ethereum importa e usa para pagamentos; uma saída de exportação suplementar, que são dados extras anexados à exportação primária e não se destinam a ser tratados como uma exportação ativa independente para fins de pagamento; e uma notarização, que permite ao Ethereum provar que um objeto específico do lado Verus existia no estado finalizado da ponte.

Análise de Vulnerabilidade

Os contratos de ponte do lado Ethereum com falha estão implantados em 0xa045...6fc87f e 0x08f0...d0107d.

A causa raiz foi uma falha de validação de tipo no caminho de importação do Ethereum. A ponte provou que um objeto real do lado Verus existia, mas não verificou se o objeto provado era uma exportação primária válida antes de usá-lo para liberar fundos. Em vez disso, aceitou uma saída suplementar artesanal e a interpretou como se fosse uma exportação ativa normal.

Em alto nível, o fluxo vulnerável é:

proveImports(...)
    -> verificar prova
    -> verificar keccak256(serializedTransfers) == hash de transferência comprometido

processTransactions(...)
    -> executar pagamentos no Ethereum

Nenhuma verificação neste fluxo rejeita objetos com FLAG_SUPPLEMENTAL definido. A correção verifica explicitamente este sinalizador e reverte quando o objeto provado é suplementar:

Análise do Ataque

A análise a seguir é baseada na transação Ethereum 0x6990f0...87eb321 e na transação Verus f899e698...b9f5a733.

• Passo 1: Em 17 de maio, o atacante financiou o endereço Ethereum 0x5aBb...9D5777 com 1 ETH via Tornado Cash. Em 18 de maio, o atacante obteve 0,02 VRSC da torneira Verus para o endereço RW9vEW...B3g6zd.

• Passo 2: O atacante submeteu quatro transações de exportação destinadas ao Ethereum na Verus contendo saídas de exportação suplementares artesanais. Essas saídas suplementares foram codificadas para serem analisáveis sem erro e continham um comprometimento hashReserveTransfers correspondente aos pagamentos fraudulentos que o atacante pretendia executar posteriormente.

• Passo 3: Após uma notarização entre cadeias avançar o suficiente no Ethereum, o atacante submeteu uma transação de importação forjada no Ethereum. O objeto provado do lado Verus era a saída suplementar da transação Verus acima.

• Passo 4: A ponte Ethereum aceitou a prova, mas não rejeitou o objeto provado como dados suplementares. Em vez disso, interpretou a saída artesanal como se fosse uma exportação ativa válida. Como o atacante também forneceu serializedTransfers cujo hash correspondia ao valor comprometido hashReserveTransfers, a ponte prosseguiu pelo fluxo de importação.

• Passo 5: Com a saída suplementar mal interpretada como uma exportação válida, as transferências fraudulentas passaram pelas verificações do lado Ethereum. O atacante drenou aproximadamente $11,7M em ETH, tBTC e USDC.

• Passo 6: Logo após o sucesso da importação maliciosa, os nós Verus encontraram uma asserção de estado inválido causada pela coexistência da thread de exportação fraudulenta e uma thread de exportação real, o que interrompeu a progressão adicional da ponte e limitou a exploração subsequente.

Conclusão

O incidente foi causado por uma falha de validação de tipo na Ponte Verus-Ethereum: o contrato Ethereum aceitou uma prova criptográfica real, mas o objeto provado era uma saída de exportação suplementar, não uma exportação primária válida para pagamentos.

Os formatos de mensagens entre cadeias fazem parte da superfície de ataque. Dados suplementares, campos opcionais, codificações compactas e deslocamentos de analisador devem ser tratados com o mesmo rigor que verificações de assinatura ou prova de Merkle. Quando um objeto não corresponde ao tipo esperado para a ação sendo executada, a ponte deve rejeitá-lo imediatamente em vez de tentar analisá-lo.

Referências

• [1] Alerta BlockSec Phalcon
• [2] Post-Mortem Oficial da Verus

Mais Incidentes desta Semana

RetoSwap

Em 20 de maio de 2026, a RetoSwap, uma exchange P2P descentralizada na Monero derivada do Protocolo Haveno, foi explorada em aproximadamente $2,7M (7.000 XMR) [1]. A causa raiz foi uma falha de autenticação em nível de protocolo: o cliente aceitou uma mensagem ACK forjada e fora de ordem e sobrescreveu o endereço Tor armazenado do árbitro com um controlado pelo atacante sem verificar o remetente contra a chave pública conhecida do árbitro. Isso permitiu que o atacante sequestrase a criação da carteira multisig e roubasse fundos assim que foram depositados.

Contexto

A RetoSwap é uma exchange P2P descentralizada na Monero, derivada do Protocolo Haveno. Seu protocolo de negociação depende de um modelo multisig de árbitro 2-de-3 para proteger as negociações e coordena as negociações fora da cadeia via Tor.

Uma negociação normal prossegue em três fases: primeiro, o comprador, o vendedor e o árbitro completam trocas de mensagens fora da cadeia para estabelecer uma carteira multisig; segundo, os fundos são bloqueados na carteira multisig somente após ela ter sido totalmente criada; terceiro, o comprador e o vendedor co-assinam uma transação de pagamento para liquidar, ou o árbitro intervém para resolver disputas. Toda a comunicação ocorre via Tor, e cada nó é identificado unicamente pelo seu endereço .onion.

Análise de Vulnerabilidade

Em 20 de maio, o projeto Haveno abriu um pull request intitulado "core: refuse to update node address before multisig created" [2]. Nesse momento, a RetoSwap já estava sendo explorada.

O patch revelou uma vulnerabilidade em TradeProtocol.java:onAckMessageAux(...). O cliente identificava pares usando um senderNodeAddress fornecido pela mensagem sem verificar criptograficamente se o remetente correspondia à chave pública esperada do árbitro. Um atacante poderia enviar uma mensagem ACK forjada carregando um endereço .onion controlado pelo atacante, e o cliente sobrescreveria o endereço do árbitro armazenado com ele.

Como isso ocorreu durante a Fase 1 (antes da criação da carteira multisig), o endereço do atacante substituiu o endereço do árbitro real. O atacante, portanto, detinha tanto a chave do negociador quanto a chave do árbitro da carteira multisig, possibilitando o roubo de todo o saldo assim que os fundos fossem depositados.

A correção aborda isso de duas maneiras: verifica o remetente contra a chave pública conhecida do par, rejeitando mensagens de pares não verificados; e condiciona as atualizações de endereço a trade.isDepositRequested(), impedindo sobrescritas antes que a carteira multisig seja criada.

Análise do Ataque

Nenhuma transação de ataque on-chain foi identificada para este incidente. A RetoSwap opera inteiramente via Tor com tratamento de mensagens fora da cadeia, portanto as ações críticas ocorrem fora de qualquer registro público. A reconstrução a seguir é baseada no patch publicamente disponível e nas comunicações oficiais.

• Passo 1: O atacante ingressou em uma negociação existente como comprador ou vendedor.

• Passo 2: O atacante enviou uma mensagem ACK forjada e fora de ordem aparentando vir do árbitro, carregando um endereço .onion controlado pelo atacante como senderNodeAddress.

• Passo 3: O cliente da vítima aceitou a mensagem e sobrescreveu o endereço armazenado do árbitro sem verificar o remetente contra a chave pública conhecida do árbitro.

• Passo 4: Toda comunicação subsequente destinada ao árbitro, incluindo a criação da carteira multisig, foi roteada para o atacante, que obteve a terceira chave multisig.

• Passo 5: Assim que o comprador e o vendedor depositaram fundos na carteira multisig comprometida, o atacante roubou todo o conteúdo da carteira. O lucro total foi de aproximadamente 7.000 XMR (~$2,7M).

Conclusão

O incidente não foi uma falha criptográfica, mas uma falha de autenticação em nível de protocolo: as mensagens foram validadas como bem formadas, mas o remetente não foi criptograficamente vinculado a uma chave pública conhecida antes que as atualizações de endereço fossem aplicadas. Como resultado, o cliente tratou um senderNodeAddress não verificado de uma mensagem ACK forjada como o novo ponto de contato do árbitro antes que a carteira multisig fosse criada, permitindo que o atacante sequestrase o papel de árbitro.

As principais lições são: (1) qualquer mensagem que atualize a identidade de um par deve ser verificada criptograficamente contra a chave pública conhecida do par antes que a atualização seja aplicada, e (2) o estado crítico de identidade, como endereços de contraparte, deve ser imutável uma vez que a fase sensível à segurança (por exemplo, criação da carteira multisig) tenha começado.

Referências

• [1] Declaração Pós-Incidente da RetoSwap
• [2] Pull Request de Correção do Haveno

Sobre a BlockSec

A BlockSec é um provedor completo de segurança em blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança em blockchain em conferências prestigiosas, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 Serviço de Auditoria BlockSec : Enviar uma solicitação

• 🔗 Phalcon Security APP: Agendar uma demonstração

• 🔗 Phalcon Compliance