過去1週間（2026/03/23 - 2026/03/29）に、BlockSecは8件の攻撃インシデントを検出し分析しました。総推定損失額は約153万ドルです。以下の表にこれらのインシデントの概要を示し、各ケースの詳細な分析は以降のサブセクションで提供します。

未知のインシデント 1

概要

2026年3月23日、イーサリアム上の未検証コントラクトが、その配布ロジックにおける整数オーバーフローにより、約97,000ドルの損失を被りました。関数 0x317de4f6() は、オーバーフロー保護なしにユーザーが制御するトークン量を合計していましたが、攻撃者は claim() 関数を通じて、わずか1 weiの USDT を支払うだけで、コントラクトの USDT 全残高を引き出すことができました。

脆弱性分析

根本原因は、コントラクト 0xF0a105...568C97 の関数 0x317de4f6() における整数オーバーフローでした。この関数は、レコードの配列（それぞれアカウントと量を含む）を受け取り、配列を反復処理して、すべての量を totalAmount に合計します。累積処理にはオーバーフローチェックが欠けていたため、攻撃者は uint256 をラップアラウンドする量を含むように細工したレコードを提供でき、個々の割り当ては大きいままで totalAmount を任意に小さくすることができました。

攻撃分析

以下の分析は、トランザクション 0x73bd1384...630b053 に基づいています。

• ステップ1：攻撃者は、攻撃の初期資本として、Uniswap V4から1 weiの USDT を借りました。

  

• ステップ2：攻撃者は、被害者コントラクトの USDT 残高を照会し、細工した配列で 0x317de4f6() を呼び出しました。1つの量は uint256 の上限近くに設定され、もう1つは被害者コントラクトの USDT 残高に設定されました。その合計は1にオーバーフローし、攻撃者は被害者の USDT 全残高に相当する割り当てを記録しながら、わずか1 weiの USDT を支払うだけで済みました。

  

• ステップ3：攻撃者は claim() を呼び出して、被害者コントラクトから 97,812e6 USDT を引き出しました。

  

• ステップ4：攻撃者はUniswap V4から借りた1 weiの USDT を返済し、残りの USDT を WETH と交換して、エクスプロイトを完了しました。

結論

このインシデントは、Solidityバージョン0.8.0より前のバージョンでチェックされていない算術演算を使用することのリスクを浮き彫りにしています。すべての重要な金融計算では、ラップアラウンドの問題を防ぐために、オーバーフロー安全な算術演算（例：SafeMathまたはSolidity >=0.8.x）を明示的に使用する必要があります。

未知のインシデント 2

概要

2026年3月23日、イーサリアム上の未検証コントラクトが、再入可能脆弱性により、約11,000ドルの損失を被りました。関数 0xbe16634e() は、決済前に流動性関連の会計を更新し、再入可能保護なしに外部コールバックを呼び出しました。前の呼び出しが決済される前に繰り返し関数を再入することで、攻撃者は記録された流動性を膨張させ、後に実際に預けた量よりも多くの USDC と WETH を引き出しました。

脆弱性分析

根本原因は、コントラクト 0x39Ed37...9C6b08 の関数 0xbe16634e() における再入可能問題です。この関数は、決済前に流動性関連の状態（ユーザー流動性およびティックリザーブを含む）を更新し、再入可能ガードなしに msg.sender.call() を介して外部コールバックを呼び出します。残高チェックは呼び出しごとに実行されるため、攻撃者は再帰的に関数を再入して内部流動性会計を膨張させることができ、最も深い呼び出しでの単一のトークン転送で、ネストされた実行フローを満たすことができました。

攻撃分析

以下の分析は、トランザクション 0x1382e898...fad993 に基づいています。

• ステップ1：攻撃者は、攻撃の初期資本として、Uniswap V4から100e8 USDC と 10e18 WETH を借りました。

  

• ステップ2：攻撃者は 0xbe16634e() を呼び出して流動性を追加しました。実行中、被害者コントラクトは攻撃者の関数 0x7c65be42() を呼び出し、これは前の呼び出しが決済される前に 0xbe16634e() を再入しました。

  

