Safe のジレンマの詳細な分析: Guard は契約上のバベルを再構築できるか?

著者: フラッシュ＆コング

編集者: リズ

背景

2025年2月21日、暗号通貨業界は史上最悪の資産管理危機に遭遇しました。取引プラットフォームBybitのオンチェーンマルチ署名ウォレットが標的となり、「合法的に署名された」取引を通じて15億ドル近くの資産がひっそりと失われた。その後のオンチェーン分析により、攻撃者は高度なソーシャルエンジニアリング攻撃を通じてマルチ署名権限を取得し、Safeコントラクトのdelegatecall関数を使用して悪意のあるロジックを埋め込み、最終的にマルチ署名検証メカニズムを回避して匿名アドレスに資金を送金したことが判明しました。

この事件は残酷な現実を露呈しました。「マルチ署名」は「絶対的なセキュリティ」を意味するものではありません。Safe マルチ署名ウォレットのようなセキュリティメカニズムであっても、追加の保護対策がなければハッキングされるリスクは依然としてあります。これは、Safe マルチ署名ウォレットに対する最初の攻撃ではありません。昨年、WazirX（2億3000万ドル）とRadiant Capital（5000万ドル）はともに同様の攻撃の被害に遭った。 SlowMist の記事「Bybit から 15 億ドル近くを盗んだハッカーの手法と疑問」で分析されているように、Safe マルチ署名ウォレット攻撃事件では、次のような技術的な相同性が示されました。

署名メカニズムへの過度の依存: すべてのセキュリティ責任を秘密鍵の管理下に置くこと。
動的防御の欠如: トランザクション実行前のリアルタイムのリスクスキャンが不足しています。
粗粒度の権限制御: delegatecall などの高リスク操作に対してホワイトリストメカニズムは確立されていません。

 (Bybit盗難プロセス: Safe v1.1.1を使用)

この一連の出来事の核心的な問題は、Safe 契約自体にあるのではなく、システム全体の統合プロセス、特にフロントエンドの検証リンクにおけるセキュリティリスクにあります。そこで、Safe の追加のセキュリティ対策を通じて、マルチ署名ウォレットの保護機能をどのように強化できるかを考えます。

安全

Safe は、主に高価値資産とデジタル通貨の安全な保管と転送を管理するために使用されるマルチ署名ウォレットです。分散型資産管理のインフラストラクチャとして、複数の当事者による共同検証メカニズムを通じて資金運用のセキュリティを確保し、単一の管理者またはハッカーが単一障害点を悪用して悪意のある操作を実行することを防ぎます。DAO ガバナンス、企業資金管理、分散型資金プールなどのシナリオで広く使用されています。この契約は Safe (旧 Gnosis Safe) チームによって開発され、現在の業界標準のオンチェーン資産管理ソリューションとなっています。この契約では、EIP-712 標準を使用して構造化データ署名を実装し、トランザクションデータのセキュリティと検証可能性を向上させます。

コア目的

資金セキュリティ管理: 契約では、取引を実行する前に複数の事前設定された所有者が共同で取引を確認する必要があるため、単一ポイントのエラーや悪意のある操作を効果的に防止し、資金のセキュリティを確保できます。
トランザクションの実行と管理: 組み込みのマルチ署名検証メカニズムにより、契約は外部転送を実行したり、他の契約を呼び出したり、署名しきい値条件が満たされたときに複雑なビジネスロジックを処理したり、トークンとネイティブ通貨の支払いと手数料の補償をサポートしたりできます。
モジュール拡張: コントラクトはモジュール設計を採用しています。複数の管理モジュール (OwnerManager、ModuleManager、GuardManager、FallbackManager など) を継承して組み合わせることで、機能が柔軟になり、拡張が容易になり、さまざまなアプリケーションシナリオに合わせてカスタマイズされたサポートが提供されます。

機能分析

execTransaction 関数は、複数の署名によって検証されたトランザクションを実行します。

