Back to Blog

No.8:SushiSwap事件:不器用な救済の試みが招いた一連の模倣攻撃

Code Auditing
February 18, 2024
6 min read

2023年4月9日、SushiSwapは未検証の外部パラメータに起因する脆弱性を突かれ、攻撃の標的となりました。被害総額は約330万ドルにのぼります。

Ethereum上の主要なプロトコルであり、広範なユーザーベースを抱えるSushiSwapのようなトップレベルのプロトコルであっても、コントラクトのアップグレード時に深刻な新たな問題を引き起こす可能性があることを示しています。これは、DeFiコミュニティに対して、セキュリティを常に最優先事項とするよう改めて警告するものです。 さらに、このセキュリティインシデントは、ホワイトハッカーによる救助の試みが引き金となって発生したものであり、コミュニティ内で大きな議論を呼びました。本稿では、2023年のセキュリティインシデント・トップ10の一つとして、この事件の概要を簡潔に紹介します。

背景

SushiSwap

SushiSwapは有名なDEXであり、Uniswapに対して吸血鬼攻撃(Vampire Attack)を仕掛け、大きな成功を収めました。ピーク時には80億ドルのTVL(預かり資産総額)を記録し、現在も約4億ドルの規模を維持しています。

アプロバル(承認)

簡単に説明すると、コントラクトがウォレット内の特定のトークンにアクセスし、送金することを許可する設定のことです。

利便性の観点から、多くのコントラクトがデフォルトで無制限のアプロバルを要求します。多くのユーザーはセキュリティリスクを懸念し、少額のみを各プロトコルに預け入れますが、実際にはプロトコルに対して無制限の資金操作権限を与えてしまっています。もしプロトコルが侵害されれば、そのアカウントで承認済みのすべてのトークンが失われる可能性があります。

脆弱性

未検証の外部パラメータ

RouteProcessor2コントラクトの processRoute() は、ユーザーが呼び出しフロー(routeパラメータ)を完全に制御できるようになっています。 そして uniswapV3SwapCallback() において、safeTransferFrom()from パラメータが、ユーザーが提供した route からデコードされます。 その結果、RouteProcessor2コントラクトを承認していたユーザーは資産を失うこととなりました。

攻撃のプロセス

このインシデントには複数の攻撃トランザクションが関与していますが、ここでは最初のトランザクションを例に挙げます。 トランザクション: 0x43ff7e01423044cfb501b4fe9ef1386725c0ddc117dadd6e6620cb68bdeaf4f9

  1. 攻撃者は、注意深く構築された長い引数 route を指定して、脆弱な RouteProcessor2 コントラクトの processRoute() を呼び出しました。
  2. processRouteInternal() は、ユーザーが提供したルートに基づいて InputStream を作成します。
  3. トランザクションは攻撃者の route に沿って進み、swapUniV3() に到達します。ここで重要なのは、poolstream からデコードされることです。つまり、攻撃者は自身が制御する poolswap() 先として設定(lastCalledPool としてセット)することが可能でした。
  4. これにより、攻撃者がデプロイした悪意のあるコントラクトが呼び出され、そこから RouteProcessor2 の uniswapV3SwapCallback() をコールバックするための悪意のある calldata が渡されます。
  5. uniswapV3SwapCallback() には msg.sender のチェックが必要ですが、lastCalledPool が既に攻撃者のコントラクトに設定されていたため、ハッカーはこのチェックをバイパスできました。さらに重要な点として、safeTransferFrom()from パラメータが、攻撃者が構築した calldata からデコードされました。
  6. 被害者の資産が、攻撃者がデプロイした悪意のあるコントラクトへと転送されます。

物議を醸したホワイトハッカーによる救助

特筆すべき点は、@trust__90 というユーザー名のホワイトハッカーがこの問題を特定し、資金の救出を試みましたが、その試みが災難を招いたことです。

  • プライベートRPCではなく、メンプールを使用してトランザクションをブロードキャストしたこと。
  • リスクにさらされている全資金ではなく、わずか100 Etherのみを救出しようとしたこと。

これにより、MEVボットや他の攻撃者が複数の便乗攻撃(copycat transactions)を実行する機会が生まれ、実質的に資金の大半が流出することとなりました。この事件後、@trust__90 氏は非難を浴び、自身の行動を弁明するに至りました。

BlockSecによる救助

今回の攻撃において、私たちも100 Etherを救出し、被害者である0xsifu氏に返還しました。

現在までに、私たちは20件以上の実際のハッキングを阻止し、1,400万ドル以上の資産を救出してきました。

セキュリティに関する推奨事項

アップグレードは常に監査を受けるべき

DeFiコミュニティに対して改めて強調します。セキュリティは常に最優先事項であるべきです。監査はセキュリティを完全に保証するものではありませんが、監査がないことは安全を全く保証しません。

アプロバル問題への緩和策

2023年はアプロバル攻撃に関する事件が多発しました。この機会に、アプロバル管理の重要性を再確認しましょう。 必要な金額のみを承認する、あるいは利便性を優先する場合でも、必要な量よりわずかに多い金額のみを承認するのが安全な運用です。

BlockSecのMetaSuitesは、便利なアプロバル診断機能を提供しています。さらに、Revoke Cashのようなツールを使用して、定期的に承認状況を確認することも有効です。

監視および自動応答メカニズムの導入

Ethereumは「暗黒の森」であり、DeFiコミュニティに関わる全員が、専門家であっても様々なリスクや課題に直面しています。 2023年、私たちは業界初となる自動応答システムであるPhalcon Securityを立ち上げました。これは単なる攻撃の監視だけでなく、リアルタイムで脅威を積極的に遮断するために設計されています。Phalconの検証済みの能力は、20件以上の実際のハッキングを阻止し、1,400万ドル以上の資産を救出するという実績により、その有効性が証明されています。この革新的なソリューションにより、すべてのステークホルダーが投資を守るための積極的な対策が講じられているという安心感を得ることができます。

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

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit