Sonne Finance 攻撃分析: 100 ドルが 650 万ドルをどのように活用できるでしょうか?この攻撃の本質は、市場 (soToken) が作成されたときに、攻撃者が最初の抵当キャスティング操作を実行し、基礎となる少量のトークンを使用して非常に少数の soToken を鋳造したため、soToken の「totalSupply」値が小さすぎるということです。次に攻撃者は、Solidity コントラクトの精度損失の脆弱性を悪用し、ステーキング + キャスト方式ではなく、基盤となるトークンを soToken コントラクトに直接送信しました (soToken は生成されません。つまり、「totalSupply」は変更されず、「totalCash」は大きくなります)。基礎となるトークンをデポジットします。このような操作により、コントラクト内の変数 "totalCash" は大きくなりますが、"totalSupply" は変化しないため、exchangeRate が大きくなります。最終的に、攻撃者が基礎となるトークンを償還するとき、破壊する必要がある soToken は、住宅ローン中に作成された soToken よりも少なくなります。攻撃者は、取得した soToken を使用して、基礎となるトークン WETH および USDC を他の soToken (soWETH など) に貸し出します。 、USDC)、最終的には 2,000 万米ドルもの利益を獲得しました。
2024 年 5 月 15 日、Sonne Finance が Optimism チェーンで攻撃され、最大 2,000 万ドルの損失が発生しました。攻撃後、ユーザー @tonyke_bot
(https://twitter.com/tonyke_bot/status/1790547461611860182)
Sonne Finance プロジェクトは攻撃を発見した後、すぐに Optimism のすべての市場を停止し、Base の市場は安全であると述べました。
(https://twitter.com/SonneFinance/status/1790535383005966554)
Sonne Finance は、個人、機関、および金融サービスにアクセスするための同意を楽観的に考慮した Compound V2 をフォークした分散型融資プロトコルです。 Sonne Finance プロトコルは、ユーザーのトークン資産を集約して融資流動性プールを形成し、ユーザーに銀行のような融資ビジネスを提供します。 Compound と同様に、プロトコル参加者は自分のトークンを Sonne Finance の融資流動性プールに抵当に入れ、証明書 soToken (cToken と同じ) を取得できます。 SoToken は利付き資産証明書であり、ブロックの進行に応じて一定の収入が得られ、SONE トークンのインセンティブも受け取ります。参加者は、soToken を手にしたまま、Sonne 融資資産プールから他のトークンを借りることもできます。たとえば、参加者は、一定量の USDC を抵当にして soUSDC 証明書を取得し、さらに流通させるために WETH を貸し出すことができます。 Sonne Finance プロトコルでの住宅ローン融資は多対多の資産関係になる可能性があり、住宅ローン融資プロセス中に、プロトコルは参加者の住所の健康係数 (健康係数) を自動的に計算します。健康係数が 1 より低い場合、住所の抵当権製品は清算をサポートし、清算人は特定の清算報酬を受け取ることもできます。
ユーザーが預けた基礎となるトークンと生成された soToken の関係は、主に、exchangeRate と呼ばれる変数に関連しています。この変数は、各 soToken の基礎となるトークンの価値を大まかに示すために使用できます。 ExchangeRate の計算式は次のとおりです。
上記の式において、totalCash は soToken が保有する基礎トークンの数を指し、totalBorrows は特定の市場で貸し出されている基礎トークンの数を指し、totalReserves は準備金の合計数 (借り手が支払った利息を含む)、totalSupply は鋳造された soToken の数を指します。
引き換える際、ユーザーは引き換えたい基礎となるトークンの数 redeemAmount を指定して、破棄する必要がある soToken の数 redeemTokens を計算できます。計算方法はおおよそ「redeemTokens = redeemAmount /exchangeRat」であることに注意してください。ここでは損失に対処するのは正確ではありません。
この攻撃の本質は、市場 (soToken) が作成されたときに、攻撃者が最初の抵当キャスティング操作を実行し、基礎となる少量のトークンを使用して非常に少数の soToken を鋳造したため、soToken の「totalSupply」値が小さすぎるということです。 。次に攻撃者は、Solidity コントラクトの精度損失の脆弱性を悪用し、ステーキング + キャスト方式ではなく、基盤となるトークンを soToken コントラクトに直接送信しました (soToken は生成されません。つまり、「totalSupply」は変更されず、「totalCash」は大きくなります)。基礎となるトークンをデポジットします。このような操作により、コントラクト内の変数 "totalCash" は大きくなりますが、"totalSupply" は変化しないため、exchangeRate が大きくなります。最終的に、攻撃者が基礎となるトークンを償還するとき、破壊する必要がある soToken は、住宅ローン中に作成された soToken よりも少なくなります。攻撃者は、取得した soToken を使用して、基礎となるトークン WETH および USDC を他の soToken (soWETH など) に貸し出します。 、USDC)、最終的には 2,000 万米ドルもの利益を獲得しました。
攻撃準備トランザクション:
https://optimistic.etherscan.io/tx/0x45c0ccfd3ca1b4a937feebcb0f5a166c409c9e403070808835d41da40732db96
攻撃利益トランザクション:
https://optimistic.etherscan.io/tx/ 0x9312ae377d7ebdf3c7c3a86f80514878deb5df51aad38b6191d55db53e42b7f0
攻撃EOA関連アドレス:
0x5d0d99e9886581ff8fcb01f35804317f5ed80 bbb
0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43
攻撃者(契約)関連アドレス:
0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8
0x02fa 2625825917e9b1f8346a465de1bbc150c5b9
基礎となるトークン (VELO トークン V2): x9560e827af36c94d2ac33a39bce1fe78631088db
脆弱性契約 (soVELO, Compound の cToken に似ています):
0xe3b81318b1b6776f0877c3770afddff97b9f5fe5
X on @tonyke_bot ユーザーレスキュートランザクション
https://optimistic.etherscan.io/tx/0x816f9e289d8b9dee9a9 4086 c200c0470c6456603c967f82ab559a5931fd181c2
攻撃プロセスの分析
攻撃準備
具体的な手順は次のとおりです:
攻撃者は、「2,552,964,259,704,265,837,526」の値を持つ Velo トークンを SOVELO コントラクトに直接送信します。この時点でトークンは増加しますが、新しい soVELO は存在しません。トークンが鋳造されてもtotalSupplyは変化しないため、この時点でexchangeRate計算式に従って計算されるexchangeRateが大きくなります。
攻撃者は保有している soVELO トークンを複数回転送し、最終的には別の攻撃 EOA 0xae4a に転送しました。
攻撃利益フェーズでは主に、攻撃者が提案の 5 番目のトランザクションを実行し、フラッシュ ローンを通じて VELO トークンを soVELO 契約に直接貸し出し、為替レートをさらに上昇させます。次に、攻撃者は、値が 2 の soVELO トークンを手にして、WETH や USDC などの基礎となるトークンを他の soToken (soWETH、soUSDC など) コントラクトから借用し、これらの部分が攻撃者の利益となりました。その後、攻撃者は soVELO コントラクト内の基礎となるトークンを償還しようとしました。exchangeRate の増加と、償還のために破棄する必要がある soVELO トークンの計算精度の低下により、攻撃者は最終的に の値を持つ soVELO トークンのみを使用しました。 1. 以前にデポジットされた VELO トークンのほぼすべてが償還されました。これは、攻撃者が値 1 の追加の soVELO トークンを使用して、他の soToken から借りて WETH や USDC などの基礎となるトークンを獲得したと理解できます。攻撃者は同じ手法を使って何度も攻撃を繰り返し、最終的には巨額の利益を得ました。
具体的な手順は次のとおりです:
攻撃者はプロポーザルの 5 番目のトランザクションを実行し、プロポーザルで指定された融資係数を設定します。
攻撃者は、VolatileV2 AMM - USDC/VELO プールから「35,469,150,965,253,049,864,450,449」の値を持つ VELO トークンをフラッシュローンし、これにより攻撃者のフック機能がトリガーされました。フック機能では、攻撃者は攻撃操作を継続します。
攻撃者は、保有する VELO トークンを soVELO コントラクトに送信して、為替レートをさらに上昇させます。現在、soVELO コントラクトには「35,471,703,929,512,754,530,287,976」の値を持つ VELO トークンの合計があります (攻撃者によって 3 回転送された VELO トークンの合計)。
攻撃者は、新しいコントラクト 0xa16388a6210545b27f669d5189648c1722300b8b を作成し、コンストラクターで、彼が保持する 2 つの soVELO トークンを、新しく作成されたコントラクト 0xa163 (以下、攻撃者 0xa163 と呼びます) に転送します。
攻撃者 0xa163 は、保有する soVELO トークンを使用して、値「265,842,857,910,985,546,929」の WETH を soWETH から借用しました。
攻撃者 0xa163 は、soVELO の「redeemUnderlying」関数を呼び出し、引き換えられた VELO トークンの値を「35,471,603,929,512,754,530,287,976」(攻撃者が以前に転送または soVELO 契約に抵当に入れていた VELO トークンの数とほぼ同じ)を指定しました。現時点では償還のために破棄する必要がある soVELO トークンの数は、「redeemTokens = redeemAmountIn /exchangeRate」の式に従って計算する必要があります。
「exchangeRateStoredInternal」関数から、この時点では _totalSupply が 0 ではなく 2 であるため、exchangeRate の値は「exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply」という式で計算する必要があることがわかります。現在のexchangeRateは「17,735,851,964,756,377,265,143,988,000,000,000,000,000,000」であり、この値は、設定された初期exchangeRate「200,000,000,000,000,000,000,000,00」よりもはるかに大きくなります。
新しいexchangeRateに基づいて計算される「redeemTokens」の値は「1.99」となります。Solidityの特性上、切り捨てにより最終的に「redeemTokens」の値は1となります。これは、攻撃者 0xa163 が値 1 の soVELO トークンを使用して、以前に預けられたほぼすべての VELO トークンを引き換えたことを意味します。同時に、攻撃者 0xa163 は、soWETH から借用した値「265,842,857,910,985,546,929」の WETH も獲得しました。
soVELO.redeemUnderlying:
soVELO.exchangeRateStoredInternal:
攻撃者 0xa163 は、借りたすべての WETH と引き換えた VELO トークンを上位の攻撃者に転送し、その後自爆しました。
攻撃者は、値 1 のロックされた soVELO トークンを取り戻すために、soWETH の「liquidateBorrow」関数を呼び出し、新しく作成されたコントラクト 0xa163 から借りた資産の一部を清算します。現在、攻撃者は値が 1 の soVELO トークンのみを保持しています。
攻撃者は、soVELO の「mint」関数を呼び出し、soVELO トークンを再度抵当し、鋳造します。目的は、値 2 の十分な soVELO トークンを収集し、その後、他の不当なトークンから利益を得るために、上記の手順 3 ~ 8 を再度実行することです。 。
攻撃者はステップ 9 を数回実行し、フラッシュ ローンを返済し、利益を残して立ち去ります。
攻撃後、ユーザー @tonyke_bot はこの操作により攻撃者がさらなる攻撃を防ぐことができる理由は、このトランザクションが soVELO の totalSupply のサイズと保有する VELO トークン totalCash の数を変更し、totalSupply の増加が ExchangeRate の計算に与える影響の方が大きいためです。したがって、exchangeRate が小さくなり、攻撃者は攻撃時に精度の低下を利用して soVELO を獲得できなくなり、攻撃が不可能になります。
攻撃者は違法な収益を入手した直後に資金の大部分を次の 4 つのアドレスに送金しました。一部は攻撃を継続するためにアドレスを変更するため、一部はマネーロンダリングのために送金されました。
0x4ab93fc50b82d4dc457db85888dfdae28d2 9b98d攻撃後、アドレスは上記を転送しました不法利益0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb に。
0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb0x4fac0651bcc837bf889f6a7d79c1908419fe1770
攻撃者は 563 WETH をこのアドレスに転送し、その後 0x1915F77A116dcE7E9b8F4C4E43CDF8 に転送しました。 aCf9C68、現時点ではこれ以上のアクションはありません。
安全に関するアドバイス
攻撃者によって運営され、それによって為替レートが操作されることを避けるために、Compound での cToken に似たマーケットの作成と最初の住宅ローン鋳造操作は特権ユーザーによって実行されることが推奨されます。
「 this.balance 」または「 token.balanceOf() 」の値に依存するキー変数がコントラクト内にある場合、キー変数の変更条件を慎重に検討する必要があります。ネイティブ通貨をコントラクトまたはトークン メソッドに直接転送して変数の値を変更することも、特定の関数を呼び出すことによってのみ変数の値を変更することもできます。
以上が100 ドルが 650 万ドルをどのように活用できるでしょうか? Sonne Finance の攻撃分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。