• ステップ3：この再入可能フローを複数回繰り返すことで、攻撃者は記録された流動性を継続的に増加させました。最も深い呼び出しでは、攻撃者は必要なトークンを1回転送し、ネストされた残高チェックを満たすのに十分でした。

  

• ステップ4：記録された流動性を膨張させた後、攻撃者はプール状態をチェックし、 upcoming withdrawal をカバーするのに十分な USDC と WETH を保持するように、追加の資金をプールに転送しました。

  

• ステップ5：攻撃者は 0xbe16634e() を再度呼び出して流動性を削除し、膨張した会計に基づいてプールから USDC と WETH を引き出しました。

  

• ステップ6：攻撃者はUniswap V4を返済し、残りの USDC を WETH と交換して、エクスプロイトを完了しました。

  

結論

このインシデントは、決済前に流動性会計を更新しながら、保護されていない外部コールバックを呼び出すことの危険性を示しています。同様のエクスプロイトを防ぐために、プロトコルはchecks-effects-interactionsパターンを厳密に遵守し、再入可能ガードで外部コールバックを保護する必要があります。

Cyrus Finance インシデント

概要

2026年3月23日、BNB Chain上のイールドファーミングプロトコルであるCyrus Financeが、プールの現在のスポット価格に依存する不完全な流動性削除式により、約512,000ドルの損失を被りました。このプロトコルはCYRP NFTポジションをPancakeSwap V3流動性の比例シェアを表すために使用していますが、ユーザーシェアから基盤となる流動性への変換は slot0() を読み取ります。これは同じトランザクション内で操作可能です。フラッシュローンで資金調達されたスワップにより価格をシフトさせることで、攻撃者はNFTポジションの流動性価値を膨張させ、公正な権利を超えて引き出しました。

背景

Cyrus Financeは、BNB Chain上のイールドファーミングプロトコルであり、PancakeSwap V3プールで流動性ポジションを管理しています。ユーザーは USDT を預けてCYRP NFTポジションを受け取ります。これは、複数のPancakeSwap V3ポジションにわたるプロトコルの流動性のシェアを表します。ユーザーは exit() 関数を通じて元本と報酬を引き出すことができます。

脆弱性分析

脆弱性は、CyrusTreasury (0xb042Ea...0aE10b) の withdrawUSDTFromAny() 関数にあります。引き出しを処理する際、この関数はPancakeSwap V3プールの slot0()（つまり、現在のスポット価格）から sqrtPriceX96 を取得し、それを getAmountsForLiquidity() に渡して、プロトコルの全ポジション流動性が現在どれだけの amount0 / amount1 に相当するかを推定します。

次に、そのスポット価格ベースの評価から availableUSDT を導き出し、次の式を使用して、要求された引き出しのためにどれだけの流動性を削除すべきかを決定します。

$liquidityToUse=liquidity\cdot remaining\mathrm{/}availableUSDTliquidityToUse\; =\; liquidity\; \backslash cdot\; remaining\; /\; availableUSDT$

言い換えれば、コントラクトは固定の所有権シェアを直接償還するのではなく、まずライブプール価格を使用してポジションの現在の USDT 相当価値を推定し、要求された USDT 量を比例流動性量に変換します。

これは、 slot0() が同じトランザクション内で操作可能であるため、安全ではありません。プール価格を一時的に移動させることで、攻撃者は availableUSDT を歪めることができ、これは計算された liquidityToUse に直接影響します。

攻撃分析

以下の分析は、トランザクション 0x85ac5d15...46d452 に基づいています。

• ステップ1：攻撃者は、PancakeSwap V3プールから約1,798 ETH をフラッシュローンで借りました。

• ステップ2：攻撃者は、ターゲットプール（プロトコルが流動性を維持していた）で大規模な ETH から USDT へのスワップを実行し、意図的にプール価格と現在のティックをシフトさせました。同時に、攻撃者は safeTransferFrom() を介してCYRP NFTポジション #15505 を攻撃コントラクトに転送しました。