トランザクションの一意のハッシュ値（トランザクションパラメータ、ノンスなどと組み合わせて）を計算します。
すべての署名の有効性を検証し、各署名が正当な所有者または事前に承認されたアドレスからのものであることを確認します。
ターゲットアドレスのビジネスロジックを呼び出し、トランザクションの実行後にイベントを通じて成功または失敗のステータスを記録します。
柔軟なガス料金処理をサポートし、補償金を支払う際の取引コストの正確な計算を保証します。

checkContractSignatures および checkNSignatures 関数は、トランザクションまたはメッセージの署名データを検証します。

EOA アカウント署名、契約署名 (EIP-1271)、事前承認ハッシュを個別に処理します。
署名が所有者の順に並べられ、各署名が有効なアドレスからのものであることを確認して、リプレイ攻撃や署名の改ざんを防止します。

getTransactionHash 関数は、署名の検証とリプレイ攻撃の防止のためにトランザクションハッシュを生成します。

EIP-712 標準を使用して、トランザクションデータに対して構造化ハッシュを実行します。
インラインアセンブリを使用してメモリ操作を最適化し、コンピューティング効率を向上させます。
現在の nonce 値と組み合わせることで、各トランザクションの一意性が保証されます。

handlePayment 関数は、トランザクションの実行中にガス補償の支払いを処理します。

支払金額は実際に消費したガス料金と基本料金に基づいて計算されます。
正確な手数料補償を保証するために、ETH およびその他のトークンでの支払いをサポートします。

onBeforeExecTransaction は、execTransaction 関数が実行される前に呼び出される内部仮想フック関数です。この機能は、トランザクションが実行される前に、Safe コントラクトを継承するサブコントラクトがカスタムロジック処理を実行できるように設計されています。受信したパラメータセットには次のものが含まれます。

to: ターゲットアドレス - トランザクションによって呼び出される契約またはアカウントアドレス
value: Ether値 - トランザクションで送信されたEtherの量
データ: データペイロード - 関数セレクタとパラメータを含む呼び出しデータ
操作: 操作タイプ - CALL か DELEGATECALL かを決定します
safeTxGas: トランザクションガス制限 - トランザクション実行用に予約されたガスの量
baseGas: ベースガス - トランザクションの実行に依存しないガスコスト
gasPrice: ガス価格 - 取引手数料の計算に使用されるガス価格
gasToken: ガストークン - 取引手数料の支払いに使用されるトークンアドレス
返金受信者: 返金受信者 - 取引手数料の補償を受け取るアドレス
署名: 署名コレクション - トランザクションの所有者の署名データ

マルチ署名ウォレット契約は、厳格なセキュリティ設計と柔軟なモジュール構造により、デジタル資産管理のための効率的で安全なソリューションを提供し、トランザクションの初期化から最終実行までの全プロセスのセキュリティ制御を実現し、ブロックチェーンのセキュリティ管理の重要なツールとなっていますが、ほとんどの被害者が署名にハードウェアウォレットに依存していること、一部のハードウェアデバイスは構造化データ署名の表示効果が悪く、ユーザーが短時間でトランザクションデータを正確に識別できなくなる可能性があり、「ブラインド署名」のリスクがあることにも注意する必要があります。この現象に対処するには、ハードウェアとそのデータ表示効果を最適化することに加えて、複数の確認、インテリジェントなプロンプト、強化された署名検証ツールの追加などの対策を検討して、ブラインド署名によって引き起こされるセキュリティリスクをさらに軽減することもできます。

セーフガード

Safe Guard メカニズムは、バージョン 1.3.0 の Safe コントラクトによって導入された重要なセキュリティ機能です。このメカニズムは、標準の n-out-of-m マルチ署名スキームに追加の制限を提供し、トランザクションのセキュリティをさらに強化するように設計されています。 Safe Guard の核となる価値は、トランザクション実行のさまざまな段階でセキュリティチェックを実行できることにあります。

