インデックス化された金融セキュリティインシデントの分析

インデックス化された金融セキュリティインシデントの分析

0x.1 背景

2021年10月15日02:38(UTC+8)、当社の内部監視システムが不正なフラッシュローン取引を検知しました。

当社の監視システム
当社の監視システム

調査の結果、Indexed Financeを標的とした価格操作攻撃であることが判明しました。具体的には、攻撃者はこのプロジェクトで使用されている(価格計算に使用される)不具合のある数式を悪用して攻撃を実行し、1600万ドルの利益を得ました。

ソーシャルメディア上ではすでにいくつかの議論が行われており、プロジェクト側も公式な事後分析 (Indexed Attack Post-Mortem)を公開しています。 しかし、既存の分析では、このセキュリティインシデントの全体像を把握するには至っていません。 そのため、本ブログでは、プロジェクトの仕組み、脆弱性、攻撃、および利益について、包括的な分析を提供することを目指します。

0x1.1 関連コントラクトアドレス

  • MarketCapSqrtController: 0x120c6956d292b800a835cb935c9dd326bdb4e011

  • DEFI5: 0xfa6de2697d59e88ed7fc4dfe5a33dac43565ea41

  • CC10: 0x17ac188e09a7890a1844e5e65471fe8b0ccfadf3

0x1.2 攻撃トランザクション

  • 攻撃TX-I: 0x44aad3b853866468161735496a5d9cc961ce5aa872924c5d78673076b1cd95aa

  • 攻撃TX-II: 0xbde4521c5ac08d0033019993b0e7e1d29b1457e80e7743d318a3c27649ca4417

0x2. Indexed Financeの仕組み

脆弱性/攻撃をよりよく理解するために、Indexed Financeの仕組みを説明するためにDEFI5(攻撃者にハッキングされたプール)を使用します。

0x2.1 バインディングトークン

DEFI5は、EthereumのDeFiプロジェクトのトップ5トークンに対する取引サービスを提供するように設計されています。具体的には、Indexed FinanceはMarketCapSqrtControllerを通じて市場価値に基づいてトークンランキングを更新します。 トップ5トークンの順序は時間の経過とともに変化する可能性があるため、DEFI5プールで使用されるトークンの数は5を超える場合があります。これは、以下のコードに示すとおりです。

図1
図1

図1は、新しいトークンをバインドするために、DEFI5がMarketCapSqrtControllerのreindexPools関数からのみ呼び出すことができる_bind関数をトリガーする必要があることを示しています。

図2
図2

図2は、MarketCapSqrtControllerがまず市場からトークン情報(TotalSupplyと価格を含む)を取得し、次に市場価値に基づいてランキングを計算することを示しています。 reindexPool関数を呼び出す際に、トップトークンのアドレスが引数として渡され、reindexTokens関数が呼び出されます。 新しく追加されたトークンは、DEFI5の元のトークンを置き換えることなく、DEFI5にバインドされることに注意してください。

0x2.2 次は何?

トークンバインディングの後、DEFI5は取引を有効にするために、トークンのステータスを示す変数readytrueに設定する必要があります。

図3
図3

コードロジックによれば、コントラクトの初期化を除いて、readygulp関数でのみ設定できます。 図3に示すように、これはトークンバランスが_minimumBalances以上の場合に発生します。同時に、初期トークンウェイト(denorm)は以下の数式に基づいて計算されます。

0x3. 脆弱性分析

脆弱性のあるコードは、MarketCapSqrtControllerのupdateMinimumBalance関数に属します。

図4
図4

図4に示すように、updateMinimumBalanceは、readyがfalseのトークンのminimumBalanceをpoolValueの1/100に変更できます。poolValueの計算が脆弱性の鍵となります。

図5
図5

図5の計算は、以下の数式を実装したものです。

ただし、この数式には2つの潜在的な問題があります。

  • 1つのトークンの流動性を使用してプール全体の価値を推定している。
  • プールのウェイト(_totalWeight)とトークンのウェイト(token.denorm)は、流動性の変化の影響を受けない。実際には、外部市場の市場価値の影響を受けている。さらに、それらの変化は時間制限によって制限される、つまり、1時間あたり1%増加または減少する。

要するに、攻撃者はフラッシュローンを使用してトークンの流動性に大きな変化を即座に引き起こし、プールとトークンのウェイトがそれに伴って変化しないようにすることで、poolValueを操作できます。 これにより、minimumBalancereadyがfalseのトークン)を操作して価格操作攻撃を開始できます。