• ステップ3：攻撃者は CyrusTreasury 上の exit(15505) を呼び出しました。実行中、 withdrawUSDTFromAny() はPancakeSwap V3プールから slot0() を読み取り、操作されたスポット価格に基づいて availableUSDT を計算しました。ティックが歪んでいたため、プロトコルはNFTシェアに対応する流動性価値を過大評価しました。次に decreaseLiquidity() と collect() を呼び出し、Cyrusポジションの公正価値を超えた過剰な USDT を解放しました。

  

• ステップ4：攻撃者はプール状態を復元し、フラッシュローンを返済し、残りの利益（約512,000ドル）をEOA 0xf96EB1...3b63b に転送しました。

結論

緩和策として、流動性を引き出し可能な USDT に変換する前に、スポット slot0() 価格設定を操作耐性のある価格設定（十分な観測ウィンドウのTWAP、またはChainlinkのような外部オラクル）に置き換える必要があります。

BCE Token インシデント

概要

2026年3月23日、BNB Chain上のPancakeSwap BCE-USDT プールが、BCEトークンの不完全なバーンメカニズムにより、約679,000ドルの損失を被りました。攻撃者は2つの悪意のあるコントラクトをデプロイして BCE の売買制限を回避し、流動性プールリザーブに対するトークンバーンをトリガーして、プールの価格を操作し USDT を使い果たしました。

脆弱性分析

脆弱性は、BCE トークン (0xcdb189...999999) の不完全なバーンメカニズムに由来します。根本的な問題は、ユーザーが影響を与える状態変数 scheduledDestruction が、ユーザー自身の残高からではなく、PancakeSwapペアアドレスから直接トークンをバーンするために使用されていることです。売却操作中、コントラクトは取引量と現在のプールリザーブに基づいて、 scheduledDestruction に破壊量を蓄積します。この値は売り手から差し引かれるわけではありません。代わりに、ペアからトークンをバーンし sync() を呼び出す別のコードパスを通じて後で実行されます。

攻撃者は取引量とプールリザーブを操作できるため、 scheduledDestruction を任意の価値に設定し、ペアの BCE リザーブを圧縮するバーンをトリガーして、有利なようにプールの価格を歪めることができました。

攻撃分析

以下の分析は、トランザクション 0x85ac5d15...46d452 に基づいています。

• ステップ1：攻撃者は、複数のフラッシュローンと貸付プールを通じて、悪意のあるコントラクト（MC1）を呼び出して1億2350万 USDT を借りました。

• ステップ2：攻撃者は2番目の悪意のあるコントラクト（MC2）をデプロイし、借りたすべての USDT をMC2に転送しました。

• ステップ3：攻撃者（MC2経由）は、BCE-USDT プールで222万 USDT を552.9万 BCE とスワップしました。

• ステップ4：攻撃者はMC2からMC1に552.9万 BCE を転送しました（MC1.drain()経由）。バーンメカニズムにより、MC1は276.4万 BCE を受け取りました。

• ステップ5：攻撃者（MC1経由）は248.8万 BCE を136.8万 USDT とスワップし、プールリザーブとスワップ額に基づいて scheduledDestruction 変数を約174Kに更新しました。この変数は後にバーン額として使用されました。

• ステップ6：攻撃者（MC2経由）は3490万 USDT を348.4万 BCE とスワップし、BCE リザーブを約174Kに向けてさらに操作しました。

• ステップ7：攻撃者はMC2から残りの BCE と USDT をMC1に転送しました。 scheduledDestruction が0より大きかった（約174K）ため、 BCE の転送によりバーンがトリガーされ、 BCE リザーブが約10,000に圧縮されました。

• ステップ8：攻撃者は残りの BCE を操作された価格で USDT とスワップしました。

• ステップ9：攻撃者はすべてのローンを返済し、約679,000ドルの利益を上げました。

結論

このインシデントは、トークンの経済ロジックにおける根本的な欠陥によって引き起こされました。ユーザーが影響を与える状態変数が、ユーザー自身の残高ではなく、流動性プールの残高を変更するために使用されていました。コントラクトは、取引活動から派生した破壊がユーザーコストを反映すると暗黙的に仮定していましたが、実際には攻撃者が限定的な資本エクスポージャーで遅延バーンを構築し、流動性プロバイダーから価値を抽出することを可能にしました。その結果、攻撃者はプールの深さと価格設定を操作でき、資本エクスポージャーを制限して価値を抽出できました。

