Resumo Semanal de Incidentes de Segurança Web3 | 16 a 22 de Mar de 2026

Durante a semana passada (2026/03/16 - 2026/03/22), a BlockSec detectou e analisou sete incidentes de ataque, com perdas totais estimadas de ~$82,7M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

*O incidente Venus não foi coberto no relatório da semana passada e está incluído aqui para fins de completude.

1. Incidente Venus

Resumo Breve

Em 15 de março de 2026, o mercado THE (Thena) do Venus Protocol na BNB Chain sofreu um ataque de doação combinado com manipulação de mercado, resultando em aproximadamente ~$2,15M em dívida inadimplente. O limite de fornecimento do mercado THE se aplicava apenas ao caminho de emissão, enquanto doações diretas de tokens no mercado ainda aumentavam o cash e inflavam o exchangeRate. O atacante então aproveitou esse valor de colateral inflado para tomar emprestado ativos líquidos, adquirir mais THE enquanto impulsionava o preço de mercado do token THE, deixando o protocolo com dívida inadimplente após a liquidação forçada da posição.

Contexto

Venus é um protocolo de empréstimo com fork do Compound V2. No mercado THE, os usuários depositam THE e recebem tokens vTHE. O exchangeRate determina quanto dos ativos subjacentes do mercado cada vTHE representa, e sua fórmula central é:

exchangeRate = (cash + borrows - reserves) / totalSupply

Aqui, cash é o saldo do token subjacente do mercado, borrows é a dívida total em aberto, reserves são as reservas de propriedade do protocolo, e totalSupply é o fornecimento total de vTHE. O mercado THE também possui um limite de fornecimento destinado a limitar a exposição total de colateral.

Análise de Vulnerabilidade

Este incidente envolveu dois vetores compostos contra o contrato do mercado vTHE (0x86e0...739f).

Ataque de Doação

O protocolo deriva o cash diretamente do saldo bruto de tokens do contrato de mercado, tornando-o inerentemente suscetível a ataques de doação. Qualquer transferência direta de THE para o contrato do mercado vTHE aumenta o cash e, portanto, o exchangeRate. O atacante explorou isso para inflar o exchangeRate em aproximadamente 3,81×, amplificando o valor de colateral de sua posição vTHE existente.

Manipulação de Mercado

O token THE tinha liquidez on-chain superficial, tornando seu preço spot suscetível à manipulação por meio de uma pressão de compra relativamente modesta. O Oracle do protocolo foi projetado para rejeitar preços que se desviem muito de uma referência, o que corretamente rejeitou preços extremos por cerca de 37 minutos durante o ataque. No entanto, a pressão de compra sustentada eventualmente elevou o preço do token THE para aproximadamente $0,51, cerca do dobro de seu preço pré-ataque, que o oracle acabou aceitando.

Esses dois vetores se reforçaram mutuamente. O exchangeRate inflado pelo ataque de doação amplificou o valor de colateral de cada unidade vTHE, enquanto o preço manipulado do token THE inflou ainda mais a capacidade de empréstimo. Juntos, eles permitiram que o atacante acumulasse ~$14,9M em empréstimos contra uma posição 3,67× acima do limite de fornecimento.

Análise do Ataque

A análise a seguir é baseada na transação de ataque de exemplo 0xce6e3e...1f5fb0e.

• Passo 1: Uma carteira vinculada ao atacante recebeu 7.447 ETH por meio de 77 transações relacionadas ao TornadoCash ao longo de aproximadamente nove meses. Esse ETH foi depositado no Aave e ~$9,92M em stablecoins foram emprestados para construir uma posição vTHE de cerca de 12,2M THE, aproximadamente 84% do limite de fornecimento de 14,5M THE.

• Passo 2: Na primeira transação de ataque, seis endereços transferiram cerca de 36M THE diretamente para o contrato do mercado vTHE. O contrato de ataque também tomou emprestado 1,58M USDC, re-forneceu-o, depois tomou emprestado cerca de 4,6M THE e o transferiu diretamente para o vTHE. Isso elevou o exchangeRate em cerca de 3,81x.

• Passo 3: Nas transações subsequentes, o atacante tomou emprestado ativos líquidos, incluindo CAKE, BNB, BTCB e USDC. O atacante continuou comprando THE com ativos emprestados e doando mais THE para vTHE, criando um ciclo que aumentou tanto o poder de empréstimo da posição quanto o preço de mercado do token THE.

