Partnered With:

SlowMist: 金庫のジレンマ、ガードは契約バベルタワーを再建できるか?

この記事を読むのに必要な時間は 29 分

Bybit 攻撃は、セキュリティインフラストラクチャをタイムリーに更新することの重要性を浮き彫りにしています。すべてのリンクにセキュリティの概念を統合することによってのみ、ハッカーの「槍」と守護者の「盾」の間にゲーム内の真のセキュリティバリアを構築できます。

元のタイトル:「SlowMist 分析 | 金庫のジレンマ、警備員は契約バベルを再構築できるか?」》

原著者: flush & kong、SlowMist Technology

背景

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

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

主な目的

資金セキュリティ管理: 契約では、取引を実行する前に複数の事前設定された所有者が共同で取引を確認する必要があるため、単一ポイントのエラーや悪意のある操作を効果的に防止し、資金のセキュリティを確保できます。

トランザクションの実行と管理: 組み込みのマルチ署名検証メカニズムにより、契約は外部転送を実行したり、他の契約を呼び出したり、署名しきい値条件が満たされたときに複雑なビジネスロジックを処理したり、トークンとネイティブ通貨の支払いと手数料の補償をサポートしたりできます。

モジュール拡張: コントラクトはモジュール設計を採用しています。複数の管理モジュール (OwnerManager、ModuleManager、GuardManager、FallbackManager など) を継承して組み合わせることで、機能が柔軟になり、拡張が容易になり、さまざまなアプリケーションシナリオに合わせてカスタマイズされたサポートが提供されます。

機能分析

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

· トランザクションの一意のハッシュ値を計算します (トランザクションパラメータ、nonce などと組み合わせて)。

· すべての署名の有効性を検証して、各署名が正当な所有者または事前承認されたアドレスからのものであることを確認します。

· ターゲットアドレスのビジネスロジックを呼び出し、トランザクションの実行後にイベントを通じて成功または失敗のステータスを記録します。

· 補償金を支払う際にトランザクションコストを正確に計算できるように、柔軟なガス料金処理をサポートします。

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

· EOA アカウント署名、契約署名 (EIP-1271)、および事前承認ハッシュを個別に処理します。

· リプレイ攻撃や署名の改ざんを防ぐために、署名が所有者の順に並べられ、各署名が有効なアドレスからのものであることを確認します。

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

· EIP-712 標準を使用して、トランザクションデータに対して構造化ハッシュを実行します。

· インラインアセンブリを使用して、メモリ操作を最適化し、コンピューティング効率を向上させます。

· 現在の nonce 値と組み合わせて、各トランザクションの一意性を確保します。

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

· 実際に消費されたガス料金と基本料金に基づいて支払い金額を計算します。

· 正確な料金補償を確保するために、ETH やその他のトークンの支払いをサポートします。

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

· to:宛先アドレス - トランザクションによって呼び出されるコントラクトまたはアカウントアドレス

· value:Ether 値 - トランザクションで送信される Ether の量

· data:データペイロード - 関数セレクターとパラメータを含む呼び出しデータ

· operation:操作タイプ - CALL か DELEGATECALL かを決定します

· safeTxGas:トランザクションガス制限 - トランザクション実行用に予約されているガスの量

· baseGas:基本ガス - トランザクション実行に依存しないガスコスト

· gasPrice:ガス価格 - トランザクション手数料の補償を計算するために使用されるガス価格

· gasToken：ガストークン - 取引手数料の支払いに使用されるトークンアドレス

· fundReceiver：返金先 - 取引手数料の補償を受け取るアドレス

· signatures：署名コレクション - 取引における所有者の署名データ

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

セーフガード

セーフコントラクトでは、バージョン 1.3.0 で重要なセキュリティ機能であるセーフガードメカニズムが導入されました。このメカニズムは、標準の 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 機能を使用する際の敷居が高くなります。 Guard チェックロジックは自分で実装する必要があります。粗雑または欠陥のある Guard 実装は、ユーザーの Safe ウォレットのセキュリティの向上に役立たない可能性があるため、Guard 実装のセキュリティ監査が必要です。安全で適切な Guard の実装により、Safe ウォレットのセキュリティが大幅に向上することは間違いありません。

結論と展望

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

Safe Guard メカニズムは、デジタル資産の金庫に追加されたインテリジェントなセキュリティシステムのようなものです。その有効性は、ルール設計の厳密さと実装の品質に依存します。ますます巧妙化する攻撃方法に直面する中で、次のことが必要です。 · 自動検証: 自動トランザクション検証メカニズムを確立する · 動的なポリシー調整: 脅威インテリジェンスに基づいてセキュリティポリシーをリアルタイムで調整する · 多層防御: 複数のセキュリティメカニズムを組み合わせて、強力な防御システムを構築する · 継続的な監査: Guard 実装に対して定期的なセキュリティ監査を実施するデジタル資産管理の未来は、スマートコントラクトのセキュリティメカニズムと継続的な攻撃および防御の進化の共進化プロセスになります。すべてのリンクにセキュリティの概念を統合することによってのみ、ハッカーの「槍」とガーディアンの「盾」の間にゲーム内の実際のセキュリティバリアを構築できます。