損失は​​4000万ドルを超える、GMXハッキング事件の分析

  • GMXがハッキング攻撃を受け、4000万ドル以上の損失が発生。攻撃者は再入性脆弱性を悪用し、レバレッジ機能を利用したショートポジションで不正操作を行った。

  • 脆弱性の核心:

    • executeDecreaseOrder関数の設計不備(外部アカウント前提のパラメータにスマートコントラクトアドレスが許可された)
    • 償還プロセス中に攻撃者がシステムに再侵入し、内部状態を操作可能に
  • GLP償還メカニズムの仕組み:

    • ユーザーは保有GLP比率に応じてAUM(運用資産総額)から資産を受け取る
    • AUM計算式には未実現損失/利益が含まれることが問題の伏線に
  • 攻撃手法:

    1. レバレッジ有効状態で大規模WBTCショートポジションを開設
    2. 未実現損失がAUMを人為的に増加させ(実際の資金増加なし)
    3. 水増しされたAUMを悪用し、GLP保有量を超える不正償還を実行
  • 根本的な問題:

    • AUM構成要素へのセキュリティチェック不備
    • 契約アドレスの身元検証欠如
    • レバレッジ機能と償還ロジックの連動リスク評価不足

この事件は、DeFiプロトコルにおける複雑な金融ロジック実装時には、状態操作防止と再入可能性対策が不可欠であることを示唆しています。

要約

GMXはハッカー攻撃を受け、4,000万ドル以上の損失が発生しました。攻撃者は再入性脆弱性を悪用し、契約のレバレッジ機能が有効な状態でショートポジションを保有しました。

問題の根本は、executeDecreaseOrder関数の不適切な使用にあります。関数の最初のパラメータは外部アカウント(EOA)であるべきでしたが、攻撃者はスマートコントラクトのアドレスを渡しました。これにより、攻撃者は償還プロセス中にシステムに再侵入し、内部状態を操作し、最終的に保有していたGLPの実際の価値をはるかに超える資産を償還することができました。

GLPの通常の償還メカニズム

GMXにおいて、GLPは流動性プロバイダートークンであり、財務資産(USDC、ETH、WBTCなど)の一部を表します。ユーザーがunstakeAndRedeemGlpを呼び出すと、システムは以下の式を使用して返還すべき資産の量を計算します。

償還金額 = (ユーザーGLP / 総GLP供給量) * AUM

AUM(運用資産総額)の計算方法は次のとおりです。

AUM = すべてのトークンプールの合計価値 + グローバルショート未実現損失 - グローバルショート未実現利益 - 留保額 - デフォルト控除(aumDeduction)

このメカニズムにより、GLP 保有者は財務省の実際の資産の比例配分を受け取ることが保証されます。

レバレッジが有効になった後の問題

enableLeverage がオンになっている場合、ユーザーはレバレッジポジション(ロングまたはショート)を開くことができます。攻撃者は、GLP を償還する前に、WBTC の大規模なショートポジションを開いていました。

ショートポジションは開設と同時にグローバルショートサイズを増加させるため、システムは価格が変化していないにもかかわらず、ショートポジションが損失を出していると想定し、この未実現損失の一部をVaultの「資産」としてカウントし、運用資産残高(AUM)を人為的に増加させます。Vaultに実際に価値が追加されることはありません。しかし、償還額の計算はこの水増しされたAUMに基づいて行われるため、攻撃者は本来受け取るべき金額をはるかに超える資産を手に入れることができます。

攻撃プロセス

トランザクションへの攻撃

https://app.blocksec.com/explorer/tx/arbitrum/0x03182d3f0956a91c4e4c8f225bbc7975f9434fab042228c7acdc5ec9a32626ef?line=93

損失は​​4000万ドルを超える、GMXハッキング事件の分析

損失は​​4000万ドルを超える、GMXハッキング事件の分析

最後に書いた

この攻撃は、GMXのレバレッジメカニズムと再入可能性保護設計に重大な欠陥があることを露呈しました。根本的な問題は、資産償還ロジックが運用資産残高(AUM)に過度に依存し、その構成要素(未実現損失など)に対する十分なセキュリティチェックを実施していないことです。同時に、主要機能において、呼び出し元の身元前提(EOA vs. 契約)の必須検証も欠如しています。このインシデントは、資金に関わる機密性の高い操作においては、特に複雑な金融ロジック(レバレッジ、デリバティブなど)を導入する際には、システム状態が操作されないことを保証し、再入可能性と状態汚染によるシステムリスクを厳格に防止する必要があることを開発者に改めて認識させました。

共有先:

著者:BlockSec

本記事はPANews入駐コラムニストの見解であり、PANewsの立場を代表するものではなく、法的責任を負いません。

記事及び見解は投資助言を構成しません

画像出典:BlockSec侵害がある場合は、著者に削除を連絡してください。

PANews公式アカウントをフォローして、一緒に強気相場と弱気相場を乗り越えましょう
おすすめ記事
たった今
23分前
1時間前
2時間前
2時間前
3時間前

人気記事

業界ニュース
市場ホットスポット
厳選読み物

厳選特集

App内阅读