0x4. 攻撃分析

攻撃は以下の9つのステップで構成されます。

ステップ1: reindexPool関数を呼び出してSUSHIをバインドします。呼び出し前、DEFI5プールにはUNI、AAVE、COMP、SNX、CRV、MKRの6つのトークンが含まれていました。SUSHIの市場価値がトップ5になると、SUSHIがプールに追加されます。

ステップ2: IndexPoolでサポートされている6つのトークン(UNI、AAVE、COMP、SNX、CRV、MKR)すべてをSushiSwapを通じて貸し付けます。

ステップ3: 借り入れたトークンを使用して(CMOPを例にとる)、swapExactAmountIn関数を複数回呼び出してUNIをスワップします。

注意1:ここでは、MAX_IN_RATIOの制約により複数回実行されます。トークン残高の半分までしかスワップできません。

注意2:このステップでは、プール内のUNI(firstToken)の残高が大幅に減少するため、poolValueが大幅に過小評価されます。

ステップ4: updateMinimumBalance関数を呼び出して、SUSHIのminimumBalanceを変更します。

ステップ3で計算された異常なpoolValueのため、minimumBalanceは通常の値よりも小さいことに注意してください。

ステップ5: 流動性を提供するためにjoinswapExternAmountIn関数を呼び出してLPトークンを準備します。これらのLPトークンは、より多くのSUSHIをスワップするために使用されることがわかります。

注意:MAX_IN_RATIOの影響により、joinswapExternAmountIn関数は複数回呼び出す必要があります。

ステップ6: 大量のSUSHIを貸し付けてプールに転送し、その後gulp関数を呼び出してSUSHIのreadytrueに設定することによって、DEFI5プール内のSUSHIのウェイトを操作します。これにより、SUSHIの初期ウェイト(denorm)は高い値になります。

ステップ7: exitPool関数を呼び出して、LPトークンを基盤となるトークン(UNI、AAVE、COMP、SNX、CRV、MKR、SUSHI)にスワップします。

exitPool関数は各トークンのウェイトを考慮しないため、基盤となるトークンは均等な割合で返還されることに注意してください。

ステップ8: SUSHIを使用してjoinswapExternAmountIn関数を呼び出してLPトークンをスワップし、流動性を提供します。この時点でのSUSHIの異常なウェイトのため、より多くのLPトークンが得られます。

joinswapPoolAmountIn関数は、受け取った基盤トークン(この場合はSUSHI)のウェイトに基づいてLPトークンをミントすることに注意してください。

ステップ9: ステップ8で得たLPトークンを使用してexitPool関数を呼び出し、プールから資金を引き出します。

0x5. 利益分析

調査によると、攻撃者が使用したすべての資金(取引手数料を含む)はTornado Cashから来ています。

合計で2つの攻撃トランザクションがあります。

  • 最初のトランザクションでは、攻撃者は以下を獲得しました:6,226.8 AAVE、15 ETH、192,358.6 UNI、5,459.5 COMP、721,611.3 CRV、16,680.6 SNX、406.5 MKR。

  • 2番目のトランザクションでは、攻撃者は以下を獲得しました:109.6 MKR、17,844 UMA、1,002.4 COMP、34,602.5 UNI、131,645.4 BAT、28,754.1 SNX、1,273.6 AAVE、124,194.2 CRV、33,215.4 LINK、5.24 YFI。

さらに、攻撃者はいくつかの失敗した試みも行っています。

本稿執筆時点では、攻撃者が得た利益は1600万米ドル相当であり、まだ移動されていません。

BlockSecについて

BlockSecは、2021年に世界的に著名なセキュリティ専門家グループによって設立された、先駆的なブロックチェーンセキュリティ企業です。同社は、Web3の普及を促進するために、新しいWeb3の世界のセキュリティと使いやすさを向上させることにコミットしています。この目的に向かって、BlockSecはスマートコントラクトとEVMチェーンのセキュリティ監査サービス、セキュリティ開発と脅威のプロアクティブなブロックのためのPhalconプラットフォーム、資金追跡と調査のためのMetaSleuthプラットフォーム、そしてWeb3ビルダーが仮想通貨の世界を効率的にサーフィンするためのMetaSuites拡張機能を提供しています。

今日まで、同社はMetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300を超える著名なクライアントにサービスを提供し、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalなどの著名な投資家から2回の資金調達で数千万米ドルを受け取っています。

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

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

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.