北京時間の2023年10月18日19時48分59秒、Hope.moneyの融資プールはフラッシュローンの実施に基づいて攻撃されました。
Hope.money は、HopeLend 融資プラットフォーム、HopeSwap 分散型取引所、安定通貨 $HOPE、ガバナンス トークン $LT を構築し、ユーザーにフルスタックの分散型金融サービスを提供しています。
この攻撃に関与したプロトコルは、ユーザーがプロトコルに流動性を提供したり、過剰担保ローンから収入を得たりできる分散型融資プラットフォームである HopeLend です。
一部始終
HopeLendのコード実装には、貸出プールに悪用可能な脆弱性が存在し、預金証明書を破棄する際に、整数の除算に誤りがあり、小数点部分が切り捨てられる問題が発生し、想定よりも少ない数の証明書が破棄されてしまう問題があった。取得および期待される一貫した値のトークン。
攻撃者はこの欠陥を悪用し、Hope.money に資金が存在していたさまざまな融資プールを空にしました。
その中で、hEthWbtc 融資プールは 73 日前に展開されましたが、そこに資金がなかったため、ハッカーは融資プールに大量の資金を注入して割引率を大幅に引き上げ、それによって融資プール内の他のすべての融資をすぐに空にしました。ブロックトランザクション、プール資金。
さらに驚くべきことは、この脆弱性を悪用したハッカーは、その脆弱性を悪用するための資金を取得していなかったということです。彼の攻撃取引は、最有力候補によって発見されました。最有力候補は、彼の攻撃行動を模倣し、攻撃収益をすべて盗むことに成功しました (527 ETH)、そして最終的に攻撃収益の 50 % (263 ETH) が、ブロック (ペイロード) をパッケージ化したマイナーに賄賂を渡すためにフロントランナーによって使用されました。
脆弱性を発見した最初のハッカーは、ブロック 18377039 で攻撃コントラクトを作成し、ブロック 18377042 で攻撃コントラクトを呼び出しました。このとき、フロントランナーはメモリ プール内のトランザクションを監視し、フロントランナーとして攻撃コントラクトをシミュレートしました。実行中のコントラクトへの入力は同じブロック 18377042 で悪用され、ブロック 18377042 の最初のハッカーのトランザクションは、フロントランナーの後ろに順序付けされていたために実行に失敗しました。
資金の行き先
最有力候補が利益を受け取ってから 1 時間後、資金を 0x9a9122Ef3C4B33cAe7902EDFCD5F5a486792Bc3A に移動しました。
10月20日13時30分23秒、公式チームと思われる人物がそのアドレスに連絡し、優勝者に報酬として26ETH（利益の10％）を残すことを許可し、優勝者から返信を受け取りました。
1 時間の通信の後、最終的な資金は GnosisSafe のマルチ署名保管庫に転送されました。
以下に、実際の脆弱性と、ハッカーがそれを悪用した方法の詳細を示します。
事前情報
*HopeLend の融資プロトコル実装は Aave からフォークされているため、脆弱性に関連するコア ビジネス ロジックは Aave のホワイト ペーパーから参照されています。
0x00 預金とローン
Aave は純粋な DeFi であり、融資ビジネスは流動性プールを通じて実行され、ユーザーが Aave に流動性を預けると、融資による収益を受け取ることが期待されます。
融資収益は全額が利用者に分配されるわけではなく、利息収入の一部がリスク準備金に含まれますが、その割合は小さく、融資収益の大部分は流動性を提供する利用者に分配されます。
Aave で預金を貸付する場合、Aave は割引を使用して、さまざまな時点での預金数を流動性プールの初期時点での預金数に換算するため、それぞれの原資産に対応する元利金の合計が株式数は直接計算できます。金額（株式数）*指数（割引率）を使用して計算されます。これにより、計算と理解が大幅に容易になります。
ファンドの購入と同様のプロセスとして理解できます。ファンドの初期の純価値は 1 です。ユーザーは 100 元を投資して 100 株を取得します。一定期間後に純価値は 1.03 になったとします。このとき、ユーザーは 100 元を投資します。 、ユーザーは再度 100 元を投資し、100 株を取得します。は 97 で、ユーザーの合計シェアは 197 です。
これは実際には、インデックス (正味価値) に従って資産を割り引いています。これが行われる理由は、残高を使用して、ユーザーの実際の元本と利息の合計に現在のインデックスが乗算されるためです。 2回目入金時のユーザーの正しい元利合計は100 * 1.03 + 100 = 203となります。割引処理が行われない場合、2回目の入金後の元利合計は(100)となります。 + 100) * 1.03 = 206 となりますが、これは誤りですが、割引を行うと元利金の合計は (100 + 100 / 1.03) * 1.03 = 103 + 100 = 203 となり、203 の結果が正しいことになります。
攻撃プロセス
0x25126......403907(hETHWBTC pool)
0x5a63e....844e74 (攻撃契約の現金化)
アタッカー：
1. 初回フラッシュローン資金を融資し、担保に入れます
攻撃者は最初に Aave Flash Loan から 2,300 WBTC を借り、HopeLend に 2,000 WBTC を誓約し、資金は HopeLend の hEthWbtc コントラクト (0x251...907) に転送され、対応する 2,000 hETHWBTC が取得されます。
2. 空のローンプールを使用して初期割引率 (liquidityIndex) を操作します。
HopeLend からフラッシュ ローンで 2,000 WBTC を借ります。
現在の値は 1 hETHWBTC = 1 WBTC です。
WBTC と引き換えに ETHWBTC を入出金する通常の操作は交換比率に影響しません (交換比率は利息が得られる場合にのみ影響を受け、1 hETHWBTC はより多くの WBTC を獲得します)。
この時点で、ハッカーは一連の複雑な操作を通じて割引率を操作し始めます。
• ハッカーは取得した 2,000 WBTC を直接送金で HopeLend の hEthWbtc 契約 (0x 251…907) に送金しましたが、このステップはローンの返済ではありません。
• その後、ハッカーはステップ 1 で約束した WBTC (1999.999...) のほとんどを引き出したため、前のステップではプール内の資産を補充するために WBTC を返送する必要がありました。
• 最終的にハッカーは hEthWbtc の最小単位 (1 e-8) だけを保持しますが、少し残す必要があるためここでは完全には言及できませんが、割引率 (liquidityIndex) を計算する際に新たに追加されます。はい、クリアすると割引率 (liquidityIndex) が 0 になり、プール内の割合がアンバランスになることはありません。
• 前のステップで hEthWbtc の大部分を破棄するために交換された wBTC と、前回のフラッシュ ローンからの残りの wBTC は、ホープレンド プールに貸し出されたフラッシュ ローンに返還され、支払総額は 2001.8 WBTC (1.8 の利息を含む) となります。 wBTC）。
• 上記のプロセスにより、hEthWbtc の大部分が破壊され、ハッカーアカウントに hEthWbtc の最小単位 (1 e-8) が 1 つだけ残ります。これにより、hETHWBTC の総量は減少しますが、融資プールには 2001.8 wBTC が存在します。これは、割引を意味します。当時の金利（流動性指数）は驚異的な1億2,600万に達しました。これには、預金利用者の利益は基本的にプール内の流動性の増加によってもたらされるという知識が含まれており、貸出プールは預金金利と利用率に基づいて借入金利と預金金利を動的に調整します。
ここで、プールがフラッシュ ローンの金利 (1.8 WBTC) から追加の流動性を受け取ると、70 パーセント (126, 000, 000) が、単位あたりの預金 (hEthWbt) の割引価値を計算するために使用される流動性インデックス (liquidityIndex) に含まれます。
ハッカーの操作前はプールが空だったので、返済後の totalLiquidity は 1 のみ、金額は 126000000、初期の流動性インデックスは 1 で、結果は 126000001 になります。
3. 割引率の拡大を継続
ハッカーは HopeLend からのフラッシュ ローンを通じて 2,000 WBTC を借り続け、毎回追加で 1.8 WBTC を返し、毎回 LiquidityIndex が 126,000,000 ずつ蓄積することを可能にしました。
ハッカーはこのプロセスを 60 回繰り返し、最終的に流動性インデックスは 7,560,000,001 に達し、攻撃者が保有する hEthWBTC の最小単位の割引価値は 75.6 WBTC (約 214 万ドル) に達する可能性がありました。
これにより、ハッカーが hEthWBTC を制御し、その値を歪めることも可能になります。
4. 他の既存資金の融資プールを空にして収入を生み出す
その後、攻撃者は hEthWBTC の最小単位 1 を担保として使用し、HopeLend の他の 5 つのトークン プールから大量の資産を貸し出しました。
含む：
175.4 - WETH
145, 522.220985 - USDT
123, 406.134999 - USDC
844, 282.284002229528476039 - HOPE
220, 617.821736563540747967 - stHOPE
これらのトークンは収益として Uniswap を通じて WBTC と WETH に変換され、さまざまな手数料を差し引いた後のハッカーの最終利益は約 263 WETH (賄賂のペイロードを除くと 263.9 WETH) でした。
ハッカーが他のプールから多額の資金を借りることができる理由:
お金を借りたり、預金を引き出したりするときは、融資契約によりユーザーの住宅ローンの資産状況がチェックされ、ローンが住宅ローンを超えていないことが保証されます。
割引率は以前にハッカーによって操作されており、割引率はnormalizedIncome乗数を使用して住宅ローン価値の計算に組み込まれるため、その手にあるhEthWBTCの1単位の住宅ローン価値は75.6 WBTCにもなります。
ハッカーは他のプールからお金を借りるたびに、担保資産の検証を簡単に通過しました。
この時点で、攻撃者は、liquidityIndex を操作するために合計 2000+ 1.8* 60 WBTC を HopeLend に投資し、hEtthWBTC の 1 ユニットのみを残しました。
5. 主要な脆弱性ポイント (整数の除算エラー) を悪用してキャッシュアウトする
以前に投資した wBTC を引き出すために、攻撃者は別の攻撃コントラクト: 0x 5 a 63 e....844 e 74 を展開し、その中でdrawAllBtc() メソッドを呼び出しました。
脆弱性のプロセスは次のとおりです。
① 初回入金額 151.20000002 wBTC 現在の流動性インデックス (1 最小単位 hEthWBTC= 75.6 wBTC) に従って、攻撃者は最小 2 単位の hEthWBTC を取得します。
② 113.4 wBTC を出金し、対応する hEthWBTC シェアを逆算し、hEthWBTC に対して書き込み操作を実行します。
③ 113.4 wBTC では最小単位 1.9999999998 個の hEthWBTC を破壊する必要がありますが、div 関数の精度により hEthWBTC 最小単位 1 個しか破壊されず、悪用可能な脆弱性となり、ハッカーは最小単位 1 個の hEthWBTC を保持することができます。
重大な脆弱性
hEthWBTC の burn メソッドは高精度分割 rayDiv を呼び出します。
ここ：
a= 11340000000 (WBTCは撤回予定)
b=7560000001000000000000000009655610336 (割引率)
(a* 1e27+b/2)/b = 1.9999999998 ですが、solidity 独自の div メソッドは切り捨てて 1 を返します。これは 11340000000 / 7560000001 に相当します。小数点以下の桁は除算後に切り捨てられます。
0x5a63 (攻撃コントラクト - キャッシュアウト) は 75.60000001 WBTC の入金を継続し、hEthWBTC の最小単位をさらに 1 つ取得し、hEthWBTC の最小単位を 2 つ保持し続けます。
113.40000000 wBTC を引き出し、75.60000001 wBTC を入金するこのサイクルで、攻撃者は毎回 37.8 wBTC を何もないところから入手できます。
58 サイクル後、攻撃者は以前に投資したすべての wBTC を引き出し、Aave のフラッシュ ローンを無事に返済しました。
結論は
hEthWBTCの融資プールは初期化されていないため、攻撃者は簡単にliquidityIndexを操作して最大値まで増やすことができ、整数除算の切り捨て誤差により出金率が除数として大幅に増幅された後、出金が容易になります。ワンブロックに先行投資です。
適切に機能している融資プールでは、融資プールにはすでに流動性があるため、融資利子のわずかな増加によって割引率が大幅に上昇することは容易ではありません。