トランザクション前チェック (checkTransaction): Guard メカニズムは、トランザクションが実行される前にすべてのトランザクションパラメータに対してプログラムによるチェックを実行し、トランザクションが事前に設定されたセキュリティルールに準拠していることを確認できます。
CheckAfterExecution: トランザクションが実行された後、Guard は追加のセキュリティ検証を実行し、トランザクション実行後の Safe ウォレットの最終状態が期待どおりであるかどうかを確認します。

アーキテクチャ分析

Safe では、マルチ署名トランザクションは通常、execTransaction 関数を通じて実行されます。 Safe Guard が有効な場合、ユーザーがマルチ署名トランザクションを実行すると、Safe コントラクトは Guard コントラクトの checkTransaction 関数を呼び出してトランザクション前チェックを実行します。マルチ署名トランザクションが完了すると、Safe コントラクトは Guard コントラクトの checkAfterExecution 関数を呼び出してトランザクションの実行結果をチェックします。具体的な実装は以下のとおりです。

Safe コントラクトが Guard メカニズムを通じてマルチ署名トランザクションの事前チェックを実行すると、その checkTransaction 関数は、ターゲットコントラクトアドレス、呼び出しメソッド、実行データ (delegatecall など)、所有者の署名情報、Gas 構成、支払い情報を含む完全なトランザクションコンテキストデータを受け取ります。このメカニズムにより、開発者は、契約ホワイトリスト制御（インタラクティブアドレスの制限）、機能レベルの権限管理（高リスク機能セレクタの無効化）、トランザクション頻度の制限、資本フローに基づく動的ルールなど、多次元のリスク管理戦略を実装できます。ガード戦略を適切に構成することで、攻撃者が非契約レイヤーを使用して攻撃を開始するのを効果的にブロックできます。

最近のセキュリティインシデントを受けて、すべての関係者がマルチ署名ウォレット契約のセキュリティにますます注目しています。KeyStone、OneKey、RigSecなどのハードウェアウォレットプロバイダーは、同様のリスクが再発しないように、Safe契約の解析および保護機能を強化するよう求めています。 Bybit 事件後、多くのプロジェクト関係者が Safe 契約に焦点を合わせ、Guard メカニズムに基づくアップグレードおよび拡張ソリューションを模索し始めました。その中には、Guard メカニズムに基づく革新的なアプリケーションが数多くあり、Safe マルチ署名ウォレットに基づく中間層セキュリティソリューションを構築し、基礎となる資産とユーザー資産の間に追加のセキュリティ保護を提供します。その中核機能は、ホワイトリストコントラクト呼び出し、ホワイトリスト関数操作、ホワイトリスト転送ターゲット、トランザクション頻度、およびその他の権限制御を含む、Safe マルチ署名トランザクションに関係するターゲットコントラクト、呼び出し方法、実行データ、所有者署名情報、支払い情報、ガス情報を checkTransaction 関数に渡すことにより、トランザクションの非常にきめ細かい検査を実装することです。

Safe 自体は Guard 管理とコールバック機能のみを提供している点に注意してください。実際のマルチ署名トランザクションチェックロジックはユーザー自身が実装し、そのセキュリティは Guard 実装の品質に依存します。たとえば、Solv Guardian は、各 Vault に専用の Guardian を構成して許可されたターゲットアドレスと操作権限を指定することにより、この考え方を拡張し、許可された契約の指定、許可された関数操作の定義、ACL 検証要件という 3 つの主要な権限制御要素を実装します。同時に、Vault Guardian が実行を担当し、Governor がガバナンス権限を制御する別のガバナンスメカニズムが採用されており、Guardian に問題が発生した場合でも、ユーザー資産を保護するために適切なタイミングで是正措置を講じることができます。同様の設計コンセプトは、Elytro の SecurityControlModule にも適用されています。このモジュールは、preExecute 関数を通じて主要な操作を傍受し、ホワイトリストメカニズムを使用して、モジュールのインストール、フック設定、バリデータ管理などの高リスク操作を微調整します。これにより、信頼できるコントラクトのみがシステムに追加され、ウォレットの長期的なセキュリティ保護が実現します。