未知のインシデント 3

概要

2026年3月25日、BNB Chain上の未検証ステーキングコントラクトが、複数のステーキングモード間での不整合な会計により、約1,200ドルの損失を被りました。このコントラクトは、stake2()/withdraw2() と stake3()/withdraw3() の両方で同じポジション変数を共有していましたが、これらの関数は異なるトークンバスケットと比率を扱っていました。攻撃者は軽量な stake2() モードで預け入れ、より重い withdraw3() モードで償還し、過剰なトークンを繰り返し抽出しました。

背景

これは、いくつかのステーキングおよび引き出しモードを備えたステーキングコントラクトです。標準の stake() および withdraw() パスはフルステーキングモードであり、報酬会計ロジックとともに、 Pangolin、Bzzt、Bzzone のバスケットを扱います。 stake3() および withdraw3() パスは同じ3トークンバスケットとdeposit/withdraw比率を使用しますが、追加の報酬会計フローをスキップします。対照的に、 stake2() および withdraw2() パスは、 Pangolin と Bzzt のみを扱う軽量モードであり、したがって他の2つのモードとは異なるトークン組み合わせと比率を使用します。

脆弱性分析

根本原因は、コントラクト 0x29d36c...774137 における会計の不整合でした。 stake2()/withdraw2() および stake3()/withdraw3() は異なるトークンバスケットを扱っていましたが、すべて同じ変数 _exit[msg.sender] および _totalSupply を更新していました。その結果、軽量な stake2() モードで作成されたポジションは、 withdraw3() モードで償還可能でした。

実際には、 stake2(amount) は Pangolin と Bzzt をそれぞれ amount だけ引き出しましたが、 withdraw3(amount) は Pangolin を amount、 Bzzt を 10 * amount、 Bzzone を 10 * amount 返しました。これは、 stake2() を通じて20e18 Pangolin と20e18 Bzzt をステーキングすると、後で withdraw3() を通じて20e18 Pangolin、200e18 Bzzt、200e18 Bzzone を引き出すことができる _exit 残高が作成されたことを意味します。この不一致を繰り返すことで、攻撃者は過剰なトークンをコントラクトから継続的に抽出しました。

攻撃分析

以下の分析は、トランザクション 0x7fcd5882...323f8d に基づいています。

• ステップ1：攻撃者は、0x9bce07d8bbe4f19dfe465710ff9612878bfe3302 にコントラクトをデプロイし、0.05 BNB で資金を調達し、資金を WBNB にラップし、20e18 Pangolin、20e18 Bzzt、および200e18 Bzzone を正確にスワップして、ステーキングコントラクトに取得したトークンを使用する権限を与えました。

  

• ステップ2：攻撃者は入力20e18で stake2() を呼び出し、20e18 Pangolin と20e18 Bzzt をステーキングコントラクトに転送し、攻撃者の共有 _exit 残高を20e18増加させました。

  

• ステップ3：攻撃者は次に、入力20e18で withdraw3() を呼び出しました。 withdraw3() は共有 _exit 残高のみをチェックしていたため、コントラクトはポジションが stake2() を通じて作成されていたにもかかわらず、20e18 Pangolin、200e18 Bzzt、および200e18 Bzzone を返しました。

  

• ステップ4：攻撃者は、同じトランザクション内で stake2() -> withdraw3() のサイクルを何度も繰り返しました。各ラウンドで、返された Pangolin と Bzzt の一部は次の stake2() 呼び出しに使用され、 Bzzone はステーキングコントラクトに戻されたため、後続の withdraw3() 呼び出しは引き続き成功できました。このループを通じて、攻撃者は Bzzt 残高を20e18から16,400e18に増加させました。

• ステップ5：攻撃者は取得したトークンを WBNB にスワップし、資金を BNB にアンラップし、約2.007e18 BNB を攻撃者EOAに返して、エクスプロイトを完了しました。

  

結論

このようなエクスプロイトを防ぐために、ステーキングコントラクトは各モードの会計を分離し、すべての引き出しパスが対応する預け入れパスの正確な資産構成と比率と一致することを確認する必要があります。

