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

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

このインシデントの根本原因は、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を例にとります）。

1. 攻撃者はフラッシュローンを介してAAVEから3000万DAIを借入しました。
2. 攻撃者は2000万DAIを預け入れ、2000万eDAIを受け取りました。
3. Euler Financeはレバレッジ借入機能を提供しているため、攻撃者は1億9500万eDAIと2億dDAIをミントできます。現在、攻撃者は2億1500万eDAIと2億dDAIを保有しています。
4. 上記を継続。攻撃者がさらにeDAIをミントできるように、1000万の負債が返済されました。現在、攻撃者は2億1500万eDAIと1億9000万dDAIを保有しています。
5. ステップ3を繰り返しました。現在、攻撃者は4億1000万eDAIと3億9000万dDAIを保有しています。
6. 攻撃者はdonateToReserve関数を呼び出し、1億eDAIを寄付しました。しかし、このプロセス中に、攻撃者のヘルスファクターはチェックされませんでした。この場合、ポジションは清算可能になります（3億1000万eDAI対3億9000万dDAI）、これにより利益を得る機会が生まれます。
7. 攻撃者は別のウォレットアドレス（0xa0b3...）を清算人として使用してポジションを清算しました。清算人（0xa0b3...）は3億1000万eDAIと2億5900万dDAIを受け取りました。
8. 攻撃者は、清算人のポジション（0xa0b3...）で3890万eDAIをバーンし、3890万DAIを引き出しました（ソルベンシーチェックのため、それ以上は引き出せませんでした）。
9. 攻撃者はフラッシュローンを返済しました。

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

まとめ

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

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

このシリーズの他の記事を読む：

• リードイン：2023年のトップ10「素晴らしい」セキュリティインシデント
• ＃1：Flashbots Relayの脆弱性を悪用したMEVボットの収穫
• ＃3：KyberSwapインシデント：非常に微妙な計算による丸め誤差の巧妙な悪用
• ＃4：Curveインシデント：コンパイラエラーが単純なソースコードから誤ったバイトコードを生成
• ＃5：Platypus Finance：幸運のいたずらで3回の攻撃を生き延びる
• ＃6：Hundred Financeインシデント：脆弱なフォークされたプロトコルにおける精度関連の侵害の波を触媒する
• ＃7：ParaSpaceインシデント：業界で最も重大な攻撃を阻止するための時間との戦い
• ＃8：SushiSwapインシデント：不器用な救済の試みが一連の模倣攻撃につながる
• ＃9：MEVボット0xd61492：巧妙な攻撃における捕食者から被食者へ
• ＃10：ThirdWebインシデント：信頼されたモジュールの間の非互換性が脆弱性を露呈