Bybit イベント攻撃チェーンでは、Safe コントラクトが適切に構成された Guard メカニズムを展開すると、攻撃者が execTransaction を通じて開始した悪意のある delegatecall は、事前チェック段階で複数の戦略によって傍受されます。Guard の checkTransaction 関数は、最初に delegatecall 操作タイプを識別し、無効化ルール (操作を通常の呼び出しのみに強制するなど) をトリガーし、次にデータフィールドを解析して、通常とは異なるコントラクトアドレス (0x4622...7242) と高リスクの機能セレクターを検出し、事前設定されたコントラクトホワイトリストと機能ブラックリストの戦略を通じてトランザクションを直接ロールバックし、最終的に「戦略傍受 → ロジックブロッキング」防御システムを形成して、ストレージの改ざんと資金移動パスを完全にブロックします。

 (Safeバージョン≥v1.3.0使用時のSafe Guardモジュール検証操作 https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)

一般的に、Safe はバージョン 1.3.0 以降でのみ Guard 機能を提供します。Guard は非常にきめ細かいマルチ署名トランザクションチェックを提供できますが、ユーザーが Guard 機能を使用するにはハードルが高くなります。ガードチェックロジックは独自に実装する必要があります。ガード実装が粗雑であったり欠陥があったりすると、ユーザーが Safe ウォレットのセキュリティを向上させるのに役立たない可能性があるため、ガード実装のセキュリティ監査が必要です。安全かつ適切な Guard の実装により、Safe ウォレットのセキュリティが大幅に向上することは間違いありません。

結論と展望

Bybit 攻撃は、セキュリティインフラストラクチャをタイムリーに更新することの重要性を浮き彫りにしています。Bybit は Safe コントラクトバージョン v1.1.1 (<1.3.0) を使用していたため、重要なセキュリティ機能である Guard メカニズムを使用できませんでした。 Bybit が Safe コントラクトバージョン 1.3.0 以上にアップグレードし、資金を受け取る唯一のホワイトリストアドレスを指定したり、厳格なコントラクト機能 ACL 検証を実行したりするなど、適切なガードメカニズムを実装していれば、この損失は回避できた可能性があります。これは単なる仮説ではありますが、将来の資産セキュリティ管理にとって重要なアイデアを提供します。

Safe Guard メカニズムは、デジタル資産の金庫に追加されたインテリジェントなセキュリティシステムのようなものです。その有効性は、ルール設計の厳密さと実装の品質に依存します。ますます巧妙化する攻撃手法に直面して、私たちは次のことを行う必要があります。

自動検証: 自動取引検証メカニズムを確立する
動的なポリシー調整: 脅威情報に基づいてセキュリティポリシーをリアルタイムで調整します
多層防御: 複数のセキュリティメカニズムを組み合わせて強力な防御システムを構築
継続的な監査: Guard実装の定期的なセキュリティ監査を実行します。

デジタル資産管理の将来は、スマートコントラクトのセキュリティメカニズムと継続的な攻撃および防御の進化の共進化プロセスになります。すべてのリンクにセキュリティの概念を統合することによってのみ、ハッカーの「槍」とガーディアンの「盾」の間にゲーム内の実際のセキュリティバリアを構築できます。

参考文献

[1] https://github.com/safe-global/safe-smart-account/blob/v1.3.0/CHANGELOG.md

[2] https://docs.safe.global/advanced/smart-account-guards

[3] https://docs.solv.finance/security/solv-guard

[4] https://github.com/safe-global/safe-smart-account/tree/main/contracts/examples/guards

[5] https://github.com/Elytro-eth/soul-wallet-contract/blob/v0.6/contracts/modules/securityControlModule/SecurityControlModule.sol