第5回：Platypus Finance：幸運に救われた3度の攻撃からの生還

概要

Platypus Financeは、Avalancheブロックチェーン上のAMMプロトコルです。同プロトコルはこれまでに3回攻撃を受けており、その詳細は以下の通りです。

2023年2月17日、不適切な支払い能力チェック（ソルベンシーチェック）によりハッキングが発生し、合計で約905万ドルの損失を被りました。そのうち、240万ドルがBlockSecの協力により救出されました。約38万トークンがAaveコントラクト内にスタックしていましたが、その後返還されました。
2023年7月12日、ステーブルコイン間の価格乖離を無視したことによりハッキングが発生し、約5万ドルの損失を被りました。
2023年10月12日、価格操作攻撃を受け、約220万ドルの損失を被りました。攻撃者との交渉後、盗まれた資金の90%が返還されました。

同プロジェクトは、これらすべての攻撃から生き残れたことは幸運と言えます。これら3つのエクスプロイト（脆弱性攻撃）を分析すると、綿密な監査やより積極的なセキュリティ対策を講じていれば、論理的な欠陥は回避できたはずです。

最初の攻撃

このセキュリティインシデントを理解するには、いくつかのスマートコントラクトのワークフローを把握する必要があります。大まかなプロセスは以下の通りです。

ユーザーはプールにトークンを預け入れてLP（流動性提供者）となり、LPトークンを受け取ることができます。
LPトークンは「MasterPlatypus」にステーキングして報酬を受け取ることができます。このプロセス中、LPトークンはMasterPlatypusコントラクトへ転送されます。
LPトークンは、資産効率を向上させるために他の資産を借りる際の担保として使用できます。

以下の図は、その相互作用を示しています。

脆弱性分析

この脆弱性は、MasterPlatypusコントラクト内のemergencyWithdrawという関数に存在していました。緊急時には、この関数を使用してMasterPlatypusコントラクトにステーキングされたLPトークンを引き出す必要があります。この関数では、コントラクトはユーザーの「Solvent（支払い能力がある）」状態を確認してから引き出しを許可します。このロジックは、ユーザーに不良債権がないか（つまり、担保を使って負債を支払えるか）をチェックするものです。もし問題なければ、ユーザーはステーキングされたLPトークンを引き出すことができます。

しかし、このロジックには欠陥がありました。ユーザーが「Solvent」であるということは、単に担保で負債を支払えることを意味するに過ぎません。しかし、緊急引き出しによってステーキングされたトークンを引き出した後もユーザーが「Solvent」な状態を維持できるかどうかはチェックされていませんでした。攻撃者はこの欠陥を悪用して資産を借り入れ、さらに（負債を返済することなく）ステーキングされたLPトークンを緊急引き出しすることができました。詳しくはImmunefiブログの詳細分析を参照してください。

攻撃分析

攻撃トランザクションの例を使って、攻撃プロセス全体を確認します。

ステップ 1: AAVEから4,400万USDCをフラッシュローンで借り入れる

ステップ 2: プールに4,400万USDCを預け入れ、LP-USDCを取得する

ステップ 3: LP-USDCをMasterPlatypusへ預け入れる

ステップ 4: LP-USDCを担保としてUSPを借り入れる

ステップ 5: emergencyWithdraw関数を実行して攻撃を開始する

攻撃者はUSPの負債を返済することなくLP-USDCを獲得しました。

ステップ 6: プールからLP-USDCを引き出してUSDCを取得する

ステップ 7: USPを売却して利益を得る

ただし、この利益は攻撃用コントラクト内に残されていました。実際には、攻撃者はスワップの受取先アドレスを自由に設定して利益を得ることが可能でした。

BlockSecによる救出

私たちは、攻撃者が利益を攻撃用コントラクト内に残していることを突き止めました。さらに、そのコントラクト内には資産を引き出すためのロジックが組み込まれていませんでした。しかし、私たちはその攻撃用コントラクト自体に脆弱性があることを発見しました。それを悪用して「ハックバック」を行うことで、コントラクト内に保管された資産の一部を回収できることが分かりました。

具体的には、フラッシュローンのコールバック関数にアクセス制限がなく、誰でもその関数を呼び出せる状態でした。これは、以前多くのMEVボットが攻撃を受けた原因でもあります。

さらに、そのコールバック関数内で、攻撃用コントラクトはPlatypus Financeプールコントラクトに対してUSDCトークンの承認（approve）を行っていました。そして、このプールコントラクトはアップグレード可能でした。

以上の2点を組み合わせることで、私たちは以下の手順で攻撃用コントラクト内のUSDCを救出することができました。

Platypus Financeプールコントラクトをアップグレードし、コントラクト内のUSDCを引き出すロジックを追加する。
攻撃用コントラクトのコールバックを呼び出し、プールコントラクトへUSDCを承認させる。
プールコントラクト（攻撃用コントラクトによって実行される関数）を任意のロジックに置き換え、攻撃用コントラクトからプールへUSDCを転送させる。

240万USDCを救出したトランザクションはこちらです。

その他の2つの攻撃

その他の2つの攻撃の詳細については、以下のリンクを参照してください。

攻撃-II：2023年7月11日、プロトコルがUSDCとUSDTの比率を固定の1:1と仮定していたため、市場変動と乖離し、引き出しロジックに欠陥が生じました。攻撃トランザクションの1つです。他にも複数存在します。
攻撃-III：2023年10月12日、操作されたcash（現金）およびliability（負債）がスワップ価格に影響を与えたことによる攻撃です。[最初の攻撃トランザクション | 2回目の攻撃トランザクション]

まとめ

これら3つの攻撃は、それぞれプロトコルの異なる脆弱性を突いたものでした。他のベンダーによる監査を受けていたにもかかわらず、攻撃者は依然として抜け穴を見つけ出し、プロトコルを攻略しました。幸いにも資産の一部は救出されましたが、常に幸運であるとは限りません。プロトコルとユーザーの資産を守るためには、攻撃監視や自動応答などのより高度なセキュリティ対策を導入すべきです。