#2: Euler Finance事件：2023年最大のハッキング

2023年3月13日、当社のシステムはEuler Financeのレンディングプールがフラッシュローン攻撃を受け、1億9700万ドルの損失が発生したことを検知しました。まずコミュニティに警告を発し、その後、根本原因の特定に役立つ分析を提供しました。

1/ @eulerfinance is attacked. The root cause is due to the lack of liquidity check in the function donateToReserves()https://t.co/stWtPWK900

See the detailed attack steps below. https://t.co/bm10OJHiXu pic.twitter.com/TDbYuzVWHe
— BlockSec (@BlockSecTeam) March 13, 2023

このインシデントの根本原因は、donateToReserves() 関数におけるソルベンシーチェックの欠如にあります。具体的には、脆弱なコントラクトは、ユーザーのポジションがソルベントかどうかを確認せずに、ユーザーが担保をプロトコルに寄付する機能を提供していました。さらに悪いことに、この悪いポジションを解消するために、プロトコルは清算人に対し、このポジションを清算するために支払うべき負債を少なくする大幅な割引を提供していました。攻撃者はこの機能を利用して大規模なポジションを作成し、それをソルベントではなくしました。その後、割引価格で担保を買い戻して利益を得ることができました。

背景

Euler Financeの概要

Euler Financeは、ユーザーが指定されたトークンを貸し借りできるEthereum上のレンディングプロトコルです。貸し手がEulerの流動性プールに預金すると、対応する量のETokens（利息が発生するERC20トークン）が発行され、彼らに送信されます。これらのETokensは、預け入れた元資産と引き換えることができます。

一方、流動性を借りた借り手はDTokensを受け取ります。これらのDTokensはERC20に準拠しており、保有者はそれを個別にバーンすることはできません。具体的には、トークンを誰にでも送信することはできませんが、誰でも受け取ることができますが、それを受け入れるには承認が必要です。元資産に関しては、借り手はローンに対する利息の支払いを担当し、その利息の一部はプロトコルの不良債務のカバーに使用されます。

Euler Financeのレバレッジ借り入れ（セルフ借り入れとも呼ばれる）とソフト清算メカニズムは、この攻撃の原因をよりよく理解するのに役立つ2つの重要な概念です。

レバレッジ借り入れ

Euler Financeはレバレッジ借り入れ機能を提供しており、ユーザーは再帰的な借り入れ戦略をシミュレートできます。簡単に言うと、ユーザーは担保を預け入れてETokensを発行し、それを担保としてさらにETokensを借りることができます。コントラクトは、対応する量のdTokensを負債トークンとして発行します。ユーザーのポジションの健全性は、ETokensとdTokensの値に基づいて計算されます。Euler Financeのドキュメントによると、ユーザーは最大19倍までレバレッジをかけることができます。レバレッジ借り入れ機能は、このインシデントで重要な役割を果たしました。この機能の支援なしには、攻撃者は利益を得ることができなかったでしょう。レバレッジ借り入れを通じて、攻撃者はフラッシュローンで得た初期資金のほぼ11倍にポジションサイズを増幅させました。

ソフト清算

Euler Financeのホワイトペーパーに概説されているように、ソフト清算メカニズムにより、清算人は、CompoundやAaveのようなプロトコルが採用している固定係数に限定されるのではなく、清算される当事者が柔軟に負債を返済できるようにします。ソフト清算とは、ポジションの健全性が低いほど、清算可能な担保の量が多くなることを意味します。このインシデントのデータによると、不良債務の場合は、ポジション内の担保の最大75％が清算対象となります。したがって、大幅に割引された担保の清算により、攻撃者はフラッシュローンを返済し、利益を確保することができました。

脆弱性分析

主な脆弱性、すなわちソルベンシーチェックの欠如は、ユーザーが自分のポジションからETokensをプロトコルの準備金に寄付として転送するために使用されるdonateToReserves() 関数内に存在します。通常のユーザーにとって、そのような行為を行うインセンティブや動機は通常ありません。実際、脆弱性は、donateToReserves() 関数がユーザーのポジションからETokensを転送する際に健全性チェックを実行しないという点にあります。これにより、攻撃者はレバレッジ借り入れによって作成された大規模なポジションからETokensを直接寄付することができ、ポジションの健全性が100％を下回り、不良債務が発生します。

