原作者: ムーンビーム
タイムライン
2025年2月21日： Bybitのマルチ署名ウォレットが攻撃を受け、「合法的な」署名取引を通じて15億ドルが流出した。
オンチェーン追跡:資金は匿名アドレスに転送され、混合コインに分割されます。攻撃者は、いくつかの検証ノードと潜在的に接続しています。
事後分析:セキュリティ監査により、攻撃者が Safe フロントエンドのサプライ チェーンの脆弱性を利用して悪意のあるスクリプトを埋め込んだことが判明しました。
なぜ攻撃が起きたのか
ハッカーは悪意のあるフロントエンドコードを使用して、bybit マルチ署名ウォレットの署名者にこれが正当なトランザクション (通常のトークン転送など) であると信じ込ませ、実際に違法なトランザクションに署名するように誘導しました。署名者が他の手段でトランザクションの内容の問題を発見するのを防ぐために、ハッカーはこの攻撃を転送トランザクションに偽造し、bybit 署名者が他の手段でトランザクションのコールデータを確認しないようにしました。 (トランザクションの内容は通常、コールデータと呼ばれます)
簡単に言うと、攻撃方法は次のとおりです。
ハッカーはSafeフロントエンドの開発者権限を取得し、フロントエンドコードを変更し、bybit攻撃を狙った悪意のあるスクリプトを埋め込みました。
Bybit のマルチ署名メンバーが汚染されたウェブページにアクセスし、偽の取引情報を確認しました。
表示されるページ: 「100 ETH をアドレス A に転送」
実際に署名が必要なのは、「コールドウォレットロジックの変更」です。
これは、ディスプレイ画面が交換されたATM機のようなものです。画面には100元が引き出されると表示されていますが、実際の操作は100万元を引き出すことです。
公式アプリ - ユーザーの信頼の盲点
ユーザーの認識では、マルチ署名トランザクション プロセスは非常にシンプルです。トランザクションを確認する → 署名する → チェーンに送信するだけですが、実際にはキーの分離を意味します。
ユーザーが閲覧した取引
実際に署名された取引
公式アプリを使用すると、ユーザーの警戒心が大幅に低下し、この分離層を無視するようになります。公式アプリページがハッキングされた場合、ユーザーの署名は本物になりますが、現時点では何に署名したかはわかりません。
このとき、署名内容の真正性を検証する独立したチャネルがあれば、フロントエンド攻撃によってもたらされるリスクを大幅に排除できます。これがブロックチェーンが提唱していることです。信頼するのではなく、検証しましょう。
「独立チャネル検証」の理論的基礎
まず、Safe コントラクトがどのように機能するかを見てみましょう (これまでのところ、Safe コントラクトはまだ十分に安全です)。
まず、トランザクションの内容のハッシュ値を計算します（トランザクションの「指紋」を生成するのと同様です）
このハッシュ値を秘密鍵で署名する
十分な署名が集まったら、元のトランザクションとこれらの署名をチェーンに送信します。
チェーンは元のテキストに基づいてハッシュ値を再計算し、署名が有効かどうかを検証します。十分な数の有効なトランザクションが収集された場合は実行され、そうでない場合は拒否されます。
ハッシュと署名のセキュリティと偽造困難性は、ブロックチェーンの 2 つの基礎であることに疑いの余地はありません。
そのため、トランザクションがチェーンに送信される前に、元のトランザクションテキストと署名を取得できる独立したチャネルがあれば、「ユーザーが署名したトランザクションが正確に何であるか」と「ユーザーがトランザクションに署名したかどうか」を検証することができます。
そのため、フロントエンドまたはバックエンドが攻撃された場合でも、最悪のシナリオでは間違ったデータが返されます。ただし、「独立チャネル」に間違ったデータがあると、次のような状況が発生します。
トランザクションテキストが間違っており、署名が間違っているため、ユーザーはトランザクションをチェーンに送信することを拒否します
トランザクションテキストが間違っていますが、署名は有効です - ユーザーはトランザクションをチェーンに送信することを拒否します
トランザクションテキストが間違っており、署名が間違っているため、ユーザーはトランザクションをチェーンに送信することを拒否します
最悪のシナリオは、トランザクションがチェーンに送信されないことです。それ以外では、チェーン上での損失は発生しません。したがって、このような「表示攻撃」に対処する最善の方法は、複数のチャネルを通じて検証することです。これは、ブロックチェーンの精神「信頼するのではなく、検証する」にも沿っています。
既存のソリューション
複数のマルチ署名製品が相互に検証する
市場には Safe と互換性のあるマルチ署名製品が数多く存在します。たとえば、Safe 自体は 2 つの独立したフロントエンド ページを展開しています。
https://eternalsafe.vercel.app/welcome/
https://eternalsafe.eth.limo/welcome/
ユーザーがマルチ署名トランザクションに署名した後、そのユーザーまたは後続の署名者は別のマルチ署名製品のページにログインし、元のトランザクションを再度表示します。異なるマルチ署名製品でまったく同じトランザクション コンテンツ分析が表示される場合、ユーザーは「署名するトランザクション コンテンツ」が正しいと確信できます。
しかし、この方法では、さまざまなマルチ署名製品がすべて {Safe} のバックエンドを使用してオフチェーン トランザクションと署名データを保存し、収集した署名データを {Safe} のバックエンドに送信する必要があり、製品間の連携に非常に厳しい要件が課せられます。また、Safe は、一部の非標準的なトランザクションの元のテキスト解析には適していません。複数の Safe フロントエンドが同じ calldata を表示したとしても、それが 0x abcdefsf という意味のない文字列である場合、署名者は意欲を失います。
注: 現在、Safe が提供する 2 つの独立した代替 Web サイトでは、どちらも独自の RPC リンクを提供する必要があります。
独立した安全な取引検証ツール
コミュニティは Safe フロントエンド攻撃に迅速に対応しました。公式の Safe Telegram グループで、誰かが独立した Safe トランザクション解析ツールを提供していたことがわかりました。これはよりシンプルで直接的であるように思われます。
このツールも検証しました。図に示すように、トランザクション共有リンクをセーフページに貼り付けるだけで、セーフバックエンドデータを自動的に読み取り、元のトランザクションのハッシュ値と署名の正確性を独立して検証できます。 つまり、図のコールデータ分析が目的のトランザクションであり、「SafeHash Check」と「Signature Check」の検証に合格したと確信できる場合、「これは送信したいトランザクションです」と「正しく署名されています」と考えることができます。
もちろん、安全のために、 Safe Address、署名を通じて解析された署名者アドレス、インタラクティブコントラクトアドレス、操作タイプ（CallかDelegatecallか）も注意深く確認する必要があります。たとえば、今回bybitに攻撃されたトランザクションは、delegatecallとtransferが同時に出現したトランザクションでした。少し経験のある開発者であれば、このような組み合わせは非常に奇妙であることがわかるでしょう。
読み取れない取引情報が発生した場合:
「デコード」をクリックすると、次のようなトランザクション メソッドの ABI が提供されます。
読み取り可能なトランザクション情報を表示できます。
安全を確保する - 信頼せずに検証する
Bybit のマルチ署名攻撃は、フロントエンドの信頼性がトランザクションのセキュリティと同義ではないことを改めて思い起こさせます。公式アプリを使用している場合でも、取引の内容が改ざんされる可能性があり、署名者は署名内容を検証するための独立した方法を持っている必要があります。
信頼するのではなく、検証する。これが Web3 セキュリティの基本原則です。将来的には、Safe エコシステムとより多くのマルチ署名製品によって独立した署名検証メカニズムが強化され、同様の攻撃が再び発生するのを防ぐことができるようになることが期待されます。
