第2回 Bybit事件：Web2の脆弱性が招いた史上最大の仮想通貨ハッキング

2025年2月21日、ソーシャルエンジニアリングによってSafe{Wallet}開発者のマシンが侵害されたことを受け、Bybitは約15億ドルの資産を失いました。攻撃者は悪意のあるJavaScriptをSafe{Wallet}のAWS S3バケットに注入し、Bybitのトランザクションを標的にしました。注入されたコードは署名プロセス中にトランザクションの内容を改ざんしました。すなわち、Safe{Wallet}のUIには正規のトランザクションが表示されていた一方で、署名者のLedgerデバイスに送信された実際のペイロードは、BybitのSafeコントラクトを悪意のある実装へとアップグレードさせるものであり、これにより攻撃者は完全な制御権を掌握しました。署名および実行が完了すると、攻撃者はコントラクトからすべての資産を流出させました。詳細な技術分析については、以前公開したレポート [1] を参照してください。

背景

Safe{Wallet}（別名：GnosisSafe）は、n-of-mモデルを使用したマルチシグウォレット基盤です。トランザクションを実行するには、計m人の署名者のうち少なくともn人からの署名が必要です。

各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のBen Zhou CEO [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億ドルの損失が発生しました。

関連コントラクトおよびトランザクション

まとめ

本インシデントは、オフチェーンインフラの侵害がいかに壊滅的なオンチェーン損失に繋がるかを示しました。攻撃者はWeb2のセキュリティ侵害、フロントエンドの操作、プロキシのアップグレードをつなぎ合わせ、オンチェーンの脆弱性を一つも利用することなくマルチシグ保護を回避する攻撃経路を構築しました。

重要な教訓：

• フロントエンドの整合性は、オンチェーンのセキュリティと同程度に重要です。 攻撃の連鎖はフロントエンドの配信レイヤーから始まりました。dAppが高価値なトランザクションを仲介するようになるにつれ、整合性検証（SRI、コード署名、再現可能なビルド）によってフロントエンドコードを保護し、不正な変更を監視することが基礎的な要件となります。
• ハードウェアウォレットの検証は依然として実務的に困難です。 ハードウェアウォレットは実際の署名ペイロードを表示できますが、複雑なマルチシグ用トランザクションデータを小さな画面上で解釈するのは、よく知られたユーザービリティの課題です。デバイス上のトランザクション要約の読みやすさを改善することは、ウォレットエコシステムにおける未解決の問題です。
• プロキシのアップグレードメカニズムは攻撃のレバレッジが高いターゲットです。 Safeプロキシのアーキテクチャは、アップグレード可能な単一のポインタを通じてすべてのロジックをルーティングします。一歩で実装を置き換えられるいかなるメカニズムもリスクを集中させます。タイムロック、二次的な確認ステップ、アップグレード用の独立したガーディアン（管理者）を追加することで、単一のトランザクションが侵害された際の影響を軽減できる可能性があります。

参照

1. BlockSec: Bybit $1.5B Hack In-Depth Analysis

2. Bybit CEO Ben Zhou X Broadcast

About BlockSec

BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。当社は、プロトコルやプラットフォームのライフサイクル全体を通じて、コード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃阻止、インシデント分析、不正資金の追跡、そしてAML/CFT義務への対応を支援する製品とサービスを開発しています。

BlockSecは、権威ある会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃を複数回検出、複数のハッキングを阻止して2,000万ドル以上の資金を救出し、数十億ドルの暗号資産を保護してきました。

• 公式ウェブサイト: https://blocksec.com/

• 公式Twitterアカウント: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalcon Compliance