• Passo 4: O preço do token THE subiu de cerca de $0,20, com a fonte de preço da Binance se aproximando brevemente de $4. O oracle do protocolo rejeitou preços extremos por cerca de 37 minutos antes de finalmente aceitar um preço de cerca de $0,51.

• Passo 5: Às 20h42 UTC+8, a posição do atacante atingiu cerca de 53,2M THE, aproximadamente 3,67x o limite de fornecimento, com exposição total de empréstimos de cerca de ~$14,9M.

• Passo 6: A posição então entrou em grandes liquidações. Cerca de 42M THE em colateral foram liquidados em 8.048 transações de liquidação de 254 endereços de liquidadores. À medida que as vendas continuaram, o token THE caiu para cerca de $0,22. Os rendimentos da liquidação não puderam cobrir a dívida total, deixando a Venus com ~$2,15M em dívida inadimplente líquida.

Conclusão

Este incidente não revelou nenhuma vulnerabilidade nova. Ele demonstrou como um vetor de ataque bem conhecido, executado metodicamente, pode sobrecarregar toda a pilha de risco de um protocolo quando cada camada pressupõe que as outras vão resistir. Os sinais de alerta haviam sido visíveis on-chain por meses, mas a lacuna entre detecção e intervenção permaneceu sem solução. Preencher essa lacuna por meio de parâmetros de risco sensíveis à liquidez, disjuntores automáticos e monitoramento no nível de posição é a lição central que este incidente deixa para outros protocolos de empréstimo.

Para uma análise detalhada, consulte nossa publicação aprofundada [1].

Referências

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. Incidente dTRINITY

Resumo Breve

Em 17 de março de 2026, o dTRINITY, um protocolo de empréstimo com fork do Aave V3 na Ethereum, foi explorado por meio de seu mercado de empréstimos dLEND, resultando em uma perda de ~$257,3K. A causa raiz foi a vulnerabilidade de mercado vazio inerente aos forks do Aave V3. Quando uma reserva possui liquidez próxima de zero, o acúmulo repetido de prêmios de flash loan eleva o liquidityIndex a um valor extremo. Uma vez que a contabilidade da reserva foi distorcida, o atacante explorou a perda de precisão nos caminhos de depósito e saque para superestimar o colateral, tomar emprestado dUSD e recuperar o cbBTC depositado para obter lucro líquido.

Contexto

O dTRINITY inclui o sistema de stablecoin dUSD e o dLEND, um mercado de empréstimos com fork do Aave V3. No contrato central L2Pool (0xfda3...e19e84), cada ativo tem sua própria reserva, e a contabilidade da reserva é baseada em saldos escalados e um liquidityIndex no nível da reserva. O saldo subjacente atual de um usuário é derivado do saldo escalado multiplicado pela renda normalizada da reserva.

Os prêmios de flash loan são adicionados à contabilidade da reserva por meio de cumulateToLiquidityIndex(), onde:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

Quando totalLiquidity se torna extremamente pequeno, cada acúmulo de prêmio pode elevar o liquidityIndex a uma taxa anormalmente rápida.

Análise de Vulnerabilidade

A condição-chave para o ataque foi uma reserva quase vazia no mercado dLEND-cbBTC (0x504d...3acc). Uma vez que a reserva foi comprimida a uma única cota escalada, os prêmios de flash loan deixaram de ser distribuídos por uma base de fornecimento significativa. Repetidos flash loans fizeram, portanto, o liquidityIndex subir extremamente rápido.

Após o liquidityIndex ser inflado, a conversão de subjacente para escalado entrou em um regime extremo de arredondamento. Nesse estado, um pequeno depósito poderia emitir uma cota adicional, enquanto um saque muito maior ainda poderia queimar apenas uma cota. Essa assimetria permitiu que o atacante superestimasse o colateral aCbBTC e tomasse emprestado dUSD real de uma reserva diferente, pois as verificações de saúde eram realizadas no nível do Pool e a reserva cbBTC corrompida afetava diretamente o poder de empréstimo entre ativos.

Análise do Ataque

O exploit consistiu em duas transações: 0x8d33d6...40ae7139 e 0xbec4c8...4fc33260.

Transação 1: Manipulação do liquidityIndex

• Passo 1: Tomar emprestado cbBTC do Morpho Blue.

• Passo 2: Depositar cbBTC no dLEND-cbBTC para emitir 100 cotas escaladas.

• Passo 3: Sacar 99 unidades de cotas para que apenas 1 cota permaneça, comprimindo a reserva dLEND-cbBTC para um estado de fornecimento escalado quase vazio.