設計によれば、Euler Financeは動的なクローズファクターを使用してポジションを「ソフト清算」します。要するに、ポジションの健全性が低いほど、そのポジションの担保のうち清算可能な割合が高くなります。不良債務の場合、清算率はポジション内の担保の最大75％（実際のエクスプロイトトランザクションに基づく計算）になる可能性があります。その結果、大幅な割引された担保の清算により、攻撃者はフラッシュローンを返済し、利益を得ることができました。

攻撃分析

異なるプールを標的とした複数の攻撃トランザクションがあります。

0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d (DAI)
0x71a908be0bef6174bccc3d493becdfd28395d8898e355d451cb52f7bac38617 (WBTC)
0x62bd3d31a7b75c098ccf28bc4d4af8c4a191b4b9e451fab4232258079e8b18c4 (wstETH)
0x465a6780145f1efe3ab52f94c006065575712d2003d83d85481f3d110ed13d9 (USDC)
0x3097830e9921e4063d334acb82f6a79374f76f0b1a8f857e89b89bc58df1f311 (stETH)
0x47ac3527d02e6b9631c77fad1cdee7bfa77a8a7bfd4880dccbda5146ace4088f (WETH)

攻撃手順は次のとおりです（最初の攻撃トランザクション0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111dを例として）：

攻撃者はフラッシュローンでAAVEを介して30M DAIを借入します。
攻撃者は20M DAIを預け入れ、20M eDAIを受け取ります。
Euler Financeはレバレッジ借り入れ機能を提供しているため、攻撃者は195M eDAIと200M dDAIを発行できます。現在、攻撃者は215M eDAIと200M dDAIを保有しています。
上記を続けます。10Mの負債が返済されたため、攻撃者はさらにeDAIを発行できます。現在、攻撃者は215M eDAIと190M dDAIを保有しています。
ステップ3を繰り返します。現在、攻撃者は410M eDAIと390M dDAIを保有しています。
攻撃者はdonateToReserve関数を呼び出して100M eDAIを寄付します。しかし、このプロセス中に、攻撃者のヘルスファクターはチェックされませんでした。この場合、ポジションは清算可能になり（310M eDAI vs 390M dDAI）、利益を得る機会が生まれます。
攻撃者は別のコントラクトアドレスを清算人（0xa0b3...）として使用してポジションを清算します。清算人（0xa0b3...）は310M eDAIと259M dDAIを受け取ります。
攻撃者は38.9M eDAIをバーンして、清算人のポジション（0xa0b3...）から38.9M DAIを引き出します（ソルベンシーチェックのため、それ以上は引き出せません）。
攻撃者はフラッシュローンを返済します。

鍵となる攻撃ステップ2〜7は、トランザクショントレースでラベル付けされています。

まとめ

これは2023年最大のハッキングであり、20歳のアルゼンチン人、フェデリコ・ハイメによって記録的な1億9700万ドルが盗まれました。彼はメディアに「紆余曲折があり、時に混乱し、矛盾した物語」を提供しました。「しかし、回収可能な資金はすべて」後にEuler Financeの宝庫アドレスに返還されました。ただし、少額（約20万ドル）が「意図せず」Lazarus Group—米国財務省が制裁を課したとされる北朝鮮の国家支援犯罪シンジケート—に送金されました。詳細で興味深い物語については、これらのリンク、すなわちリンク2およびリンク2を参照してください。

このインシデントの根本原因はソルベンシーチェックの欠如であり、教訓となります。実際、レンディングプロトコルにおいては、ユーザーのポジションに影響を与える可能性のあるいかなる手順に対しても、ポジションの健全性チェックを実装すべきかどうかを評価することが極めて重要です。さらに、プロジェクトチームは、レンディングプロトコルにおける大規模な清算を積極的に監視し、そのようなイベントを迅速に検知して対応するための効果的なアラートシステムを確立する必要があります。