出典：SINOHOPE
Bybit盗難の概要
2025年2月21日、仮想通貨取引所BybitのSafeマルチシグネチャウォレットが盗まれ、約15億ドル相当の暗号資産が消失し、仮想通貨史上最大の盗難事件となった。この攻撃では、Safeマルチ署名ウォレットの契約自体には問題がなかったものの、使用プロセスが攻撃を受けました。マルチ署名参加者は署名時に十分なセキュリティ意識と信頼できる独立した検証メカニズムを欠いていたため、ハッカーは署名内容を改ざんし、複数（3）の署名者を完全に欺きました。最終的に、ハッカーは悪意のあるトランザクションを通じてマルチ署名ウォレットの制御権を取得し、攻撃を完了しました。
Bybit による Safe マルチ署名ウォレットへの攻撃に加えて、これまでにも次のような同様の攻撃がいくつか発生しています。
2024年7月18日、インドの取引所WazirXのSafeマルチシグネチャウォレットが攻撃を受け、論理契約が変更され、約2億3000万ドルが盗まれました。
2024年10月16日、貸付プロトコルRadiant Capital Safeのマルチ署名ウォレットが攻撃を受け、約5,000万ドルが盗まれました。
暗号化業界の発展以来、スマートコントラクトによって引き起こされるセキュリティ問題は業界関係者から高い注目を集めてきました。しかし、近年の一連のハッカーによる盗難から判断すると、ウォレットのセキュリティ問題は依然として懸念されています。 Bybitの盗難事件や業界における同様の事件により、ウォレットのセキュリティにおける大きな抜け穴が露呈しました。一見安全そうなマルチ署名ウォレットの仕組みのもとでも、日々の資金/権限管理において、プロセス全体に依然として体系的な問題が残っています。ウォレットのセキュリティは、業界全体で十分な注意を払う必要があります。
ハッカー攻撃プロセスの分析
最新の調査報告書で明らかにされた情報によると、Bybit の攻撃のプロセスと主な疑問点は次のとおりです。
攻撃者は、悪意のある契約 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516 を UTC 2025-02-19 7:15:23 に事前に展開しました。
Safe{Wallet} のシステム公開権限を持つ開発者用コンピューターがハッキングされました。攻撃者は、UTC 2025-02-19 15:29:43 に Safe の AWS S3 バケットに JavaScript コード ファイルをアップロードして変更しました。ファイルには悪意のあるロジックが含まれており、Bybit の Ethereum Safe ウォレットと未知のウォレット (攻撃者がテストと検証に使用したと思われる) のみをターゲットにしていたため、Safe{wallet} フロントエンド インターフェイスのハッキングが完了しました。
UTC 2025-02-21、Bybitの通常のホットおよびコールド資金送金プロセス中に、すべてのSafe{wallet}ユーザーが悪意のあるコードが埋め込まれたSafe{wallet}フロントエンドを見て使用しました。そのため、Bybitマルチ署名参加者は、Safe{Wallet}フロントエンドインターフェースに表示される情報が完全に正常であることを確認しました（ただし、実際の署名コンテンツはフロントエンドに表示されるコンテンツと一致しませんでした）。
署名者は Ledger ハードウェア ウォレットを使用しますが、Ledger ハードウェア ウォレットの署名プロセスはブラインド署名です。署名者は、Ledger で署名するコンテンツが Safe{Wallet} フロントエンド インターフェイスに表示される情報と一致しているかどうかを確認できません。
攻撃者は署名参加者全員を騙し、十分な（3）署名を取得しました。悪意のあるトランザクションは、ERC 20転送を偽造するDelegateCallの形式で悪意のあるコントラクトの機能を呼び出すように構築されました。悪意のある機能は、ウォレットコントラクトの「アップグレード」、つまり、ロジック実装コントラクトを、攻撃者が事前に展開した悪意のあるコントラクトに変更することを完了しました。
悪意のあるトランザクションが完了した後、攻撃者は 2 分以内に通常のスクリプト ファイルを再アップロードし、悪意のあるスクリプト ファイルを削除しました。
その後、攻撃者はマルチ署名ウォレットを完全に制御し、約15億ドル相当の暗号資産を盗み出しました。
このプロセスにおいて、残る疑問には次のようなものがあります。
Safe{wallet} フロントエンドシステムのリリースプロセスとは何ですか?
コードをソース コード リポジトリにコミットせずに、クラウド ストレージでホストされているフロントエンド システムのコード ファイルを 1 人の開発者が変更できるのはなぜですか?
バイビット盗難事件で明らかになった弱点
DeFiシステムのフロントエンドのセキュリティリスク
すべての DeFi アプリケーションでは、理論上は誰でもトランザクションを作成し、オンチェーン スマート コントラクトと直接やり取りできますが、現実には、実際の環境ではほとんどのユーザーにとってこれは不可能なタスクです。したがって、すべての DeFi アプリケーションでは、トランザクションの構築や EIP-712 データの署名にフロントエンドシステムが必須となります。同じスマート コントラクト セットが複数の独立したフロントエンド システムでサポートされていない場合、DeFi アプリケーションのフロントエンド システムが単一の主要なリスク源になります。
操作機器の安全上の危険
Bybit事件の直接的な原因は、Safe{Wallet}プロジェクトからシステム公開権限を持つ開発者のコンピューターデバイスがハッキングされたことであり、従来のセキュリティリスクが永遠に存在することを浮き彫りにしました。 Web3 実践者はオンチェーン資金のセキュリティに直接関与する可能性があるため、従来のネットワーク セキュリティ リスクの防止に最高レベルの注意を払う必要があります。 Web3 分野のすべての技術システムと管理リンクは、金融グレードのセキュリティ レベルを参照して検討および実装する必要があります。
安全なマルチ署名契約のセキュリティの弱点
Safe マルチ署名コントラクトは、execTransaction という 1 つの実行エントリのみを提供します。execTransaction は、Call と DelegateCall という 2 つの実行メソッドを提供します。バッチ トランザクションの場合、Safe コントラクト自体はバッチ実行エントリを直接開くのではなく、MultiSendCallOnly コントラクトなどの他のコントラクトを使用してバッチ トランザクションのロジックを実装します。したがって、一括して契約を構築する必要がある場合は、外部契約の DelegateCall の呼び出しトランザクションを構築して、トランザクションの分割と外部契約の個別実行ロジックを実行する必要があります。
通常のビジネス シナリオでは、DelegateCall メソッドは、インタラクションのターゲット アドレス (送信先アドレス) が MultiSendCallOnly 契約である場合にのみ実行する必要があります。
ただし、Safe のこのメカニズムは、Safe を日常的に使用する際に潜在的な安全上のリスクを残します。ほとんどのユーザーは、使用中に独立して完全な検証を行うのに十分な知識、スキル、認識を欠いている可能性があります。
実際、Safe Wallet に対する巨額の金銭を狙った 3 件の既知の攻撃はすべてこのメカニズムを悪用していました。攻撃者は DelegateCall 実行メソッドをうまく利用して、Safe Wallet に悪意のあるロジックを実行させました。
ワジールX:
https://etherscan.io/tx/0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d
バイビット:
https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
一部のハードウェアウォレットにはブラインド署名のリスクがある
署名されたトランザクション データをデコードするウォレット アプリケーションの機能は、非常に重要な機能です。Web3 オンチェーン インタラクションに重点を置く一部のウォレットには、すでに特定のトランザクション解析機能があり、継続的に改善されています。ただし、ハードウェア ウォレット (このインシデントで Bybit が使用した Ledger ハードウェア ウォレットなど) には現在、そのような機能がありません。ユーザーは盲目的に署名することしかできず、トランザクションの内容を検証する最後のチャンスを失ってしまいます。
ウォレットのトランザクション解析機能には、大量のタイムリーに更新されるデータのサポート (EVM 互換チェーン フィールドの ABI データベースなど) と、一般的な特定のトランザクション タイプを識別し、特定のカスタマイズされた処理を実行する必要性が必要です。これにより、ウォレットの継続的な更新と反復に対する要求が高まります。
マルチ署名参加者間の独立検証の意識を強化する必要がある
単一署名のシングルポイントリスクと秘密鍵漏洩リスクを回避するために、業界では一般的にマルチ署名ウォレットの使用に移行しています。ただし、使用中にマルチシグ参加者が独立した検証に対する認識、能力、必要なツールを欠いており、代わりにトランザクション開始者のセキュリティと信頼性に主に依存する場合、マルチシグウォレットは本来の機能を失ってしまいます。
SINOHOPEのセキュリティ対策
暗号資産のセキュリティ原則
暗号資産の安全性を確保するためには、セキュリティ意識、セキュリティ技術システム、セキュリティ規制の面で総合的かつ立体的なメカニズムを形成する必要があります。 SINOHOPEは、Bybit事件や同様の事件を受けて、ユーザーが基本的なセキュリティ意識を高める必要があることを特に強調しました。
1. 従来のセキュリティ強化の提案
Web3 組織および担当者は、金融グレードのセキュリティを認識し、従来のセキュリティ リスクを防ぐための実用的な対策を講じる必要があります。
専用デバイスを有効にする:
重要な目的には専用の独立した機器を装備し、日常のオフィス機器との混在を避け、必要な場合以外は起動しないでください。
Linux や最新バージョンの macOS/Windows などのより安全なオペレーティング システムを使用し、不要なサービスとポートを削除します。
オフィスネットワーク機器のセキュリティを強化し、従来のセキュリティ対策を実施します。
端末/オフィス環境のセキュリティは、Lazurus などの APT 攻撃組織から保護するための最優先事項です。端末に EDR ツールがインストールされていることを確認してください (従来のウイルス対策ソフトウェアでは、APT への対処に効果が限られています)。
内部システムのアクセス制御と保護の深さを強化します。機密性の高い内部システムや重要な操作へのアクセスには、内部コード ベース管理やクラウド プラットフォーム管理などの追加の二次認証が必要です。
CDN/AWS などのクラウド サービス プロバイダーの権限管理を適切に行います。コンソールにログインする際は、人員、権限、アクセス時間の範囲を最小限に抑えるようにしてください。デフォルトでは、ルート アカウントと管理者権限アカウントは使用されません。 IAM ロールの使用を優先し、ak/sk アクセス メソッドの使用は避けてください。有効にする必要がある場合は、キー ローテーションを有効にし、アクセス アドレスのホワイトリストを追加します。
パブリック SDK、クライアント インストール パッケージ、CDN (CloudFront-S 3/CloudFlare-R 2 など) によってキャッシュされた静的リソースなど、パブリックにアクセス可能なリソースの整合性チェックを実行し、定期的なチェックのユーザー シナリオをシミュレートします。
各コードリリースで追加の整合性チェックを実行し、オンライン環境のコードが内部のセキュリティレビュー済みコードと一致していることを確認します。
社内・仕入先システムへのアクセス監視を強化し、他拠点や異常時へのアクセスを速やかに検知し、速やかに調査・確認を行う。
主要な権限を持つ担当者に対して、端末デバイスのセキュリティ機能を完全にカバーします。
（II）ウォレット使用の基本原則
分離原理
熱と冷気の隔離
目的の分離: 資金ウォレットと許可ウォレットは厳密に分離されています。資金調達ウォレットは資金を保管し、送金機能のみを持つ必要があります。Safe などのマルチ署名契約を単純な資金調達ウォレットとして使用する代わりに、専用の資金調達ウォレット ソリューションを使用することを強くお勧めします。マルチ署名契約ウォレットは、ウォレットがオンチェーン契約の管理権限を持つ必要がある場合、DeFi アプリケーションに参加する場合、およびその他のシナリオでのみ検討する必要があります。
機器の分離: 資産に不可欠な機器、分離された機器、日常のコンピューター/仕事用コンピューターは使用せず、必要な場合以外は有効にしない
単一点リスクを回避し、複数の当事者による独立した検証を実施する
独立したリスク管理システム
ホワイトリスト制御
独立したリスク管理レビュー
取引シミュレーションの実行
十分な能力の原則と権限の最小化の原則：リスクの露出を可能な限り減らす
コールドウォレットソリューションの推奨事項
1. MPCテクノロジーに基づくエンタープライズレベルの資金管理ソリューション
資金の管理のみが必要なウォレットの場合、「任意のロジックを実行する」潜在的なリスクがあるスマート コントラクトのマルチ署名ウォレット ソリューションを使用することは、最善の選択ではない可能性があります。
資金管理のみが必要な「コールドウォレット」（DeFiインタラクションに参加する必要がない）の場合、Xinhuo TechnologyのSINOHOPEエンタープライズレベルMPCウォレットソリューション、つまりSINOHOPEセルフカストディプラットフォームをSafeマルチ署名の代替として使用できます。 SINOHOPE は、特定のニーズを持つ機関のクライアント向けに、MPC ソリューションのプライベート展開の実装をサポートする技術ソリューションも提供できます。
MPC-TSS（Muti-Party Computation-Threshold Signature Scheme）テクノロジーは、秘密鍵のシャーディングと共同署名の分散管理をサポートし、秘密鍵の単一点リスクを解決し、安全な自己管理を実現します。
EVM 互換チェーンでのみ利用可能なマルチ署名スマート コントラクト ソリューションと比較すると、MPC ベースのソリューションは、Safe マルチ署名ソリューションのすべての利点を完全に備えているだけでなく、マルチチェーンの汎用性、独立した監査のより優れた実装、「任意のロジックを実行する」潜在的なリスクの排除など、Safe マルチ署名にはないいくつかの利点も備えています。 SINOHOPE MPC ソリューションの特徴は次のようにまとめられます。
集中型ホスティングよりも自律的
資産を独立して管理し、「横領」や「逃亡」の心配がない
単一ポイントリスクを回避するためにTNマルチ署名をサポート
企業のマルチレベル資産管理をサポート
分散型ウォレットよりも安全で機能的
秘密鍵シャーディングのマルチパーティ管理により、従来の秘密鍵管理のリスクが排除されます。
「目に見えない」秘密鍵や記憶フレーズを保持する必要がない
マルチレベルの災害復旧ソリューションとマルチシナリオのシャード復旧メカニズム
ハードウェアウォレットよりも便利で使いやすい
シャーディングはインターネットに接続でき、「0」のストレージの難しさ
Web2製品フォーム、すぐにマスター
契約ウォレットよりも安価で多用途
アドレス作成にガス消費がなく、手数料も安い
ほとんどの主流ブロックチェーンをサポート
プライバシーを保護するためのチェーンマルチ署名
シンプルな資金管理のニーズに対して、ビジネスレビューとリスク管理をより適切に実装し、「恣意的なロジックを実行する」潜在的なリスクを排除できます。
これを、取引を確認するときのみオンラインになる専用のモバイル デバイスを使用するという強化された対策と組み合わせることで、セキュリティをさらに強化できます。
MPC-TSS の技術力と利点は、オンライン アカウント システム、多要素認証システム、インターネット上で長年蓄積されてきた生体認証技術と組み合わせることで、ユーザーが秘密鍵のニーモニックを排除し、盗難、紛失、悪意のある行為を防止し、ユーザーが資産を確実に管理できるように効果的に役立ちます。
2. SINOHOPEのSafe{wallet}マルチ署名向け署名検証ソリューション
Web3分野では、コールドウォレットなどの単純な資金管理ニーズに加えて、オンチェーンの権限管理やDeFiインタラクションへの参加などのニーズもあります。このようなニーズに対して、Safe{wallet}に代表されるオンチェーンマルチ署名ソリューションは、間違いなく現時点でも最良のソリューションの1つです。しかし、Bybit の事件では、Safe{Wallet} マルチ署名の使用における複数の弱点も明らかになり、その中でもフロントエンド システムへの単独依存とハードウェア ウォレットでのブラインド署名の隠れた危険性が特に顕著でした。
Safe{Wallet}の使用における潜在的なリスクに対応するため、SINOHOPEはSafe{Wallet}マルチ署名用の署名検証ソリューションを開始しました。独立した署名コンテンツ検証メカニズムを導入し、企業レベルの承認プロセスとリスク管理メカニズムを組み合わせることで、ハードウェアウォレット+ Safe{Wallet}マルチ署名ソリューションのセキュリティ上の欠点を補います。
SINOHOPE MPC ウォレットの独立検証スキームには以下が含まれます。
Safe{Wallet} の署名リクエストでは、独立したリスク管理検証戦略が有効になっています。業界の ABI データベースと Safe コントラクトのターゲット処理に基づいて、署名するコンテンツとその実行意図が独立して解析され、リスクの高い操作 (予期しない DelegateCall 呼び出しなど) に対してタイムリーに早期警告を発行できます。
統合されたトランザクションシミュレーション実行機能により、署名前にトランザクション実行をシミュレートし、操作意図を識別し、操作意図と潜在的なリスクをユーザーフレンドリーな方法で表示して、ブラインド署名のリスクを回避できます。
エンタープライズレベルの承認プロセスを統合し、MPC ウォレット アカウントによって管理されるマルチ署名ウォレットの特別な承認プロセスとリスク管理戦略を策定して、より柔軟で豊富な資金管理ニーズを満たすことができます。
SINOHOPE MPCウォレットをSafe{Wallet}の部分署名メンバーとして使用することで、現在のSafe{Wallet}マルチ署名ウォレットアプリケーションシステムに独立したセキュリティ強化レイヤーを導入することができ、既存の使用計画を補完する便利な機能となります。 SINOHOPE MPC ウォレット自体は自己管理型ウォレットであり、単一の署名権限は SINOHOPE MPC ウォレットのみが保持できるため、顧客は常に Safe ウォレット/資産に対する最終的な管理権を維持します。
SINOHOPE MPCウォレットの署名検証サービスは、Safe{Wallet}の使用プロセスにおける顧客のセキュリティを大幅に向上させ、ユーザーの独立検証スキル要件を効果的に削減し、ユーザーの独立検証負担を軽減します。これにより、機関顧客は企業のニーズをより密接に統合し、複数の署名参加者（上司、ビジネス、財務、セキュリティなど）の役割をより合理的に割り当てることができ、各参加者が独立した監査と検証を実施するための条件を備えていることが保証され、Safe{Wallet}の目的である「単一ポイントのリスクを防ぎ、複数当事者の検証を実現する」が真に実現されます。
結論: Web3 業界ウォレット セキュリティ イニシアチブ
業界全体で統一されたセキュリティ標準を推進し、Web3の信頼できるエコシステムを構築する
Web3 エコシステムが急速に発展するにつれて、ウォレットはユーザー資産管理の中核でありエントリ ポイントとなるため、ウォレットのセキュリティは極めて重要になります。しかし、現在、業界には統一されたセキュリティ標準がないため、ユーザーは異なるウォレットを使用する際に異なるセキュリティリスクに直面しています。
SINOHOPEイニシアチブ:
業界共通のセキュリティ標準を確立 - 業界セキュリティフォーラムを構築し、業界の研究開発、日常管理、ユーザーの使用など、あらゆる側面をカバーするセキュリティのベストプラクティス仕様を共同で構築し、エコロジカルなアプリケーション/セキュリティコンポーネントの相互運用性標準を構築し、業界の長期的なセキュリティを共同で確保します。
ユーザーの安全意識の向上 - 標準化された安全教育を通じて、業界ユーザーのリスク認識と予防能力を向上させます。
エコシステム間の連携を強化 - セキュリティの脅威に共同で対応するために、業界間での情報共有と緊急対応メカニズムを促進します。
セキュリティは、暗号業界の安定的かつ長期的な発展の基盤です。開発者、ウォレットサービスプロバイダー、監査機関、コミュニティが協力してセキュリティの標準化を推進し、ユーザーにとってより安全な取引環境を構築するよう呼びかけます。