• Passo 4: Transferir 80.000.000 unidades de cbBTC (ou seja, 0,8 cbBTC) diretamente para o aToken dLEND-cbBTC.

• Passo 5: Executar 150 chamadas Pool.flashLoan() para acumular prêmio na contabilidade da reserva, elevando o liquidityIndex para 6.226.621.999.999.999.999.999.999.979.728.276.

• Passo 6: Executar ciclos repetidos de depósito e saque para extrair o saldo residual da reserva.

• Passo 7: Reembolsar o flash loan.

Transação 2: realização de lucro

• Passo 1: Tomar emprestado cbBTC novamente do Morpho Blue.

• Passo 2: Depositar ~7,72 cbBTC na reserva já manipulada para construir uma posição de colateral aCbBTC superestimada.

• Passo 3: Usar o colateral superestimado para tomar emprestado 257.328 dUSD do mercado dLEND-dUSD.

• Passo 4: Continuar a extração de cbBTC por meio de ciclos repetidos de depósito/saque.

• Passo 5: Reembolsar o flash loan do Morpho e transferir o dUSD emprestado para a EOA do atacante.

Conclusão

Este incidente é um exemplo do ataque de mercado vazio que foi bem documentado em forks do Aave V3. Esse padrão apareceu em múltiplos protocolos, e a mitigação é bem estabelecida. Impor um limite mínimo de fornecimento durante a inicialização da reserva impede que a reserva entre em um estado onde o crescimento do índice se torna incontrolável. Protocolos que fazem fork do Aave V3 devem, portanto, tratar a inicialização da reserva como uma operação crítica e garantir que liquidez significativa esteja bloqueada no momento da implantação, em vez de depender do fluxo orgânico de depósitos para estabilizar o índice.

3. Incidente Fun.xyz

Resumo Breve

Em 17 de março de 2026, o Fun.xyz, um protocolo de infraestrutura de checkout na Polygon, foi explorado em ~$85,7K. A causa raiz foi que o CheckoutPool legado expunha uma função crítica bridge() sem controle de acesso e sem vincular os dados de chamada da bridge ao destinatário pretendido. Essa vulnerabilidade permitiu que o atacante redirecionasse a execução para o caminho de liquidação confiável e transferisse fundos para uma conta inteligente controlada pelo atacante.

Contexto

CheckoutPool é o contrato central de liquidação na infraestrutura de checkout do Fun.xyz. No fluxo normal, um usuário cria um checkout via deposit(), e um operador confiável o avança pelos caminhos de liquidação, como bridge() e execute(). Para operações de bridge, bridge() executa uma chamada externa com base em bridgeParams.target e bridgeParams.callData fornecidos pelo chamador.

Análise de Vulnerabilidade

A causa raiz é que o CheckoutPool legado (0x1304...2ec01a) expunha um caminho sensível de roteamento de liquidação por meio da função bridge() sem controle de acesso adequado, além de falhar em validar os dados de chamada de bridge fornecidos externamente em relação ao destinatário pretendido. Especificamente:

• A implementação legada não aplicava onlyOperator em bridge(), permitindo que qualquer chamador externo invocasse a função após criar um checkout via deposit().

• bridge() passava os bridgeParams fornecidos pelo chamador para _bridgeToRecipient(), que realizava uma chamada externa sem validar o destinatário em relação ao registro de checkout.

Uma condição operacional adicional tornou o exploit prático: o CheckoutPool legado ainda retinha privilégios de operador no CheckoutPaymaster no momento do exploit. Isso permitiu que a chamada bridge() manipulada chegasse a CheckoutPaymaster.activateAndCall(), que então invocou o caminho mais recente CheckoutPool.execute(), transferindo fundos para um endereço sob controle do atacante.

Análise do Ataque

A análise a seguir é baseada na transação de ataque 0x957bcf...1f4f5a.

• Passo 1: Criar a conta inteligente ERC-4337 0xb648 e designá-la como remetente e pagador na UserOperation externa.

• Passo 2: Chamar deposit() tanto no CheckoutPool legado quanto no novo, criando um registro de checkout no novo CheckoutPool com um valor de liquidação de 85.730 USDC.

• Passo 3: Chamar bridge() no CheckoutPool legado com bridgeParams maliciosos: definir bridgeParams.target como CheckoutPaymaster e codificar bridgeParams.callData como uma chamada para activateAndCall() carregando a UserOperation externa como seu payload interno.

