#2 Bybitインシデント：Web2の侵害が史上最大の暗号資産ハックを可能に

2025年2月21日、Safe{Wallet}開発者のマシンがソーシャルエンジニアリングによって侵害され、攻撃者が約15億ドルを盗難しました。攻撃者はSafe{Wallet}のAWS S3バケットに悪意のあるJavaScriptを注入し、特にBybitのトランザクションを標的にしました。注入されたコードは署名プロセス中にトランザクションの内容を変更しました。Safe{Wallet}のUIには正規のトランザクションが表示されましたが、署名者のLedgerデバイスに送信された実際のペイロードはBybitのSafeコントラクトを悪意のある実装にアップグレードし、攻撃者に完全な制御権を与えました。署名・実行された後、攻撃者はコントラクトからすべての資産を流出させました。詳細な技術的分析は、以前のレポート[1]で入手可能です。

背景

Safe{Wallet} (別名 GnosisSafe) は、トランザクションの実行に n 件中最低 n 件の署名を m 人の全署名者から必要とする、n-of-m モデルを使用するマルチシグウォレットインフラストラクチャです。

各Safeウォレットはプロキシコントラクトとしてデプロイされます。このインシデントの中心となる2つのストレージ変数は以下の通りです。

masterCopy (スロット 0): 実装コントラクトのアドレス。このコントラクトには、署名検証やアップグレードメカニズムを含むすべての実行ロジックが含まれています。プロキシは delegatecall を介してすべての呼び出しを masterCopy に委譲します。
threshold (スロット 4): 必要な最低署名数 (n)。BybitのSafeでは、これは 3 でした。

プロキシは delegatecall を使用するため、masterCopy で呼び出された関数はプロキシのストレージコンテキストで実行されます。これは、delegatecall のターゲットがスロット0の masterCopy を直接上書きでき、単一のトランザクションで実装全体を置き換えることができることを意味します。

脆弱性分析

攻撃経路はシステムを3つのレイヤーを通過し、それぞれが攻撃者が利用した構造的な条件を提示しました。

フロントエンド提供モデル。 Safe{Wallet} のフロントエンドJavaScriptはAWS S3バケットから提供されていました。このアーキテクチャでは、バケットへの書き込みアクセス権を持つ人は誰でも、署名者向けのトランザクションを構築するコードを変更できます。サブリソース整合性 (SRI) ハッシュやコード署名などの整合性検証メカニズムは、このリスクを軽減できますが、ほとんどのdAppフロントエンドではまだ標準的なプラクティスではありません。攻撃者は侵害された開発者マシンを通じて書き込みアクセス権を取得し、提供されるJavaScriptを静かに変更しました。

UI表示と署名ペイロードの間のギャップ。 注入されたJavaScriptはSafe{Wallet} UIに正規に見えるトランザクションを表示しましたが、Ledgerハードウェアウォレットには異なるペイロードを送信しました。Ledger画面に表示されるトランザクションの詳細とUIは異なっていたはずですが、ハードウェアウォレット画面で生のトランザクションデータを解釈することは、特に複雑なマルチシグ操作の場合、容易ではありません。このギャップにより、攻撃者は悪意のあるペイロードに対して3つの有効な署名を取得することができました。

プロキシアップグレードモデル。 背景で説明したように、delegatecall はプロキシのストレージコンテキストでターゲットのコードを実行します。Safeプロキシアーキテクチャは、スロット0の単一の masterCopy ポインタを通じてすべての呼び出しをルーティングします。このポインタを上書きすると、プロキシは単一のトランザクションで、署名検証ロジックやアップグレードメカニズムを含む、まったく異なる実装にリダイレクトされます。n-of-mモデルは誰がトランザクションを開始できるかを管理しますが、トランザクションが承認・実行されると、実装自体を変更できます。新しい実装が署名検証を削除すると、それ以降のすべてのトランザクションでマルチシグ保護は実質的に失われます。

攻撃分析

攻撃は、悪意のあるコード注入、実装の置き換え、資産の盗難 の3つのステップで進行しました。

ステップ 1: 悪意のあるコード注入

