A Verus-Ethereum Bridge sofreu um segundo exploit na quinta-feira, 23 de julho, quando invasores drenaram de US$ 7,3 milhões a US$ 7,5 milhões em ativos digitais por meio de uma solicitação de importação maliciosamente criada, segundo pesquisadores de segurança de blockchain. A violação explorou a mesma falha de bypass de autorização e de suposição de estado de protocolo que permitiu um ataque em 17 de maio, que roubou aproximadamente US$ 11,6 milhões, levando as perdas totais para cerca de US$ 19,1 milhões ao longo de 66 dias. Analistas de segurança identificaram a causa raiz como lógica de verificação insuficiente: embora a bridge tenha validado assinaturas de notário, roots de estado e provas de Merkle, ela não confirmou que as quantias de pagamento correspondiam aos ativos bloqueados no lado da Verus, permitindo retiradas sem lastro dos saldos de reservas no Ethereum. O incidente destaca desafios de segurança persistentes na infraestrutura de bridges cross-chain, em que a verificação criptográfica tem sucesso, mas a validação de business logic para lastro de ativos falha.
Invasores exploram bypass de autorização na lógica da bridge
O ataque envolveu uma importação maliciosamente criada a partir do lado da Verus que incluía uma solicitação de pagamento sem lastro no Ethereum. A bridge verificou assinaturas de notary, roots de estado e provas de Merkle, mas falhou em verificar que a quantia de pagamento solicitada correspondia aos ativos bloqueados ou exportados no lado da Verus, de acordo com analistas de segurança.
A Backward Labs afirmou que a causa raiz foi um problema de bypass de autorização e de suposição de estado de protocolo. A bridge aceitou uma importação comprovada que autorizava pagamentos de reservas com múltiplos ativos, mas verificações críticas a montante para criação, autorização, hash da transferência, contagem e lastro econômico foram insuficientes. Uma análise observou: “Desta vez, a mesma causa raiz continuou explorável por 66 dias.”
Várias ferramentas de monitoramento sinalizaram a transação com uma pontuação crítica, citando manipulação de estado, cunhagem arbitrária e saídas de Finanças Descentralizadas (DeFi).
Reservas da bridge perdem ETH, USDC, DAI e seis outros ativos
Os ativos drenados das reservas da bridge incluíram Ether, tBTC, MKR, USDC, Tether, EURC e scrvUSD. Para DAI, a bridge interagiu com uma posição de garantia na Sky (anteriormente MakerDAO) para cunhar cerca de 220.357 DAI a fim de cumprir a solicitação fraudulenta.
A violação de 17 de maio havia roubado aproximadamente US$ 11,6 milhões usando um método semelhante, elevando as perdas combinadas para cerca de US$ 19,1 milhões.
Backward Labs publica prova de conceito e análise da causa raiz
A Backward Labs publicou um relatório e uma prova de conceito destacando o invariante quebrado: “As reservas da bridge do Ethereum só podem ser liberadas para transferências de reserva da cadeia de origem cujas criações de CCE, autorização, hash da transferência, contagem e lastro econômico sejam todos comprovados dentro do ciclo de vida esperado da bridge.”
O exploit destaca desafios contínuos de segurança em bridges cross-chain, em que a verificação criptográfica é bem-sucedida, mas a validação de business logic para lastro de ativos falha. Exploits de bridge continuam sendo um problema recorrente em DeFi, frequentemente levando a perdas não recuperáveis porque transações no blockchain são imutáveis.
Perguntas frequentes
O que aconteceu com a Verus-Ethereum Bridge em 23 de julho?
Invasores exploraram uma falha de bypass de autorização em 23 de julho, drenando de US$ 7,3 milhões a US$ 7,5 milhões em ativos digitais incluindo ETH, USDC, DAI, tBTC, MKR, Tether, EURC e scrvUSD por meio de uma solicitação de importação maliciosamente criada que ignorou a verificação de lastro de ativos.
Por que a mesma vulnerabilidade permaneceu explorável por 66 dias?
O contrato inteligente da bridge falhou em verificar que as quantias de pagamento correspondiam aos ativos bloqueados no lado da Verus. Embora ele tenha validado provas e assinaturas criptográficas, verificações críticas a montante para criação, autorização, hash da transferência, contagem e lastro econômico foram insuficientes, permitindo que o mesmo método de ataque usado em 17 de maio tivesse sucesso novamente em 23 de julho.