• Passo 4: Alcançar execute() no novo CheckoutPool (0x1929...0215), que transfere 85.730 USDC para 0xb648, o endereço especificado como ops[0].sender na UserOperation externa.

• Passo 5: Entrar em EntryPoint.handleOps(): como 0xb648 serve tanto como remetente quanto como pagador, tanto a validação da conta quanto a validação do pagador permanecem sob controle do atacante, permitindo que o atacante lucre 85.730 USDC.

Conclusão

Este incidente foi causado pelo CheckoutPool legado que carecia tanto de controle de acesso quanto de vinculação de dados de chamada ao destinatário em seu caminho bridge(), resultando em perdas de ~$85,7K. Para prevenir incidentes semelhantes, os protocolos devem impor controle de acesso rigoroso em todos os fluxos sensíveis de roteamento e liquidação, garantir que os payloads fornecidos externamente permaneçam consistentes com os destinatários derivados do protocolo, e remover contratos desatualizados de relacionamentos de privilégio confiável assim que substitutos corrigidos forem implantados.

4. Incidente Keom

Resumo Breve

Em 18 de março de 2026, o Keom, um protocolo de empréstimo com fork do Compound V2 na Polygon zkEVM, foi explorado em aproximadamente $35K. A causa raiz foi uma lógica de contabilidade falha em redeemFresh(), chamada por redeemUnderlying(). A função limitava a redução de cotas ao saldo real do usuário, mas não recalculava o valor de saque subjacente de acordo. Essa inconsistência permitiu que o atacante resgatasse muito mais ativos do que suas cotas deveriam permitir.

Contexto

Keom é um protocolo de empréstimo com fork do Compound V2. Os usuários fornecem ETH ao mercado e recebem kETH. Quando um usuário resgata, o protocolo converte cotas kETH de volta em ETH usando a taxa de câmbio atual. Dois pontos de entrada de resgate existem no protocolo: redeem() para resgatar pelo valor de cotas, e redeemUnderlying() para resgatar pelo valor subjacente desejado.

Análise de Vulnerabilidade

A falha está em redeemFresh() do mercado kETH (0x4c6e...0403), chamada por redeemUnderlying(). O redeemAmountIn controlado pelo usuário é primeiro atribuído a redeemAmount, e então usado para calcular redeemTokens por meio da taxa de câmbio atual. Se redeemTokens exceder o saldo do resgatador, a função o limita a accountTokens[redeemer]. No entanto, redeemAmount não é recalculado após esse limite e permanece igual ao redeemAmountIn original. Isso permite que o resgatador saque o redeemAmount completo de ativos subjacentes enquanto queima apenas uma fração das cotas correspondentes.

Como mostrado no trecho de código abaixo, redeemFresh() também realiza uma verificação de saúde via redeemAllowed(). No design do Compound V2, redeemAllowed() verifica markets[cToken].accountMembership[redeemer] e só invoca a verificação de liquidez quando a conta entrou neste mercado cToken; caso contrário, a verificação é totalmente ignorada. Como redeemAmountIn é controlado pelo atacante e pode ser definido arbitrariamente grande, a verificação de liquidez falharia se kETH ainda contasse como colateral. Isso significa que a falha contábil por si só não é diretamente explorável sem primeiro contornar a verificação de saúde.

Análise do Ataque

A análise a seguir é baseada na transação de ataque 0x4ccde7...03d9dfd8.

• Passo 1: Invocar mint() com apenas 0,001 ETH, obtendo um saldo mínimo de kETH.

• Passo 2: Invocar exitMarket() para remover a participação da conta no mercado kETH, de modo que redeemAllowed() ignore completamente a verificação de liquidez (conforme descrito na Análise de Vulnerabilidade acima).

• Passo 3: Invocar redeemUnderlying() para sacar todo o saldo de ETH do mercado (~38,6 ETH), explorando a contabilidade falha para drenar ETH do mercado.

Conclusão

Este incidente foi causado por uma vulnerabilidade contábil que falha em recalcular redeemAmount após limitar redeemTokens ao saldo real do usuário, resultando em aproximadamente $35K em perdas. A lógica de resgate deve recalcular todos os valores dependentes após qualquer limite ou ajuste para preservar a invariante de cota para subjacente. Forks do Compound V2 devem revisar cuidadosamente esse caminho, pois falhas semelhantes podem existir em outros derivados.

5. Incidente ShiMama

Resumo Breve

