Analyse des attaques de Sonne Finance : comment 100 $ peuvent-ils générer 6,5 millions de dollars ? L'essence de cette attaque est que lorsque le marché (soToken) a été créé, l'attaquant a effectué la première opération de moulage d'hypothèques et a créé très peu de soTokens avec une petite quantité de jetons sous-jacents, ce qui a rendu la valeur « totalSupply » de soToken trop petite. L'attaquant a ensuite exploité la vulnérabilité de perte de précision du contrat Solidity, puis a envoyé le jeton sous-jacent directement au contrat soToken (soToken ne sera pas émis, ce qui signifie que "totalSupply" reste inchangé et "totalCash" devient plus grand) au lieu de la méthode de jalonnement + casting. pour déposer le jeton sous-jacent. Une telle opération rend la variable « totalCash » dans le contrat plus grande, mais « totalSupply » reste inchangé, ce qui entraîne une augmentation de changeRate. 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 lors de 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 pouvant atteindre 20 millions de dollars américains.
Le 15 mai 2024, Sonne Finance a été attaquée sur la chaîne Optimisme, entraînant des pertes pouvant atteindre 20 millions de dollars. Après l'attaque, l'utilisateur @tonyke_bot sur
(https://twitter.com/tonyke_bot/status/1790547461611860182)
Après que le projet Sonne Finance ait découvert l'attaque, il a rapidement suspendu tous les marchés sur Optimism et a déclaré que les marchés sur Base étaient sûrs.
(https://twitter.com/SonneFinance/status/1790535383005966554)
Sonne Finance est un protocole de prêt décentralisé qui a dérivé le composé V2 sur l'optimisme pour les particuliers, les institutions et l'accord d'accès aux services financiers. Le protocole Sonne Finance regroupe les actifs symboliques des utilisateurs pour former un pool de liquidités 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és 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 en jetons SONE. Les participants peuvent également emprunter d'autres jetons du pool d'actifs de prêt Sonne avec le soToken en main. Par exemple, les participants peuvent hypothéquer un certain montant d'USDC pour obtenir des certificats soUSDC, puis prêter du WETH pour une circulation ultérieure. Les prêts hypothécaires dans le protocole Sonne Finance peuvent être une relation d'actifs plusieurs à plusieurs. Au cours du 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 soutiendra la liquidation, et les liquidateurs peuvent également recevoir certaines récompenses de liquidation.
La relation entre le jeton sous-jacent déposé par l'utilisateur et le soToken émis est principalement liée à une variable appelée ExchangeRate. Cette variable peut être grossièrement utilisée pour indiquer la valeur du jeton sous-jacent que chaque soToken. La formule de calcul de changeRate est la suivante :
Dans la formule ci-dessus, totalCash fait référence au nombre de jetons sous-jacents détenus par soToken, totalBorrows fait référence au nombre de jetons sous-jacents prêtés sur un certain marché et totalReserves fait référence à le nombre total de réserves (qui contient les intérêts payés par l'emprunteur), totalSupply fait référence au nombre de soTokens émis.
Lors du rachat, les utilisateurs peuvent spécifier le nombre de jetons sous-jacents qu'ils souhaitent racheter, racheterAmount, pour calculer le nombre de soTokens qui doivent être détruits, racheterTokens La méthode de calcul est approximativement "redeemTokens = racheterAmount / changeRat". Il n'y a pas de précision ici.
L'essence de cette attaque est que lorsque le marché (soToken) a été créé, l'attaquant a effectué la première opération de moulage d'hypothèque et a créé très peu de soTokens avec une petite quantité de jetons sous-jacents, ce qui a rendu la valeur « totalSupply » de soToken trop petite. . L'attaquant a ensuite exploité la vulnérabilité de perte de précision du contrat Solidity, puis a envoyé le jeton sous-jacent directement au contrat soToken (soToken ne sera pas émis, ce qui signifie que "totalSupply" reste inchangé et "totalCash" devient plus grand) au lieu de la méthode de jalonnement + casting. pour déposer le jeton sous-jacent. Une telle opération rend la variable « totalCash » dans le contrat plus grande, mais « totalSupply » reste inchangé, ce qui entraîne une augmentation de changeRate. 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 lors de 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 pouvant atteindre 20 millions de dollars américains.
Transactions de préparation de l'attaque :
https://optimistic.etherscan.io/tx/0x45c0ccfd3ca1b4a937feebcb0f5a166c409c9e403070808835d41da40732db96
Transactions de profit d'attaque :
https://optimistic.etherscan.io/tx/ 0x9312ae377d7ebdf3c7c3a86f80514878deb5df51aad38b6191d55db53e42b7f0
adresse associée à l'attaque EOA :
0x5d0d99e9886581ff8fcb01f35804317f5ed80 bbb
0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43
Attaquant (contrat ) adresse associée :
0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8
0x02fa 2625825917e9b1f8346a465de1bbc150c5b9
jeton sous-jacent (VELO Token V2) :
0x9560e827af36c94d2ac33a39bce1fe78631088db
Contrat de vulnérabilité (soVELO, Semblable au cToken de Compound) :
0xe3b81318b1b6776f0877c3770afddff97b9f5fe5
X sur la transaction de sauvetage de l'utilisateur @tonyke_bot
https://optimistic.etherscan.io/tx/0x816f9e289d8b9dee9a94086 c200c0470c6456603c967f82ab559a5931fd181c2
Projet Sonne Finance Fang a récemment approuvé 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 qui seront 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 du facteur hypothécaire. , etc. Une fois le marché VELO créé, les utilisateurs peuvent déposer des jetons VELO pour créer des jetons soVELO, qui peuvent à leur tour être utilisés pour emprunter d'autres soTokens.
L'étape de préparation de l'attaque implique principalement que l'attaquant crée un marché VELO (contrat soVELO) basé sur les informations contenues dans la proposition de projet Sonne Finance après la période de verrouillage de deux jours de la proposition, mettant en place des configurations clés, et jalonner des jetons VELO La devise entre dans le contrat soVELO pour frapper des jetons soVELO. En même temps, elle envoie également les jetons VELO qu'elle détient directement au contrat soVELO pour augmenter le taux de change et préparer des attaques ultérieures pour en tirer profit.
Les étapes spécifiques sont les suivantes :
Après la période de verrouillage de deux jours, l'attaquant a d'abord regroupé les opérations des quatre premières transactions organisées dans la proposition en une seule transaction (transaction 0x45c0cc), qui a été utilisée pour créer le marché VELO (contrat soVELO) et définir la configuration des clés. Lorsque le marché VELO est initialisé, le taux d'échange est défini sur "200 000 000 000 000 000 000 000 000".
L'attaquant appelle la fonction "mint" du contrat soVELO pour déposer des jetons VELO et créer des jetons soVELO. L'attaquant spécifie "mintAmount" comme "400 000 001" (le nombre de jetons VELO). Comme le montre la fonction "exchangeRateStoredInternal", puisque le "_totalSuppl" du jeton soVELO est actuellement égal à 0, ExchangeRate est la valeur définie à l'étape 1. Selon la formule « mintTokens = actualMintAmount / changeRate », le nombre calculé de jetons soVELO qui doivent être émis à ce moment est de 2. En bref, dans cette étape, l'attaquant dépose des jetons VELO d'une valeur de « 400 000 001 » dans le contrat soVELO, et l'attaquant obtient des jetons soVELO d'une valeur de 2. MSoveLo.Mint :
La phase de profit d'attaque implique principalement que l'attaquant exécute la cinquième transaction de la proposition et prête des jetons VELO directement au contrat soVELO via des prêts flash pour augmenter encore le taux de change. L'attaquant a ensuite utilisé le jeton soVELO d'une valeur de 2 en main pour emprunter des jetons sous-jacents tels que WETH et USDC à d'autres contrats soToken (tels que soWETH, soUSDC, etc.), et ces parties sont devenues 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 d'é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 déposés précédemment 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 :
L'attaquant exécute la cinquième transaction de la proposition et définit le facteur de prêt spécifié dans la proposition.
L'attaquant a prêté des jetons VELO d'une valeur de "35 469 150 965 253 049 864 450 449" du pool VolatileV2 AMM - USDC/VELO, ce qui a déclenché la fonction de hook de l'attaquant. Dans la fonction hook, l’attaquant continue d’effectuer l’opération d’attaque.
L'attaquant envoie les tokens VELO qu'il détient au contrat soVELO pour augmenter encore le taux d'échange. Actuellement, il existe 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 trois fois par l'attaquant).
L'attaquant crée un nouveau contrat 0xa16388a6210545b27f669d5189648c1722300b8b Dans le constructeur, il transfère les 2 tokens soVELO qu'il détient vers le contrat nouvellement créé 0xa163 (ci-après dénommé l'attaquant 0xa163).
L'attaquant 0xa163 a utilisé les jetons soVELO qu'il détenait pour emprunter WETH d'une valeur de "265 842 857 910 985 546 929" à soWETH.
L'attaquant 0xa163 appelle la fonction "redeemUnderlying" de soVELO, spécifiant la valeur des jetons VELO échangés comme "35 471 603 929 512 754 530 287 976" (presque le nombre de jetons VELO que tous les attaquants ont précédemment transférés ou hypothéqués dans le contrat soVELO). temps Le Le nombre de jetons soVELO qui doivent être détruits pour être échangés doit être calculé selon la formule « redeemTokens = redeemAmountIn / changeRate ».
Il ressort de la fonction "exchangeRateStoredInternal" que puisque _totalSupply est 2 au lieu de 0 à ce moment, la valeur de changeRate doit être calculée à l'aide de la formule "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply". , le taux de change actuel est "17,735,851,964,756,377,265,143,988,000,000,000,000,000,000", cette valeur est beaucoup plus grande que le taux de change initial défini "200,000,000,000,000,000,000,000,00".
La valeur de "redeemTokens" calculée sur la base du nouveau taux d'échange est de "1,99". En raison des caractéristiques d'arrondi de Solidity, la valeur de "redeemTokens" est finalement de 1. Cela signifie que l'attaquant 0xa163 a utilisé des jetons soVELO d'une valeur de 1 pour racheter presque tous les jetons VELO précédemment déposés. Dans le même temps, l'attaquant 0xa163 a également gagné du WETH d'une valeur de « 265 842 857 910 985 546 929 » emprunté à soWETH.
soVELO.redeemUnderlying :
soVELO.exchangeRateStoredInternal :
L'attaquant 0xa163 a transféré tous les WETH empruntés et échangé les jetons VELO à l'attaquant de niveau supérieur, puis s'est autodétruit éd.
L'attaquant appelle la fonction "liquidateBorrow" de soWETH pour liquider une partie des actifs empruntés au contrat 0xa163 nouvellement créé afin de récupérer les tokens soVELO verrouillés d'une valeur de 1. Actuellement, l’attaquant ne détient que des jetons soVELO d’une valeur de 1.
L'attaquant appelle la fonction "mint" de soVELO et hypothèque et frappe à nouveau les jetons soVELO. Le but est d'obtenir suffisamment de jetons soVELO d'une valeur de 2, puis exécute à nouveau les étapes 3 à 8 ci-dessus pour profiter d'autres jetons inquiétants. .
L'attaquant effectue plusieurs fois l'étape 9, rembourse le prêt flash et repart avec un bénéfice.
Après l'attaque, l'utilisateur @tonyke_bot sur La raison pour laquelle cette opération peut empêcher l'attaquant de poursuivre ses 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 du taux d'échange est supérieur à l'impact. de la croissance du totalCash. Par conséquent, le taux d'échange devient plus petit, de sorte que lorsque l'attaquant attaque, il ne peut plus utiliser la perte de précision pour gagner du soVELO, rendant l'attaque impossible.
L'attaquant a transféré les fonds peu de temps après avoir obtenu les produits illégaux. La plupart des fonds ont été transférés aux 4 adresses suivantes, certains pour changer d'adresse afin de poursuivre l'attaque, et d'autres pour blanchir de l'argent :
0x4ab93fc50b82d4dc457db85888dfdae28d2 9b98d
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 transférée les gains illégaux ci-dessus à 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.
0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb
L'attaquant a transféré 724277 USDC, 2353 VELO à cette adresse et a échangé des USDC contre de l'Ether. Une partie des fonds a été immédiatement transférée vers le pont inter-chaînes Stargate, et la plupart des fonds illégaux sont restés à cette adresse :
0xbd18100a168321701955e348f03d0df4f517c13b
L'attaquant 33 WETH à l'adresse et adopter Essayez peel chaîne pour blanchir de l'argent Le lien de blanchiment d'argent est le suivant :
0xbd18100a168321701955e348f03d0df4f517c13b->0x7e97b74252b6df53caf386fb4c54d4fb59cb6928->0xc521. bde5e53f537ff208970152b75a003093c2b4->0x9f09ec563222fe52712dc413d0b7b66cb5c7c795.
0x4fac0651bcc837bf889f6a7d79c1908419fe1770
L'attaquant a transféré 563 WETH à cette adresse puis à 0x1915F77A116dcE7E9b8F4C4E43CDF8 aCf9C68, aucune autre action pour le moment.
La méthode de blanchiment d'argent utilisée par l'attaquant cette fois est relativement professionnelle et les méthodes montrent une tendance à la diversité. Par conséquent, pour nous, participants au 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 via KYT, AML et d'autres produits de sécurité des transactions blockchain associés.
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 apparaissent sans cesse, en particulier dans les projets Defi, où la perte de précision entraîne souvent de graves pertes financières. Il est recommandé aux parties au projet et aux auditeurs de sécurité d'examiner attentivement les codes présentant une perte de précision dans le projet et d'effectuer des tests pour éviter autant que possible cette vulnérabilité.
Il est recommandé que la création d'un marché similaire à cToken dans Compound et la première opération de frappe hypothécaire soient effectuées par des utilisateurs privilégiés pour éviter d'être exploités par des attaquants et ainsi manipuler le taux de change.
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 si il est autorisé de transférer directement la devise native vers la méthode du contrat ou du jeton pour modifier la valeur de la variable, ou ne peut modifier la valeur de la variable qu'en appelant une fonction spécifique.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!