フラッシュローン攻撃により基地の CloberDEX から 50 万米ドルが流出

最近、私たちは Base 上のプロジェクトである CloberDEX に対するオンチェーン攻撃を監視しました。攻撃されたプロジェクトは CloberDEX であり、攻撃者は約

Recently, an on-chain attack was detected against CloberDEX, a project on Base. The attacker gained about 133 ETH, or about 500,000 USD, through this attack.

最近、Base 上のプロジェクトである CloberDEX に対するオンチェーン攻撃が検出されました。攻撃者はこの攻撃により約 133 ETH、つまり約 500,000 米ドルを獲得しました。

The attacked project is CloberDEX, and its main functions are as follows: open a new trading pool containing trading pairs A to B and B to A, and each trading pair also contains a preset trading strategy; mint is to add liquidity to the trading pair and obtain LP Token; burn is to destroy LP Token to obtain the corresponding currency.

攻撃されたプロジェクトは CloberDEX で、その主な機能は次のとおりです。取引ペア A から B および B から A を含む新しい取引プールを開き、各取引ペアには事前設定された取引戦略も含まれています。 mint は取引ペアに流動性を追加し、LP トークンを取得します。 burn は、LP トークンを破壊して、対応する通貨を取得することです。

Let's take a look at the attack process:

攻撃プロセスを見てみましょう。

First, the attacker borrowed 267 WETH from Morpho Blue using flashloan.

まず、攻撃者はフラッシュローンを使用してモルフォ ブルーから 267 WETH を借りました。

Then, the attacker used open to open two trading pairs on CloberDEX, namely Token/WETH and WETH/Token, where Token is a contract deployed by the attacker himself.

次に、攻撃者は open を使用して CloberDEX 上の 2 つの取引ペア、つまり Token/WETH と WETH/Token をオープンしました。Token は攻撃者自身が展開したコントラクトです。

Then, the attacker used mint to transfer 267 WETH and 267 Token to the newly opened trading pair to add liquidity and obtain LP Token.

次に、攻撃者は mint を使用して 267 WETH と 267 トークンを新しく開設された取引ペアに転送し、流動性を追加して LP トークンを取得しました。

So far, there is no problem. Finally, the attacker uses burn to destroy the LP Token just obtained. Let's take a look at the specific implementation of burn;

今のところ問題はありません。最後に、攻撃者はバーンを使用して、取得したばかりの LP トークンを破壊します。 burn の具体的な実装を見てみましょう。

The control flow goes to the lock function. Similarly, let's take a look at the specific implementation of lock;

制御フローはロック機能に進みます。同様に、ロックの具体的な実装を見てみましょう。

As you can see, the lock function passes bytes caldata data to the lockAcquired function. Let's continue to look at the implementation of this function.

ご覧のとおり、lock 関数はバイトの caldata データを lockAcquired 関数に渡します。引き続き、この関数の実装を見てみましょう。

We found this line of code

このコード行が見つかりました

We can see that the function called by the code is determined by data. The first four bytes of data are the signature of _burn, so burn essentially calls _burn.

コードによって呼び出される関数はデータによって決定されることがわかります。データの最初の 4 バイトは _burn の署名であるため、burn は基本的に _burn を呼び出します。

We can see that _burn calls pool.strategy.burnHook(msg.sender, key, burnAmount,supply) again, and the processing of the pool's reserver comes after this code. So, the problem lies here. The address of the strategy contract of the pool corresponding to the trading pair can be controlled by the attacker. In this attack, the attacker wrote the address as his own attack contract address: 0x32fb1bedd95bf78ca2c6943ae5aeaeaafc0d97c1 .

_burn が pool.strategy.burnHook(msg.sender, key, burnAmount,supply) を再度呼び出し、プールのリザーバーの処理がこのコードの後に​​来ることがわかります。さて、問題はここにあります。取引ペアに対応するプールのストラテジー コントラクトのアドレスは、攻撃者によって制御される可能性があります。この攻撃では、攻撃者は自身の攻撃コントラクト アドレスとしてアドレスを書き込みました: 0x32fb1bedd95bf78ca2c6943ae5aeaeaafc0d97c1 。

When the contract process reaches the BurnHook of the attacking contract, burn is called again to complete the reentrancy attack.

コントラクト プロセスが攻撃コントラクトの BurnHook に到達すると、burn が再度呼び出され、リエントランシー攻撃が完了します。

The attacker took out 264 WETH and 133 WETH from the CloberDEX contract through this vulnerability, and made a profit of 133.7 ETH after repaying the flashloan loan, which is about 500,000 USD.

攻撃者はこの脆弱性を利用して CloberDEX コントラクトから 264 WETH と 133 WETH を引き出し、フラッシュローン ローン返済後、約 50 万米ドルに相当する 133.7 ETH の利益を得ました。

The main cause of this vulnerability is that the CloberDEX project contract did not perform reentrancy detection and protection in the code for obtaining and destroying LP Tokens, and the state variables were updated after the contract was called, which eventually led to the attacker using the reentry vulnerability to empty the project's WETH. It is recommended that the project party should conduct multi-party verification when designing the economic model, price calculation mechanism and code operation logic, and try to select multiple audit companies for cross-audit when auditing the contract before it goes online.

この脆弱性の主な原因は、CloberDEX プロジェクト コントラクトが、LP トークンを取得および破棄するためのコード内でリエントラントの検出と保護を実行しておらず、コントラクトが呼び出された後に状態変数が更新され、最終的に攻撃者がリエントラントを使用することになったことです。プロジェクトの WETH を空にする脆弱性。プロジェクト当事者は、経済モデル、価格計算メカニズム、およびコード操作ロジックを設計するときに複数の当事者による検証を実施し、契約をオンライン化する前に監査するときに相互監査のために複数の監査会社を選択するよう努めることをお勧めします。