Em 18 de março de 2026, o ShiMama, um protocolo de token deflacionário na BNB Chain, foi explorado em aproximadamente $35K. A causa raiz foi a falta de controle de acesso na função executePairBurn(), que permitia que qualquer usuário acionasse a retirada e queima de reservas do par, possibilitando a manipulação de preços.

Contexto

O Protocolo ShiMama inclui um mecanismo de deflação on-chain destinado a retirar tokens do par AMM e queimá-los. Esse mecanismo é implementado no Protocolo ShiMama e no Token ShiMama. A função executePairBurn() no Protocolo ShiMama calcula um valor de retirada a partir de um parâmetro referenceIn fornecido pelo chamador:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Em seguida, chama forcePullFromPair() do Token ShiMama seguido de pair.sync() e a queima dos tokens retirados.

Análise de Vulnerabilidade

A causa raiz é a falta de controle de acesso em executePairBurn() no contrato ShiMamaProtocol (0x5049...0b49a). A função é chamável externamente sem restrição, portanto qualquer usuário pode acionar movimentação privilegiada de reservas e sincronização de par. referenceIn também é controlado pelo chamador e não está vinculado a nenhum valor real de venda. Em ShiMamaToken.forcePullFromPair(), o protocolo pode mover diretamente saldos do par Pancake sem qualquer restrição, permitindo remoção arbitrária de reservas mais sincronização imediata e, portanto, manipulação de preço spot.

Análise do Ataque

A análise a seguir é baseada na transação de ataque 0x13959b...3c20e001.

• Passo 1: Tomar emprestado WBNB do flash loan do Moolah.

• Passo 2: Transferir 30,78e18 ShiMama pré-obtidos em uma transação anterior para o contrato de ataque. Como compras diretas de ShiMama do par Pancake estavam desabilitadas, o atacante obteve ShiMama fornecendo e retirando liquidez no Protocolo ShiMama antes do ataque.

• Passo 3: Chamar executePairBurn() para retirar 1.311.349.143,96 tokens ShiMama do par Pancake e queimá-los, inflando efetivamente o preço do ShiMama.

• Passo 4: O atacante trocou 30,78e18 ShiMama por 52,98e18 WBNB no PancakeSwap ao preço inflado.

• Passo 5: Reembolsar o flash loan, deixando 52,98 WBNB como lucro líquido.

Conclusão

Este incidente foi causado pela falta de controle de acesso em executePairBurn(), que expôs um caminho não autorizado para alterar as reservas do pool. Qualquer função que mute reservas é economicamente sensível e deve ser estritamente permissionada. Entradas controladas pelo chamador devem ser vinculadas a valores derivados do protocolo para evitar a amplificação da extração de reservas.

6. Incidente BlindBox

Resumo Breve

Em 19 de março de 2026, o BlindBox, um protocolo de apostas GameFi na BNB Chain, foi explorado em aproximadamente $99K. A causa raiz foi aleatoriedade fraca, permitindo que o atacante previsse o resultado e alcançasse uma taxa de vitória de 100%. Além disso, getTwapPrice() dependia de precificação spot manipulável em vez de uma verdadeira média ponderada pelo tempo, permitindo que o atacante inflasse o preço do pool antecipadamente e fizesse apostas maiores do que os limites pretendidos pelo protocolo.

Contexto

O BlindBox é um protocolo GameFi que permite aos usuários fazer apostas transferindo tokens ATM para o endereço morto. O protocolo determina o resultado com base na paridade de um blockhash posterior. Se a aposta ganhar, o BlindBox paga 1,95x o valor original de ATM a partir do bankroll do endereço morto. O protocolo usa getTwapPrice() para limitar o tamanho de cada aposta.

Análise de Vulnerabilidade

O contrato BlindBox (0x1F83...734c59) contém duas vulnerabilidades:

1. Aleatoriedade fraca: Quando o tempo de liquidação excede 256 blocos, blockhash(bet.blockNum + 2) retorna zero. O protocolo então recorre a aleatoriedade derivada de block.prevrandao, betId e block.timestamp. Como essas entradas podem ser simuladas off-chain antes de enviar a transação, o atacante poderia invocar settle() apenas quando o resultado calculado fosse favorável, alcançando uma vitória determinística.

2. Limite de preço manipulável: O protocolo usa getTwapPrice() para restringir o tamanho da aposta. No entanto, essa função não implementa um preço médio ponderado pelo tempo verdadeiro; em vez disso, lê o preço spot no pool ATM/USDT. Isso permite que os atacantes contornem o limite manipulando o preço do pool antes de fazer sua aposta.

