2025年2月21日、Safe{Wallet}の開発者マシンがソーシャルエンジニアリングによって侵害され、攻撃者が約15億ドルの損失をBybitにもたらしました。攻撃者はSafe{Wallet}のAWS S3バケットに悪意のあるJavaScriptを注入し、特にBybitのトランザクションを標的にしました。注入されたコードは、署名プロセス中にトランザクションの内容を変更しました。Safe{Wallet}のUIには正当なトランザクションが表示されましたが、署名者のLedgerデバイスに送信された実際のペイロードは、BybitのSafeコントラクトを悪意のある実装にアップグレードし、攻撃者に完全な制御権を与えました。署名され実行されると、攻撃者はコントラクトからすべての資産を流出させました。詳細な技術的内訳は、以前のレポート[1, 2]で入手可能です。
背景
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のCEOであるBen Zhou[2]によると、Safe{Wallet}のUIには正規のトランザクションが表示されましたが、署名者のLedgerデバイスには別のペイロードが送信されました。署名者はUIに表示されたとおりにトランザクションを承認し、攻撃者は悪意のあるペイロードに対して3つの有効な署名を取得しました。
ステップ2：実装の置き換え
攻撃者は、収集した3つの署名とともに悪意のあるトランザクションを送信しました。SafeプロキシはexecTransaction()を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 |
| トランザクション | masterCopyコントラクトを置き換えたTx | 0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882 |
| トランザクション | 15,000 cmETHをドレインしたTx | 0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647 |
| トランザクション | 90,375 stETHをドレインしたTx | 0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0 |
| トランザクション | 8,000 mETHをドレインしたTx | 0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20 |
| トランザクション | 401,346 ETHをドレインしたTx | 0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c |
| トランザクション | 90 USDTをドレインしたTx | 0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9 |
まとめ
このインシデントは、オフチェーンインフラストラクチャの侵害が、いかに壊滅的なオンチェーン損失につながる可能性があるかを示しました。攻撃者はWeb2の侵害、フロントエンドの改ざん、プロキシアップグレードを単一の攻撃経路に結合させ、オンチェーンの脆弱性を一切悪用することなくマルチシグ保護を回避しました。
重要な教訓：
- フロントエンドの整合性は、オンチェーンセキュリティと同等の注意に値します。 攻撃チェーンはフロントエンド提供レイヤーで始まりました。dAppが高額なトランザクションを仲介するにつれて、整合性検証（SRI、コード署名、再現可能なビルド）によるフロントエンドコードの保護と、不正な変更の監視は、基本的な要件となります。
- ハードウェアウォレットの検証は、実際には依然として困難です。 ハードウェアウォレットは実際の署名ペイロードを表示できますが、小さな画面で複雑なマルチシグトランザクションデータを解釈することは、既知のユーザビリティの課題です。オンデバイスでのトランザクション概要の可読性を向上させることは、ウォレットエコシステムにとって未解決の問題です。
- プロキシアップグレードメカニズムは、高レバレッジのターゲットです。 Safeプロキシアーキテクチャは、単一のアップグレード可能なポインターを介してすべてのロジックをルーティングします。1ステップでの実装置き換えを許可するメカニズムは、リスクを集中させます。タイムロック、二次確認ステップ、またはアップグレードの独立したガーディアンを追加することで、単一の侵害されたトランザクションの影響を軽減できます。
参考文献
BlockSecについて
BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号コンプライアンスプロバイダーです。私たちは、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃傍受、インシデント分析、不正資金追跡、およびAML/CFT義務の履行を、プロトコルとプラットフォームのライフサイクル全体で支援する製品とサービスを構築しています。
BlockSecは、著名なカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの複数のゼロデイ攻撃を報告し、多数のハッキングを阻止して2,000万ドル以上を救済し、数十億ドルの暗号通貨を確保しました。
-
公式ウェブサイト：https://blocksec.com/
-
公式Twitterアカウント：https://twitter.com/BlockSecTeam