MYX インシデント

概要

2026年3月25日、Ethereum上のMYX Networkの sMYX コントラクトがエクスプロイトされ、プールから約667万 MYX トークン（利益約3,600ドル）が流出しました。根本原因は、sMYX コントラクトにおける転送関数の供給会計と配当分配ロジックの間の不完全な相互作用でした。細工されたアカウント間で sMYX を繰り返し転送することで、攻撃者は1株あたりの利益変数を膨張させ、裏付けのない配当を偽造し、当初預けた量よりも多くの MYX を抽出しました。

背景

sMYX コントラクト (0x404328...d27F66) は配当分配トークンモデルに従っています。ユーザーは buy 関数を通じて MYX トークンを預け入れ、そのステークを表す sMYX シェアを受け取ります。配当は、 stor_11 に格納されているグローバルアキュムレータ（1株あたりの利益）を使用して追跡されます。各ユーザーの請求可能な配当は、累積利益の比例シェアと記録された支払いベースラインとの差として計算されます。このモデルは、入ってくる価値が既存の保有者に再分配される、以前のリフレクション型トークンに概念的に似ています。

脆弱性分析

脆弱性は、供給会計と配当分配ロジックの間の不完全な相互作用から生じます。転送関数は、転送された量と現在の総供給量の比率に基づいてグローバルな1株あたりの利益変数を増加させることで、誤って新しい配当を導入します。この操作は、実際の MYX トークンの流入を伴わずに実行されるため、配当は実際の経済活動ではなく、内部会計から効果的に作成されます。同時に、関数は、実際にはトークンがバーンされていないにもかかわらず、サブトラクションヘルパーの逆の意味合いにより、記録された総供給量を転送された量だけ減少させます。

その結果、各連続した転送により、同じ転送量がますます小さい総供給量で割られるため、1株あたりの利益値が増加します。

攻撃分析

以下の分析は、トランザクション 0x843c9ea7...a55b90 に基づいています。

• ステップ1：攻撃者は、フラッシュスワップを通じて資本を調達し、それを MYX に変換し、次に sMYX コントラクトに預け入れて、配当システム内で支配的なシェアポジションを確保し、将来のほとんどの報酬分配を制御できるようにしました。

• ステップ2：攻撃者は、ポジションを2つの細工されたコントラクトに分割し、配当実現と状態操作を交互に行う連携ループを開始し、脆弱な会計パスの繰り返し通過を可能にしました。

• ステップ3：細工されたアカウント間での繰り返し転送を通じて、攻撃者はプロトコルの1株あたりの利益変数を人為的に膨張させ、同時に記録された総供給量を減らし、裏付けのない配当を作成し、その分配率を増幅させました。

• ステップ4：各操作サイクルの後に継続的に引き出すことで、攻撃者はこれらの偽造された報酬の大部分を抽出し、新しい資本を導入せずにプロトコルから MYX リザーブを効果的に使い果たしました。

• ステップ5：攻撃者はすべてのポジションを終了し、抽出された MYX を WETH にスワップし、フラッシュローンを返済し、残りの残高を利益として保持しました。

結論

このインシデントは、単なるポンジのような経済設計の帰結ではなく、配当会計の実装における重大な欠陥です。このような脆弱性を軽減するために、転送操作は総供給量に影響を与えたり、配当分配をトリガーしたりしてはならず、1株あたりの利益更新は実際の資産が導入された場合にのみ発生する必要があります。

未知のインシデント 4

概要

2026年3月26日、BNB Chain上の紹介報酬付き TUR ステーキングコントラクトが、約133,500ドルの損失を被りました。 Stake コントラクトは、単一トランザクション内で操作可能なライブAMMスポット価格を使用して預け入れ価値を計算しました。攻撃者はフラッシュローンを使用して TUR の価格を膨張させ、インフレウィンドウ中にステーキングし、自己制御の紹介アカウントを通じて過剰な TUR 報酬をドレインしました。

背景

Stake コントラクト (0x03D809...415Abe) は、紹介報酬付きの TUR ステーキングコントラクトです。ユーザーはまず bind() を通じてアップラインをバインドし、次に stake() を呼び出します。これにより、ステーキングされた TUR がバーンされ（0xdead に送信され）、ユーザーに内部 power が付与されます。これは、ユーザーが後で請求できる TUR 報酬の量を決定する重みです。