Análise do Ataque

Os passos a seguir ilustram o padrão de ataque. Os passos 2 e 3 formaram uma sequência pareada (por exemplo, betId=5.284), e o atacante repetiu esse par várias vezes para acumular lucro.

• Passo 1: Manipular o pool ATM/USDT, inflando o preço spot de ATM para que getTwapPrice() permitisse um tamanho de aposta maior no próximo passo.

• Passo 2: Fazer uma aposta grande transferindo o valor ATM com permissão inflada para o endereço morto (por exemplo, 0x4be049...3af12c).

• Passo 3: Aguardar até que mais de 256 blocos tivessem passado, de modo que blockhash retornasse zero e o caminho de fallback fosse ativado. O atacante então simulou resultados off-chain e chamou settle() apenas em um bloco onde o resultado calculado fosse favorável (por exemplo, 0x68eedc...718ce8).

Conclusão

Este incidente foi causado por aleatoriedade previsível, combinada com um preço spot manipulável como entrada de TWAP, resultando em aproximadamente $99K em perdas. Para reduzir riscos semelhantes, o protocolo deve remover qualquer caminho de liquidação que se torne previsível após o vencimento da janela de blockhash, e substituir getTwapPrice() por uma fonte de precificação resistente à manipulação de reservas de curto prazo.

7. Incidente Resolv

Resumo Breve

Em 22 de março de 2026, o Resolv, um protocolo de stablecoin na Ethereum, sofreu um comprometimento de chave de infraestrutura que possibilitou a execução não autorizada de lógica privilegiada de finalização de swap. No incidente, o atacante abusou da função privilegiada para emitir mais de 80M de USR sem colateral. O impacto se estendeu além do evento direto de emissão, pois o depeg resultante de USR desencadeou um contágio mais amplo em protocolos de empréstimo onde ativos Resolv eram usados como colateral.

Contexto

O Resolv é um protocolo de stablecoin no qual a emissão de USR depende da liquidação de swap lastreada em colateral. Seu pipeline de conclusão de swap, completeSwap() -> mint() -> transfer(), afeta diretamente o fornecimento circulante de USR e, portanto, depende tanto da integridade de autorização quanto da integridade do colateral. Em operação normal, completeSwap() no contrato Resolv (0xa27a...5861) é chamável apenas por uma chave de infraestrutura privilegiada (denominada SERVICE_ROLE no código) após o depósito de colateral correspondente ter sido verificado.

Análise de Vulnerabilidade

O incidente foi um comprometimento de chave privilegiada que invocou lógica de liquidação confiável e alcançou o caminho de emissão de USR sem uma entrada equivalente de colateral. Uma vez que o atacante obteve controle da autoridade de assinatura privilegiada, o caminho completeSwap() não fornecia nenhuma imposição de pré-condição de emissão on-chain; a verificação de colateral dependia inteiramente de autorização off-chain. Isso converteu um comprometimento do plano de controle diretamente em uma falha de integridade de fornecimento.

Análise do Ataque

• Passo 1: Antes do exploit, o atacante enviou uma solicitação de swap na transação 0x590b5c...de732c89, preparando o estado necessário para a conclusão maliciosa subsequente do swap.

• Passo 2: Usando a chave privilegiada comprometida, o atacante invocou completeSwap() para emitir mais de 80.000.000 USR em três transações: 0xfe37f2...dc33743, 0x41b6b9...db1f18f e 0x7f9143...53a931d.

Conclusão

Este incidente ressalta que a segurança de stablecoin depende de pré-condições rígidas de emissão on-chain, não apenas de funções de operador confiáveis. Notavelmente, o impacto deste incidente se estendeu muito além dos $80M em emissão não autorizada de USR. Como os ativos Resolv eram amplamente usados como colateral em múltiplos protocolos de empréstimo, o depeg desencadeou um contágio mais amplo. Conforme relatado pela Chaos Labs, curadores on-chain que usavam alocação automatizada de busca de rendimento careciam de controles de risco em tempo real e continuaram direcionando capital recente para mercados já comprometidos. O que começou como um exploit localizado rapidamente escalou para um evento de contágio entre protocolos, deixando os protocolos de empréstimo com milhões em dívida inadimplente.

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam os 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 blockchain em conferências de prestígio, relatou 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 : Envie uma solicitação

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

• 🔗 Phalcon Compliance