背景
2025年3月14日、BNBスマートチェーンプロジェクトH2Oへの攻撃を検出しました。攻撃ハッシュは次のとおりです。
https://bscscan.com/tx/0x729c502a7dfd5332a9bdbcacec97137899ecc82c17d0797b9686a7f9f6005cb7
https://bscscan.com/tx/0x994abe7906a4a955c103071221e5eaa734a30dccdcdaac63496ece2b698a0fc3
攻撃を受けたプロジェクトはH2Oであり、攻撃により合計22,000ドルの損失が発生しました。
攻撃とインシデントの分析
最初の攻撃では、攻撃者はまず、攻撃の初期資金としてフラッシュローンを使用して PancakeSwapV3 プールから 100,000 USDT を借り入れました。
その後、当初の借入資金は、USDT-H2O PancakeSwap ペアで 66,439,209 H2O を交換するために使用されました。
その後、攻撃者は頻繁にH2OをPancakeSwapペアUSDT-H2Oに転送し、ペア内のUSDT準備金とH2O準備金の不均衡を引き起こし、次にskimを使用してペア内のreserve0とreserve1のバランスを取り、攻撃を実行しました。 H2O の脆弱性は伝達関数に現れています。伝達関数の具体的な実装を見ることができます。
問題は、PancakeSwap Pair から _calulate 関数が呼び出される関数で具体的に発生します。攻撃者はPairのReserve0とReserve1の不均衡を利用してskimを呼び出して自分自身に転送するため、転送の送信者はPairアドレスになります。次に、この機能の具体的な実装を見てみましょう。
この機能のロジックは非常にシンプルです。コントラクト自体が保有するH2Oトークンの残高に応じて、報酬率（1％〜5％、残高が低いほど、報酬率も低くなります）を動的に設定し、オンチェーン乱数を通じてH2またはO2トークンを比例配分してユーザーに配布します。ユーザーが少なくとも10個のH2と5個のO2を保有している場合、2：1の比率でトークンを破壊し（化学反応2H₂+O₂→2H₂Oをシミュレート）、コントラクト内のH2Oトークンを償還できます。実際の償還額は、コントラクト残高によって制限されます。
チェーン上で乱数を生成するコントラクトのロジックは次のとおりです。
msg.sender のブロック時間、ブロック番号、keccak256 に基づいて計算されます。最初の攻撃では、攻撃者は H2 トークンと O2 トークンを持っていなかったので、この攻撃で 169,731,921 個の O2 トークンを取得しました。次に、攻撃者は getRandomOnchain()%2 == 1 である限り攻撃を完了できます。その後、攻撃者はさらに 3 回試行しましたが、最初の 2 回は getRandomOnchain()%2 が 0 であったため、攻撃は失敗しました。攻撃は 4 回目の試行で実際に完了しました。
4 回目の攻撃では、攻撃者はまず、攻撃の初期資金としてフラッシュローンを使用して PancakeSwapV3 プールから 100,000 USDT を借り入れました。
その後、当初の借入資金は、USDT-H2O PancakeSwap ペアで 66,439,209 H2O を交換するために使用されました。
その後、攻撃者は頻繁にH2OをPancakeSwapペアUSDT-H2Oに転送し、ペア内のUSDT準備金とH2O準備金の不均衡を引き起こし、次にskimを使用してペア内のreserve0とreserve1のバランスを取り、攻撃を実行しました。
上記の分析によると、この攻撃では getRandomOnchain()%2 は 1 なので、H2O は H2Token を発行します。最初の攻撃中に getRandomOnchain()%2 が 0 だったため、攻撃者は大量の O2 トークンを取得しました。したがって、H2O は H2 と O2 を燃焼させ、その後自身の H2O を攻撃者に転送します。
最終的に、攻撃者は122,820 USDTをどこからともなく現れたH2Oと交換しました。 100,000 USDTのフラッシュローンと50 USDTの利息を返済した後、最終利益は22,770 USDTでした。
要約する
この脆弱性の主な原因は、H20 トークン契約が PancakeSwap ペアから購入するための経済モデルを設計したときに、ERC20 転送関数を変更するときに skim でも同じ目的を達成できることを考慮しなかったため、攻撃者が skim を使用して大量のインセンティブを無から取得できたことです。プロジェクト関係者は、経済モデル、価格計算メカニズム、コード操作ロジックを設計する際に多者間検証を実施し、契約がオンラインになる前に監査を行う際には、相互監査のために複数の監査会社を選択するように努めることが推奨されます。