power は固定比率では割り当てられません。代わりに、 getPowerAmount() は、2つのライブAMM価格（TUR/NOBEL と NOBEL/USDT）をチェーン化して、預け入れられた TUR を USDT 額面に変換します。これらの価格は両方とも現在のペアリザーブから読み取られます。コントラクトはまた、 _distributeRefPower() を通じて、第一および第二レベルの紹介者にボーナスパワーを付与します。

脆弱性分析

根本原因は、Stake コントラクトにおける安全でないスポット価格依存でした。各預け入れ時に、 stake() は uValue = getPowerAmount(amount) を計算し、それを _power = _uValue * 100 に変換し、ステーカーの会計を更新してから、 _distributeRefPower() を呼び出して追加のパワーを紹介者に伝播します。

具体的には、 uValue は次のように計算されます。

$uValue=getPowerAmount(amount)uValue\; =\; getPowerAmount(amount)$

ここで、 getPowerAmount() は実質的に次のようになります。

$amount\times \text{TUR/NOBEL スポット価格}\times \text{NOBEL/USDT スポット価格}amount\; \backslash times\; \backslash text\{TUR/NOBEL\; スポット価格\}\; \backslash times\; \backslash text\{NOBEL/USDT\; スポット価格\}$

実装は getReserves() を介してこれらの価格を現在のペアリザーブから直接読み取るため、ステーキング評価は、操作耐性のあるオラクルやTWAPではなく、同トランザクションのスポット価格に完全に依存します。

これにより、攻撃者は TUR のオンチェーン評価を一時的に膨張させ、操作されたウィンドウ中にステーキングし、誇張された uValue と power を受け取ることができました。紹介ロジックは損害を増幅させます： _distributeRefPower() はステーカーのパワーの20％を第一紹介者に、5％を第二紹介者に付与しますが、これらの追加割り当ては、それらの紹介者の対応する rewardDebt 更新とは一致しません。その結果、攻撃者が制御する紹介アカウントは、Stake コントラクトから不均衡な TUR 報酬をすぐに請求できました。

攻撃分析

以下の分析は、トランザクション 0x96c9ce3c...81e348 に基づいています。

• ステップ1：攻撃者は、ListaDAOのMoolahコントラクトから1,900,000e18 USDT をフラッシュローンとして借りました。

• ステップ2：攻撃者は、借入資本を使用して NOBEL-USDT および TUR-NOBEL プールを操作し、一時的に TUR のスポット評価を急激に上昇させました。

• ステップ3：操作されたウィンドウ中に、攻撃者は7,770,707e18 TUR を Stake コントラクトにステーキングしました。トランザクションは、大幅に膨張した uValue 8,283,864e18 および対応する power 828,386,488e18 を示す StakeEvent を発行しました。

• ステップ4：攻撃者はすでに自己制御の紹介アカウントを手配していたため、 _distributeRefPower() は操作されたステーキングから派生した追加の報酬パワーをそれらに授与しました。第一および第二紹介者は、予想される20％および5％の紹介割り当てを受け取りました。

• ステップ5：ブーストされた紹介アカウントは、次に Stake コントラクトから TUR 報酬を請求しました。同じトランザクションで、 Stake は15,238,941e18 TUR を 0xFd11...AcEaB に、3,809,924e18 TUR を 0x9007...E550B に転送しました。両方のアドレスは直ちに同じ額を攻撃者に転送しました。4:1の支払い比率は、コントラクトの20％対5％の紹介パワー分割と一致します。

• ステップ6：トランザクションは、 claim() 実装が請求者に報酬を送る前に3％の TUR 手数料を請求することと一致して、 Stake からファンドウォレット 0xb302...89923 に流れる請求手数料も示しています。

• ステップ7：増幅された TUR 報酬を抽出した後、攻撃者は収益を USDT にスワップし、1,900,000 USDT のフラッシュローンを返済し、133,490e18 USDT を 0xEf67...4e5898 に利益として転送しました。

結論

