Échanger 200 000 contre près d’un milliard, les stablecoins DeFi à nouveau attaqués

null

Écrit par Eric, Foresight News

Vers 10h21, heure de Pékin, aujourd’hui, Resolv Labs, qui a utilisé la stratégie neutre Delta pour émettre le stablecoin USR, a été piraté. Les adresses commençant par 0x04A2 frappées 50 millions d’USR à partir du protocole Resolv Labs avec 100 000 USDC.

Lorsque l’incident a été révélé, USR est tombé à environ 0,25 $ et s’est redressé à environ 0,8 $ au moment de la rédaction. Le prix du token RESOLV a également connu une baisse maximale de près de 10 % en peu de temps.

Après cela, le pirate a conçu la même méthode et a frappé à nouveau 30 millions de USR avec 100 000 USDC. Avec le désancrage important de l’USR, les traders d’arbitrage ont également agi rapidement, de nombreux marchés de prêt sur Morpho qui soutiennent USR, wstUSR, etc. comme garanties ont été presque vidés, et Lista DAO sur BNB Chain a également suspendu de nouvelles demandes d’emprunt.

Ce ne sont pas seulement ces contrats de prêt qui sont affectés. Dans la conception du protocole Resolv Labs, les utilisateurs peuvent également frapper un token RLP avec des fluctuations de prix plus importantes et des rendements plus élevés, mais doivent être tenus responsables d’une compensation si le protocole subit des pertes. Actuellement, près de 30 millions de jetons RLP sont en circulation, le plus grand détenteur, Stream Finance, détenant plus de 13 millions de RLP, avec une exposition nette d’environ 17 millions de dollars.

C’est exact, Stream Finance, qui a déjà été touché une fois par xUSD, pourrait à nouveau être gravement touché.

Au moment de la rédaction, le hacker a converti l’USR en USDC et USDT et continue d’acheter Ethereum, avec plus de 10 000 jusqu’à présent. Utilisant 200 000 USDC pour retirer plus de 20 millions de dollars d’actifs, le pirate a découvert la « pièce 100x » appartenant à TA pendant le marché baissier.

Une fois de plus, il a été exploité pour « manque de rigueur »

La forte baisse du 11 octobre de l’année dernière a fait perdre de nombreuses stablecoins émises selon la stratégie delta-neutre à perdre des garanties dues à l’ADL (deleveraging automatique). Certains actifs qui utilisent les altcoins comme stratégie d’exécution ont même subi de lourdes pertes de projets ou même s’échappent.

Le projet a annoncé en avril 2025 avoir finalisé un tour de financement initial de 10 millions de dollars mené par Cyber.Fund et Maven11, avec la participation de Coinbase Ventures, et a lancé le token RESOLVE fin mai et début juin.

Cependant, la raison de cette attaque contre Resolv Labs n’est pas le marché extrême, mais le « manque de rigueur » dans la conception du mécanisme de frappe de l’USR.

À l’heure actuelle, aucune société de sécurité ni analyse officielle n’existe des raisons de cet incident de piratage. La communauté DeFi YAM a initialement conclu, par analyse d’analyse, que l’attaque est probablement causée par des hackers contrôlant le SERVICE_ROLE utilisé pour fournir les paramètres de la création de contrats sur le backend du protocole.

Selon l’analyse de Grok, lorsque les utilisateurs frappent l’USR, ils lancent une requête en chaîne et appellent la fonction requestMint du contrat, avec des paramètres tels que :

_depositTokenAddress : L’adresse du jeton déposé ;

_amount : Quantité déposée ;

_minMintAmount : La quantité minimale de USR (point antiglissement prévue) attendue à recevoir la source.

Ensuite, l’utilisateur dépose des USDC ou des USDT dans le contrat, et le SERVICE_ROLE du projet en backend surveille la demande, utilise l’oracle Pyth pour vérifier la valeur des actifs déposés, puis appelle la fonction completeMint ou completeSwap pour déterminer le montant réel de l’USR frappé.

Le problème, c’est que le contrat de frappe fait entièrement confiance aux _mintAmount fournis par SERVICE_ROLE, croyant que le nombre a été vérifié par Pyth hors chaîne, donc il n’y a pas de limite supérieure ni de vérification par oracle on-chain, et mint(_mintAmount est exécuté directement.

Sur cette base, YAM soupçonnait que le hacker avait pris le contrôle du SERVICE_ROLE qui était censé être contrôlé par l’équipe du projet (peut-être en raison de la perte de contrôle de l’oracle interne, de l’auto-vol du garde ou du vol de la clé), et avait directement fixé _mintAmount à 50 millions lors de la frappe, réalisant ainsi l’attaque de frapper 50 millions USR avec 100 000 USDC.

En fin de compte, Grok a conclu que Resolve n’avait pas envisagé la possibilité que l’adresse (ou le contrat) utilisée pour recevoir les demandes de frappe des utilisateurs soit contrôlée par des hackers lors de la conception du protocole, et que lorsque la demande de frappe d’USR a été soumise au contrat qui a frappé l’USR, elle n’a pas fixé de montant maximal de frappe, ni permis au contrat d’utiliser un oracle en chaîne pour une vérification secondaire, en faisant directement confiance à tous les paramètres fournis par SERVICE_ROLE.

La prévention n’est pas non plus en place

En plus de spéculer sur les raisons du piratage, YAM a également souligné le manque de préparation de l’équipe projet face à la crise.

YAM a indiqué sur X que Resolv Labs a suspendu le protocole seulement 3 heures après la première attaque du hacker, avec un délai d’environ une heure entre la collecte des 4 signatures nécessaires aux transactions multi-signatures. YAM estime que les pauses d’urgence ne devraient nécessiter qu’une signature, et que les permissions devraient être attribuées autant que possible aux membres de l’équipe ou aux opérateurs externes de confiance, ce qui peut accroître l’attention sur les anomalies en chaîne, augmenter la probabilité de pauses rapides et mieux couvrir différents fuseaux horaires.

Bien que la suggestion qu’une seule signature puisse être suspendue soit quelque peu agressive, il faut plusieurs signatures à travers différents fuseaux horaires pour mettre un accord en pause en cas d’urgence qui pourrait retarder de grandes choses. Introduire un tiers de confiance qui surveille en continu le comportement en chaîne, ou utiliser des outils de surveillance avec suspension d’urgence des protocoles, sont autant de « conséquences » provoquées par cet incident.

Les attaques des hackers contre les protocoles DeFi ne se limitent pas depuis longtemps aux vulnérabilités contractuelles, et l’incident Resolv Labs sert d’avertissement aux parties du projet : l’hypothèse en termes de sécurité des protocoles doit être qu’aucun d’eux n’est digne de confiance, et que tous les liens impliquant des paramètres doivent être vérifiés au moins deux fois, même si le backend est opéré par la partie projetuse elle-même.