Trocar 200 mil por quase 100 milhões, a stablecoin DeFi sofre novo ataque

null

Escrito por Eric, Foresight News

Por volta das 10:21, hora de Pequim, a Resolv Labs, que utilizou a estratégia neutra Delta para emitir a stablecoin USR, foi hackeada. Endereços que começam por 0x04A2 cunhados 50 milhões de USR do protocolo Resolv Labs com 100.000 USDC.

À medida que o incidente veio a público, a USR caiu para cerca de $0,25 e recuperou para cerca de $0,8 à data da redação. O preço do token RESOLV também registou uma queda máxima de quase 10% num curto espaço de tempo.

Depois disso, o hacker inventou o mesmo método e cunhou novamente 30 milhões de USR com 100.000 USDC. Com a significativa desancoragem da USR, os traders de arbitragem também agiram rapidamente, muitos mercados de empréstimos em Morpho que apoiam a USR, wstUSR, etc., como garantia foram quase esgotados, e a Lista DAO na BNB Chain também suspendeu novos pedidos de empréstimo.

Não são apenas estes acordos de crédito que são afetados. No design do protocolo Resolv Labs, os utilizadores também podem cunhar um token RLP com maiores flutuações de preço e rendimentos mais elevados, mas devem ser responsáveis por compensação caso o protocolo sofra perdas. Atualmente, existem quase 30 milhões de tokens RLP em circulação, sendo que o maior detentor, Stream Finance, detém mais de 13 milhões de RLP, com uma exposição líquida de aproximadamente 17 milhões de dólares.

É verdade, o Stream Finance, que já foi atingido uma vez pelo xUSD, pode voltar a ser criticamente atingido.

No momento da redação, o hacker converteu USR em USDC e USDT e continua a comprar Ethereum, com mais de 10.000 até agora. Usando 200.000 USDC para levantar mais de 20 milhões de dólares em ativos, o hacker encontrou a “moeda 100x” pertencente à TA durante o mercado em baixa.

Mais uma vez, foi explorado por “falta de rigor”

A forte queda de 11 de outubro do ano passado levou muitas stablecoins emitidas com a estratégia delta-neutra a perderem garantias devido à ADL (desalavancagem automática). Alguns ativos que usam altcoins como estratégia de execução chegaram mesmo a sofrer grandes perdas em projetos ou até fugiram.

O projeto anunciou em abril de 2025 que tinha concluído uma ronda inicial de financiamento de 10 milhões de dólares liderada pela Cyber.Fund e Maven11, com a participação da Coinbase Ventures, e lançou o token RESOLVE no final de maio e início de junho.

No entanto, a razão para o ataque à Resolv Labs não é o mercado extremo, mas a “falta de rigor” no design do mecanismo de cunhagem de USR.

Atualmente, não existe nenhuma empresa de segurança ou análise oficial das razões deste incidente de invasão. A comunidade DeFi YAM concluiu inicialmente, através da análise, que o ataque é provavelmente causado por hackers que controlam o SERVIÇO_ROLE usado para fornecer parâmetros para a cunha de contratos no backend do protocolo.

De acordo com a análise do Grok, quando os utilizadores minham USR, iniciam um pedido on-chain e chamam a função requestMint do contrato, com parâmetros que incluem:

_depositTokenAddress: O endereço do token depositado;

_amount: Quantidade depositada;

_minMintAmount: A quantidade mínima de USR (ponto antiderrapante) esperada a ser recebida.

Depois disso, o utilizador deposita USDC ou USDT no contrato, e o backend SERVICE_ROLE do projeto monitoriza o pedido, usa o oráculo Pyth para verificar o valor dos ativos depositados e depois chama a função completeMint ou completeSwap para determinar o montante real de USR cunhado.

O problema é que o contrato de cunhagem confia totalmente no _mintAmount fornecido pelo SERVICE_ROLE, acreditando que o número foi verificado pelo Pyth off-chain, pelo que não existe limite superior nem verificação por oráculo on-chain, e o mint(_mintAmount é executado diretamente.

Com base nisto, o YAM suspeitou que o hacker assumiu o controlo do SERVIÇO_ROLE que deveria ser controlado pela equipa do projeto (possivelmente devido à perda de controlo do oráculo interno, auto-roubo do guarda ou roubo da chave), e definiu diretamente _mintAmount para 50 milhões durante a cunhagem, realizando o ataque de cunhar 50 milhões de USR com 100.000 USDC.

Na análise final, a Grok concluiu que a Resolve não considerou a possibilidade de que o endereço (ou contrato) usado para receber pedidos de cunhagem dos utilizadores fosse controlado por hackers ao desenhar o protocolo, e quando o pedido para cunhar USR foi submetido ao contrato que cunhou o USR, não definiu um montante máximo de cunha, nem permitiu que o contrato utilizasse um oráculo on-chain para verificação secundária, confiando diretamente em todos os parâmetros fornecidos pelo SERVICE_ROLE.

Também não existe prevenção

Para além de especular sobre as razões do ataque, o YAM também apontou a falta de preparação da equipa do projeto para lidar com a crise.

O YAM disse no X que a Resolv Labs suspendeu o protocolo apenas 3 horas após o primeiro ataque do hacker ter sido concluído, com um atraso de cerca de 1 hora na recolha das 4 assinaturas necessárias para transações multi-assinatura. O YAM acredita que as pausas de emergência devem exigir apenas uma assinatura, e que as permissões devem ser atribuídas a membros da equipa ou operadores externos de confiança tanto quanto possível, o que pode aumentar a atenção a anomalias on-chain, aumentar a probabilidade de pausas rápidas e cobrir melhor diferentes fusos horários.

Embora a sugestão de que uma única assinatura possa ser suspensa seja algo agressiva, são necessárias várias assinaturas em diferentes fusos horários para suspender um acordo em caso de emergência que possa atrasar grandes coisas. Introduzir uma terceira parte de confiança que monitoriza continuamente o comportamento on-chain, ou usar ferramentas de monitorização com suspensão de protocolo de emergência, são todas “consequências” causadas por este incidente.

Os ataques dos hackers a protocolos DeFi há muito que não se limitam a vulnerabilidades contrárias, e o incidente do Resolv Labs serve de aviso para as partes do projeto: a suposição em termos de segurança do protocolo deve ser que nenhum deles pode ser confiável, e todas as ligações envolvendo parâmetros devem ser verificadas pelo menos duas vezes, mesmo que o backend seja operado pela própria parte do projeto.