このインシデントは、 TUR トークン自体のLP配当会計ではなく、 Stake コントラクトにおける操作可能な報酬評価モデルによって引き起こされました。ステーキングパワーと紹介報酬をライブAMMリザーブ比率に結び付けることで、コントラクトはフラッシュローンで資金調達された攻撃者が TUR のスポット価格を膨張させ、過剰な報酬パワーを製造し、自己制御の紹介アカウントを通じて TUR をステーキングコントラクトからドレインすることを可能にしました。より安全な設計は、スポットリザーブ価格設定を操作耐性のあるオラクルまたは十分な長さのTWAPに置き換え、紹介パワーの増加が整合性のある報酬負債会計とペアになることを保証するでしょう。

EST Token インシデント

概要

2026年3月27日、BNB Chain上の BNBDeposit コントラクトが、 BNBDeposit におけるスポット価格依存と EST トークンにおける不完全なバーンメカニズムという2つの問題により、約92,300ドルの損失を被りました。価格依存により、攻撃者は大量の EST を取得でき、不完全なバーンメカニズムにより、攻撃者はサンドイッチスタイルの操作を通じて EST-WBNB プールをドレインできました。

脆弱性分析

インシデントの根本原因は二重です。

1. BNBDeposit コントラクト (0xE71547...d29A61) の onTokenReceived() 関数は、コントラクトの残高と EST のスポット価格に基づいて、ユーザーの請求可能額を計算しました。これらは両方とも簡単に操作可能です。

   

2. EST トークン (0xD4524B...498a91) は、攻撃者が EST-WBNB プールで EST をバーンできる、不完全なバーンメカニズムを実装していました。

   

その結果、攻撃者は両方の脆弱性を利用してサンドイッチ攻撃を実行し、 EST-WBNB プールから WBNB を吸い上げました。

攻撃分析

以下の分析は、トランザクション 0x2f1c33ea...bd1626 に基づいています。

• ステップ1：攻撃者はMoolahから250,000e18 WBNB を借りました。攻撃のために15e18 WBNB を BNB にアンラップしました。

• ステップ2：攻撃者は BNBDeposit に34回（合計10.2e18 BNB）0.3e18 BNB を繰り返し転送しました。各直接転送は預け入れロジックをトリガーしました。このステップで、攻撃者は約9,100e18 LPトークン（仮想会計）と2.65e18 WBNB をボーナスとして受け取りました。

• ステップ3：攻撃者は400e18 WBNB を約822M EST とスワップし、 BNBDeposit を受信者として設定し、 BNBDeposit の EST 残高とプールの EST 価格の両方を膨張させました。

• ステップ4：攻撃者は1e18 EST を BNBDeposit に転送して請求メカニズムをトリガーし、増幅された価格と残高に基づいて20M EST を受け取りました。

• ステップ5：攻撃者は245,000e18 WBNB を約330M EST とスワップし、 BNBDeposit を受信者として設定しました。

• ステップ6：攻撃者は約150回、転送スキームアクションを実行して、 EST-WBNB プールで EST を継続的にバーンしました。

• ステップ7：攻撃者は残りの EST を245,560e18 WBNB とスワップしました。

• ステップ8：攻撃者はフラッシュローンを返済し、150 WBNB の利益を上げました。

結論

このインシデントは、スポット価格依存と不完全なバーンメカニズムという2つの問題によって引き起こされました。同様のリスクを軽減するために、プロジェクトはデプロイ前に信頼できる価格オラクルと健全なトークンバーンロジックを確保する必要があります。

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよびクリプトコンプライアンスプロバイダーです。私たちは、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃傍受、インシデント分析、不正資金追跡、およびAML/CFT義務の遵守を、プロトコルおよびプラットフォームのライフサイクル全体にわたって実行できるようにする製品とサービスを構築しています。

BlockSecは、著名なカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃を複数報告し、複数のハッキングをブロックして2000万ドル以上を救済し、数十億ドル相当の暗号資産を保護しました。

• 公式ウェブサイト: https://blocksec.com/

• 公式Twitterアカウント: https://twitter.com/BlockSecTeam

• 🔗 BlockSec監査サービス : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalconコンプライアンス