Le 15 mai 2024, Sonne Finance a subi une attaque sur la chaîne Optimism, entraînant des pertes allant jusqu’à 20 millions de dollars. Après l’attaque, l’utilisateur de Twitter @tonyke_bot a tweeté qu’il protégeait les 6,5 millions de dollars restants dans le pool de garanties de Sonne Finance (également connu sous le nom de marché, similaire à cToken dans Compound) avec environ 100 dollars.

(https://twitter.com/tonyke_bot/status/1790547461611860182)

Après avoir découvert l’attaque, l’équipe de Sonne Finance a rapidement mis en pause tous les marchés sur Optimism et a déclaré que les marchés sur Base étaient sécurisés.

(https://twitter.com/SonneFinance/status/1790535383005966554)

Brève description

l’attaque Sonne Finance est une protocole de prêt décentralisée qui forke Compound V2 sur Optimism, fournissant aux particuliers, aux institutions et aux protocoles un accès aux services financiers. Le protocole Sonne Finance agrège les actifs symboliques des utilisateurs pour former un pool de liquidité de prêt, offrant aux utilisateurs une activité de prêt de type bancaire. Comme Compound, les participants au protocole peuvent hypothéquer leurs jetons dans le pool de liquidité de prêt de Sonne Finance et obtenir le certificat soToken (identique à cToken). SoToken est un certificat d’actif portant intérêt, qui générera un certain montant de revenus au fur et à mesure de la progression du bloc, et recevra également des incitations SONE token. Les participants peuvent également emprunter d’autres tokens du pool d’actifs de prêt Sonne avec le soToken dans leurs mains. Par exemple, les participants peuvent hypothéquer un certain montant d’USDC pour obtenir des certificats soUSDC, puis prêter des WETH pour une circulation ultérieure. Les prêts hypothécaires dans le protocole Sonne Finance peuvent être une relation d’actifs plusieurs-à-plusieurs. Pendant le processus de prêt hypothécaire, le protocole calculera automatiquement le facteur de santé (facteur de santé) de l’adresse du participant. Lorsque le facteur de santé est inférieur à 1, l’hypothèque de l’adresse Produits sera support liquidation, et les liquidateurs peuvent également recevoir certaines récompenses liquidation.

La relation entre le nombre de tokens sous-jacents déposés par les utilisateurs et les soTokens minés est principalement liée à une variable appelée exchangeRate. Cette variable peut être grossièrement utilisée pour indiquer la valeur de chaque token sous-jacent à chaque soToken. La formule de calcul de changeRate est la suivante :

Dans la formule ci-dessus, totalCash fait référence au nombre de tokens sous-jacents détenus par soToken, totalBorrows fait référence au nombre de tokens sous-jacents prêtés sur un certain marché, totalReserves fait référence au montant total de la réserve (y compris les intérêts payés par l’emprunteur), totalSupply fait référence au nombre de soToken frappés.

Lors de l’échange, les utilisateurs peuvent spécifier le nombre de jetons sous-jacents qu’ils souhaitent échanger, redeemAmount, pour calculer le nombre de soTokens qui doivent être détruits, redeemTokens. La méthode de calcul est grosso modo « redeemTokens = redeemAmount / exchangeRat ». Notez qu’il n’y a pas de perte de précision ici. s’en occuper.

L’essence de cette attaque est que lorsque le marché (soToken) a été créé, l’attaquant a effectué la première opération de coulée hypothécaire et a frappé très peu de soTokens avec une petite quantité de tokens sous-jacents, ce qui a entraîné une valeur « totalSupply » de soToken trop faible. L’attaquant a ensuite exploité la vulnérabilité de la perte de précision du contrat Solidity, puis a envoyé le jeton sous-jacent directement au contrat soToken (soToken ne sera pas frappé, ce qui signifie que « totalSupply » reste inchangé et que « totalCash » devient plus grand) au lieu de jalonner + méthode de moulage pour déposer le jeton sous-jacent. Une telle opération fait que la variable « totalCash » dans le contrat devient plus grande, mais « totalSupply » reste inchangé, ce qui fait que changeRate devient plus grand. En fin de compte, lorsque l’attaquant rachète le jeton sous-jacent, le soToken qui doit être détruit est inférieur au soToken émis pendant l’hypothèque. L’attaquant utilise le soToken gagné pour prêter le jeton sous-jacent WETH et USDC à d’autres soTokens (tels que soWETH, soUSDC), et obtient finalement des bénéfices allant jusqu’à 20 millions de dollars.

Adresses clés impliquées dans l’attaque

Transactions de préparation à l’attaque :

https://optimistic.etherscan.io/tx/0x45c0ccfd3ca1b4a937feebcb0f5a166c409c9e403070808835d41da40732db96

Attaquez les transactions rentables :

https://optimistic.etherscan.io/tx/0x9312ae377d7ebdf3c7c3a86f80514878deb5df51aad38b6191d55db53e42b7f0

Adresses liées à l’EOA de l’attaque :

0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43

Adresse liée à l’attaquant (contrat) :

0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

0x02fa2625825917e9b1f8346a465de1bbc150c5b9

jeton sous-jacent (VELO Jeton V2) :

0x9560e827af36c94d2ac33a39bce1fe78631088db

Contrat de vulnérabilité (soVELO, similaire au cToken de Compound) :

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5

@tonyke_bot Transaction de sauvetage de l’utilisateur sur X :

https://optimistic.etherscan.io/tx/0x816f9e289d8b9dee9a94086c200c0470c6456603c967f82ab559a5931fd181c2

Attack process analysis

L’équipe du projet Sonne Finance a récemment adopté une proposition visant à ajouter le marché VELO à Sonne Finance (https://twitter.com/SonneFinance/status/1786871066075206044), et a organisé cinq transactions via le portefeuille multi-signatures pour être exécutées deux jours plus tard ( https://optimistic.etherscan.io/tx/0x18ebeb958b50579ce76528ed812025949dfcff8c2673eb0c8bc78b12ba6377b7), ces cinq transactions sont utilisées pour créer le marché VELO (contrat soVELO) et définir certaines configurations clés du marché, telles que la définition du modèle de taux d’intérêt, la définition de l’oracle des prix, la définition des facteurs hypothécaires, etc. Une fois le marché VELO créé, les utilisateurs peuvent dépôt VELO des tokens pour mint des tokens soVELO, qui peuvent à leur tour être utilisés pour emprunter d’autres soTokens.

préparation de l’attaque

L’étape de préparation de l’attaque consiste principalement pour l’attaquant à créer un marché VELO (contrat soVELO) basé sur les informations contenues dans la proposition de projet Sonne Finance après l’expiration de la période de blocage de deux jours de la proposition, mettre en place des configurations clés et mint VELO des tokens dans le contrat soVELO en les hypothéquant. soVELO, et envoie également les tokens VELO qu’il détient directement au contrat soVELO pour augmenter le taux de change et préparer pour tirer profit d’attaques ultérieures.

Les étapes spécifiques sont les suivantes :

1. À la fin de la période de blocage de deux jours, l’attaquant regroupe d’abord les opérations des quatre premières transactions organisées dans la proposition en une seule transaction (transaction 0x45c0cc), qui est utilisée pour créer le marché VELO (contrat soVELO) et définir la configuration de la clé. Lorsque VELO market est initialisé, exchangeRate est défini sur « 200,000,000,000,000,000,000,000,000,000 ».

2. L’attaquant appelle la fonction « mint » du contrat soVELO pour dépôt VELO des tokens et mint des tokens soVELO. L’attaquant spécifie « mintAmount » comme « 400,000,001 » (le nombre de jetons VELO). Comme on peut le voir dans la fonction « exchangeRateStoredInternal », puisque le « _totalSuppl » du jeton soVELO est de 0 à ce moment-là, exchangeRate est la valeur définie à l’étape 1. Selon la formule " mintTokens = actualMintAmount / exchangeRate « , le nombre calculé de jetons soVELO qui doivent être frappés à ce moment est de 2. Dans short, dans cette étape, l’attaquant dépose VELO jetons d’une valeur de « 400 000 001 » dans le contrat soVELO, et l’attaquant obtient des jetons soVELO d’une valeur de 2.

soVELO.mint :

1. L’attaquant a envoyé des jetons VELO d’une valeur de « 2 552 964 259 704 265 837 526 » au contrat soVELO en envoyant directement des jetons VELO au contrat soVELO. À ce moment, le nombre de jetons VELO détenus par le contrat soVELO a augmenté, mais comme il n’y avait pas de nouveaux jetons soVELO Le jeton est frappé, donc totalSupply reste inchangé, ce qui signifie que le taux de change calculé selon la formule de calcul changeRate deviendra plus grand à ce moment-là.

2. L’attaquant a transféré les jetons soVELO détenus à plusieurs reprises, puis les a finalement transférés vers un autre 0xae4a EOA d’attaque.

Attaque à but lucratif

La phase de profit de l’attaque implique principalement que l’attaquant exécute la cinquième transaction de la proposition et prête VELO jetons directement au contrat soVELO par le biais de prêts flash pour augmenter encore le taux de change. Ensuite, l’attaquant utilise le jeton soVELO avec une valeur de 2 dans sa main pour emprunter des jetons sous-jacents tels que WETH et USDC à d’autres contrats soToken (tels que soWETH, soUSDC, etc.), et ces parties deviennent le profit de l’attaquant. Ensuite, l’attaquant est allé racheter son jeton sous-jacent dans le contrat soVELO. En raison de l’augmentation du taux de change et de la perte de précision dans le calcul des jetons soVELO qui doivent être détruits pour le rachat, l’attaquant n’a finalement utilisé que le jeton soVELO d’une valeur de 1. Presque tous les jetons VELO précédemment déposés ont été échangés, ce qui peut être compris comme l’attaquant utilisant les jetons soVELO supplémentaires d’une valeur de 1 pour gagner des jetons sous-jacents tels que WETH et USDC en empruntant à d’autres soTokens. L’attaquant a utilisé la même technique pour répéter l’attaque plusieurs fois et a finalement réalisé d’énormes profits.

Les étapes spécifiques sont les suivantes :

1. L’attaquant exécute la cinquième transaction de la proposition et définit le facteur de prêt spécifié dans la proposition.

2. L’attaquant prête flash des jetons VELO d’une valeur de « 35 469 150 965 253 049 864 450 449 » du pool VolatileV2 AMM - USDC/VELO, ce qui déclenche la fonction de crochet de l’attaquant. Dans la fonction hook, l’attaquant continue d’effectuer l’opération d’attaque.

3. L’attaquant envoie les jetons VELO qu’il détient au contrat soVELO pour augmenter encore le taux de change. Actuellement, il y a un total de jetons VELO d’une valeur de « 35 471 703 929 512 754 530 287 976 » dans le contrat soVELO (la somme des jetons VELO transférés en trois fois par l’attaquant).

4. L’attaquant crée un nouveau contrat 0xa16388a6210545b27f669d5189648c1722300b8b. Dans le constructeur, il transfère les 2 tokens soVELO qu’il détient au 0xa163 de contrat nouvellement créé (ci-après dénommé le 0xa163 de l’attaquant).

5. L’attaquant a 0xa163 utilisé les jetons soVELO qu’il détenait pour emprunter des WETH d’une valeur de « 265 842 857 910 985 546 929 » à soWETH.

6. L’attaquant appelle 0xa163 la fonction « redeemUnderlying » de soVELO, spécifiant la valeur des tokens VELO échangés comme suit : « 35 471 603 929 512 754 530 287 976 » (presque le nombre de tokens VELO que l’attaquant a précédemment transférés ou hypothéqués dans le contrat soVELO). À l’heure actuelle, il est nécessaire de La formule « redeemTokens = redeemAmountIn / exchangeRate » est utilisée pour calculer le nombre de tokens soVELO qui doivent être détruits pour le rachat.

Comme on peut le voir dans la fonction « exchangeRateStoredInternal », puisque _totalSupply vaut 2 au lieu de 0, la valeur de exchangeRate doit être calculée. Selon la formule « exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply », le taux de change actuel est « 17,735,851,964,756,377,265,143,988,000,0 00,000,000,000,000 », cette valeur est beaucoup plus grande que le changeRate initial fixé « 200,000,000,000,000,000,000,000,000,000 ».

La valeur de " redeemTokens " calculée sur la base du nouveau changeRate est de " 1.99 « . En raison des caractéristiques d’arrondi à la baisse de Solidity, la valeur de " redeemTokens " finit par être de 1. Cela signifie que l’attaquant 0xa163 utilisé des tokens soVELO d’une valeur de 1 pour racheter la quasi-totalité des tokens VELO précédemment déposés. Dans le même temps, l’attaquant 0xa163 également gagné WETH d’une valeur de « 265 842 857 910 985 546 929 » empruntés à soWETH.

soVELO.redeemSous-jacent :

soVELO.exchangeRateStoredInternal :

1. L’attaquant a 0xa163 transféré tous les WETH empruntés et échangé VELO jetons à l’attaquant de niveau supérieur, puis s’est autodétruit.

2. L’attaquant appelle la fonction « liquidateBorrow » de soWETH pour liquider certains des actifs empruntés au contrat nouvellement créé 0xa163 en ordre de récupérer le jeton soVELO verrouillé d’une valeur de 1. Actuellement, l’attaquant ne détient que des jetons soVELO d’une valeur de 1.

3. L’attaquant appelle la fonction « mint » de soVELO et hypothèque et frappe à nouveau des jetons soVELO dans le but de rassembler suffisamment de jetons soVELO d’une valeur de 2, puis effectue à nouveau les étapes 3 à 8 ci-dessus pour profiter d’autres jetons undeyment.

4. L’attaquant effectue plusieurs fois l’opération de l’étape 9, rembourse le prêt flash et quitte le marché avec un bénéfice.

Comment 100 $ mobilisent 6,5 millions de

dollars Après l’attaque, l’utilisateur @tonyke_bot sur X a frappé 0,00000011 soVELO en jalonnant 1144 jetons VELO dans le contrat soVELO dans la transaction 0x0a284cd. La raison pour laquelle cette opération peut empêcher l’attaquant de nouvelles attaques est que cette transaction modifie la taille de totalSupply dans soVELO et le nombre de jetons VELO totalCash détenus, et l’impact de la croissance de totalSupply sur le calcul de changeRate est supérieur à l’impact de la croissance de totalCash. Par conséquent, le taux de change devient plus petit, ce qui empêche l’attaquant d’utiliser plus long la perte de précision pour gagner des soVELO lors de la conduite d’une attaque, ce qui rend l’attaque plus longue possible.

Suivi de l’argent

L’attaquant a transféré les fonds peu de temps après s’être emparé des produits illégaux. La plupart des fonds ont été transférés aux quatre adresses suivantes. Certains devaient changer d’adresse pour poursuivre l’attaque, et d’autres pour blanchiment d’argent :

1、0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

L’attaquant a transféré 198 WETH à cette adresse, puis l’adresse a utilisé la même méthode d’attaque pour obtenir des gains illégaux dans les transactions suivantes :

Après l’attaque, l’adresse a transféré les gains illégaux mentionnés ci-dessus à 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.

2、0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

L’attaquant a transféré 724277 USDC et 2353 VELO à cette adresse et a échangé USDC contre Éther. Ensuite, certains fonds ont été immédiatement transférés à la cross-chain bridge Stargate. La plupart des fonds illicites restent à l’adresse suivante :

3、0xbd18100a168321701955e348f03d0df4f517c13b

L’attaquant a transféré 33 WETH à cette adresse et a utilisé la chaîne peel pour tenter de blanchir de l’argent. Le lien avec le blanchiment d’argent est le suivant :

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003 093c2b4 -> 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795。

4、0x4fac0651bcc837bf889f6a7d79c1908419fe1770

L’attaquant a transféré 563 WETH à cette adresse, puis à 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, sans autre action jusqu’à présent.

La méthode de blanchiment d’argent de l’attaquant est cette fois-ci relativement professionnelle, et les méthodes montrent une tendance à la diversité. Par conséquent, pour nous, participants Web3, nous devons continuer à améliorer nos capacités de lutte contre le blanchiment d’argent en termes de sécurité et améliorer la sécurité des projets Defi grâce à KYT, AML et d’autres produits de sécurité des transactions blockchain connexes.

Conseils de sécurité

1、Tenez-vous au courant de l’audit et des tests des contrats. Effectuez un audit complet avant le déploiement des contrats intelligents, en accordant une attention particulière à toutes les parties impliquant des calculs financiers. Tout d’abord, utilisez des tests automatisés et tirez parti des mises à jour en temps réel des bibliothèques de vulnérabilités pour effectuer des analyses de sécurité contractuelles efficaces (l’industrie a également progressivement ouvert certains outils d’audit de sécurité matures, notamment ZAN AI SCAN), tout en combinant l’audit manuel pour résoudre les problèmes qui nécessitent un savoir-faire approfondi de l’industrie.

2、La perte de précision doit être prise au sérieux. Les problèmes de sécurité causés par la perte de précision sont infinis, en particulier dans les projets Defi, où la perte de précision entraîne souvent de graves pertes financières. Il est recommandé que les parties du projet et les auditeurs de sécurité examinent attentivement les codes présentant une perte de précision dans le projet et effectuent des tests pour éviter autant que possible cette vulnérabilité.

1. Il est recommandé que la création d’un marché similaire à cToken dans Compound et l’opération de première hypothèque soient effectuées par des utilisateurs privilégiés pour éviter d’être manipulés par des attaquants et ainsi manipuler le taux de plateforme d’échange.

2. Lorsqu’il y a des variables clés dans le contrat qui dépendent de la valeur de " this.balance " ou " token.balanceOf() « , vous devez examiner attentivement les conditions de modification de la variable clé, par exemple s’il est autorisé à transférer directement de la monnaie native ou des jetons vers le contrat. pour modifier la valeur de la variable, ou la valeur de la variable ne peut-elle être modifiée qu’en appelant une fonction spécifique.

ZAN]. Tous les droits d’auteur appartiennent à l’auteur original [ZAN]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.