攻撃者はSafe{Wallet}開発者のマシンを侵害し、フロントエンドを提供するAWS S3バケットに悪意のあるJavaScriptを注入しました。注入されたコードは、BybitのSafeアドレスからのトランザクションを特に標的にしました。BybitのCEOであるBen Zhou[2]によると、Safe{Wallet} UIには正規のトランザクションが表示されましたが、署名者のLedgerデバイスには異なるペイロードが送信されました。署名者はUIに提示された通りにトランザクションを承認し、攻撃者は悪意のあるペイロードに対して3つの有効な署名を得ました。

ステップ 2: 実装の置き換え

攻撃者は、収集された3つの署名とともに悪意のあるトランザクションを提出しました。Safeプロキシは masterCopy に呼び出しを委譲し、execTransaction() は署名を検証してから、攻撃者のコントラクト (0x962214...5c7242) への delegatecall であるトランザクションペイロードを実行しました。この delegatecall はプロキシのストレージコンテキストで実行されるため、攻撃者の transfer() 関数はスロット0の masterCopy の値を悪意のある実装アドレス (0xbDd077...9516) で上書きしました。この時点から、Safeコントラクトへのすべての呼び出しは攻撃者のコードに委譲されるようになりました。

ステップ 3: 資産の盗難

masterCopy が攻撃者の実装を指すようになったため、マルチシグ要件はもはや適用されませんでした。攻撃者はSafeコントラクトに対して直接 SweepERC20() と SweepETH() を呼び出しました。これらの関数は、攻撃者の実装コントラクトで定義されており、署名検証なしで保有資産をすべて転送しました。5回のドレイン・トランザクションが実行され、合計約15億ドルの損失が発生しました。

タイプ	説明	アドレス / ハッシュ
コントラクト	BybitのSafeコントラクト	0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4
コントラクト	元の masterCopy コントラクト	0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F
コントラクト	悪意のある masterCopy コントラクト	0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516
コントラクト	攻撃者のコントラクト (すなわち transfer())	0x96221423681A6d52E184D440a8eFCEbB105C7242
トランザクション	Txが masterCopy コントラクトを置き換え	0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
トランザクション	Txが15,000 cmETHをドレイン	0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647
トランザクション	Txが90,375 stETHをドレイン	0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0
トランザクション	Txが8,000 mETHをドレイン	0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20
トランザクション	Txが401,346 ETHをドレイン	0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c
トランザクション	Txが90 USDTをドレイン	0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9

まとめ

このインシデントは、オフチェーンインフラストラクチャの侵害が、いかに壊滅的なオンチェーン損失につながる可能性があるかを示しました。攻撃者はWeb2の侵害、フロントエンドの操作、プロキシアップグレードを単一の攻撃経路に連鎖させ、オンチェーンの脆弱性を一切悪用することなくマルチシグ保護を回避しました。

主な教訓：

フロントエンドの整合性は、オンチェーンセキュリティと同等の注意を払う価値がある。 攻撃チェーンはフロントエンド提供レイヤーで始まりました。dAppが高額なトランザクションを仲介するようになるにつれて、整合性検証 (SRI、コード署名、再現可能なビルド) を使用してフロントエンドコードを保護し、不正な変更を監視することは、基本的な要件となります。
ハードウェアウォレットの検証は、実際には依然として困難である。 ハードウェアウォレットは実際の署名ペイロードを表示できますが、小さな画面で複雑なマルチシグトランザクションデータを解釈することは、既知のユーザビリティの課題です。デバイス上のトランザクション概要の可読性を向上させることは、ウォレットエコシステムにとって未解決の問題です。
プロキシアップグレードメカニズムは、影響力の大きいターゲットである。 Safeプロキシアーキテクチャは、単一のアップグレード可能なポインタを通じてすべてのロジックをルーティングします。1ステップでの実装置き換えを可能にするメカニズムは、リスクを集中させます。タイムロック、二次確認ステップ、またはアップグレードのための独立したガーディアンを追加することで、単一の侵害されたトランザクションの影響を軽減できます。

参照

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよびクリプトコンプライアンスプロバイダーです。当社は、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃傍受、インシデント分析、不正資金の追跡、およびAML/CFT義務の遵守を、プロトコルとプラットフォームのライフサイクル全体にわたって実行できるように支援する製品とサービスを構築しています。

BlockSecは、著名なカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃を複数報告し、多数のハッキングを阻止して2000万ドル以上を救済し、数十億ドルの暗号資産を保護してきました。