背景の紹介
最近、私たちは Base 上のプロジェクトであるCloberDEXに対するオンチェーン攻撃を監視しました。
https://basescan.org/tx/0x8fcdfcded45100437ff94801090355f2f689941dca75de9a702e01670f361c04
攻撃されたプロジェクトは CloberDEX で、攻撃者はこの攻撃で約 133 ETH (約 500,000 米ドル) の利益を得ました。このプロジェクトの主な機能は次のとおりです。 open は、A から B へ、および B から A への取引ペアを含む新しい取引プールを開きます。各取引ペアには、事前に設定された取引戦略も含まれています。mint は、取引ペアに流動性を追加し、LP トークンを取得します。 burn は、LP トークンを破壊するために対応する通貨を取得します。
攻撃とインシデントの分析
まず、攻撃者はフラッシュローンを使用してモルフォ ブルーから 267 WETH を借りました。
次に、攻撃者は Open を使用して CloberDEX 上の 2 つの取引ペア、つまり Token/WETH と WETH/Token をオープンしました。このうち、Token は攻撃者自身が展開したコントラクトです。
次に、攻撃者は mint を使用して 267 WETH と 267 トークンをそれぞれ新しく開かれた取引ペアに転送し、流動性を追加して LP トークンを取得しました。
ここまでは問題ありません。最後に、攻撃者は Burn を使用して、新しく取得した LP トークンを破壊します。 Burn の具体的な実装を見てみましょう。
制御フローはロック関数に進みます。同様に、ロックの具体的な実装を見てみましょう。
バイト caldata データが lock 関数の lockAcquired 関数に渡されることがわかります。この関数の実装を続けて見てみましょう。
このコード行が見つかりました
このコードによって呼び出される関数はデータによって決定されることがわかります。データの最初の 4 バイトは _burn の署名であるため、基本的に burn は _burn を呼び出します。
_burn が pool.strategy.burnHook(msg.sender, key, burnAmount,supply) を再度呼び出し、プールの予約の処理がこのコードの後にあることがわかります。したがって、ここで問題が発生します。取引ペアに対応するプールのストラテジー コントラクトのアドレスは、攻撃者によって制御される可能性があります。この攻撃では、攻撃者はこのアドレスを自身の攻撃契約アドレスとして書き込みました: 0x32fb1bedd95bf78ca2c6943ae5aeaeaafc0d97c1 。
コントラクト プロセスが攻撃コントラクトの BurnHook に到達すると、引き続き Burn を呼び出してリエントラント攻撃を完了します。
攻撃者はこの脆弱性を利用して、CloberDEX 契約に投資した 264 WETH のうち 133 WETH を引き出し、フラッシュローン ローンを返済した後、133.7 ETH (約 500,000 米ドル) の利益を得ました。
要約する
この脆弱性の主な原因は、CloberDEX プロジェクト側のコントラクトが、LP トークンを取得して破棄するためのコード内で再入検出と保護を実行せず、コントラクトが呼び出された後に状態変数が更新されるため、最終的に攻撃者がこれを使用することになります。プロジェクト側を空にするリエントランシーの脆弱性。プロジェクト当事者は、経済モデル、価格計算メカニズム、およびコード操作ロジックを設計するときに複数の当事者による検証を実施し、契約がオンラインになる前に相互監査のために複数の監査会社を選択するよう努めることをお勧めします。
