Bybit取引所は、2025年2月21日午後14時(協定世界時)頃にハッキングを受け、約15億ドルに近い損失が発生しました。これは暗号資産の歴史において、現時点で最大のセキュリティインシデントとなります。従来のセキュリティ侵害とは異なり、今回の盗難はスマートコントラクトの権限の問題によって引き起こされたものではなく、Bybitが利用していたSafeマルチシグウォレットに対する悪意あるアップグレードによって発生しました。攻撃者は、Safeウォレットの複数の運営者を騙してウォレットのアップグレードトランザクションに署名させ、それによってSafeウォレットの制御権を奪取することに成功しました。制御権を掌握した攻撃者は、そのまま資金を流出させました。
私たちは、この攻撃がBybitを標的にした綿密に計画された作戦であることを突き止めました。攻撃者は、最終的な襲撃を開始する2日前に、オンチェーン上で攻撃用コントラクトを展開し、テストを行っていました。本ブログ記事では、まずSafeウォレットの紹介から始め、攻撃プロセス全体を分析し、最後にいくつかのセキュリティ上の推奨事項を提供します。
Safeマルチシグウォレットとは
Safeマルチシグウォレットは、トランザクションを承認するために複数の秘密鍵を使用することを主要な機能とするスマートコントラクトウォレットの一種です。このウォレットは、資金移動やその他の操作を実行する前に、複数のユーザー(通常は事前に指定された鍵保持者)がトランザクションに署名することを要求します。これによりセキュリティが強化され、単一障害点(シングルポイント・オブ・フェイラー)や、単一の鍵の漏洩を防ぐことができます。
ウォレット作成時には複数の鍵が設定され(通常「m-of-n」モデルを使用)、複数の鍵保持者のうち、トランザクションの実行に一定数の署名が必要となります。例えば、「3-of-5」マルチシグウォレットとは、5人の鍵保持者のうち、少なくとも3人の署名がなければトランザクションが有効にならないことを意味します。
公式のSafeウェブサイトに依存せずにトランザクションを構築する方法もありますが、ユーザーエクスペリエンスの観点から、ほとんどのユーザーはSafeウェブサイトを通じてトランザクションの構築と署名を行っています。通常、ユーザーはhttps://app.safe.globalにアクセスしてトランザクションを作成します。Safeウォレットを使用してトランザクションを構築・署名する際、ユーザーはまずトランザクションをシミュレートして、オンチェーンで実行された後の潜在的な結果を把握し、それが自身の期待するものと一致するかを確認します。期待通りの結果である場合のみ、運営者は署名プロセスを完了させます。
以下は、Safeウォレットのトランザクション構築インターフェースのスクリーンショットです。現在、Safeのウェブサイトは一時的に利用できないため、以下のスクリーンショットはインターネット(出典: https://milkroad.com/reviews/safe-wallet/)から引用したものです。

実際には、Safeウォレットを使用する際には、以下のセキュリティリスクが存在します。
-
長いセキュリティチェーン: ユーザーは、Safeの公式サイト、アプリ、バックエンドサービス、自身のコンピュータやブラウザ、そして署名に使用するウォレット(ブラウザ拡張機能かハードウェアウォレットかに関わらず)を信頼しなければなりません。これらのコンポーネントのいずれかが攻撃者に侵害された場合、運営者は誤った情報を受け取る可能性があります(例えば、インターフェースには通常の送金トランザクションと表示されているのに、実際にはアップグレードトランザクションに署名しているといった状況)。
-
ハードウェアウォレットにおけるトランザクション解析の欠如: ハードウェアウォレットは、一般的にSafeのトランザクションを解析する能力に欠けています。これは、もしユーザーがSafeのインターフェースで誤認させられた場合、最終的な署名の過程で再確認する手段がなく、いわゆる「ブラインド・サイニング(盲目的署名)」につながることを意味します。
攻撃プロセス
最終的な攻撃を開始する前に、攻撃者は既にオンチェーン上で攻撃用コントラクトを展開し、テストを行っていました。攻撃プロセス全体を通じて、複数の異なるアドレスが関与していました。
ステップ1: 資金の調達
攻撃者はまず、攻撃のための初期資金を確保する必要がありました。通常、攻撃者は足跡を隠すためにミキシングプラットフォーム(例:Tornado Cash)を通じて資金を得ます。しかし、今回のケースでは、攻撃者の資金はBinance(バイナンス)から供給されていました。これは恐らく、身元を隠すための攻撃者の手法であると考えられます。ミキシングサービスからの資金やアドレスは通常、セキュリティ会社によって厳重に監視されていますが、取引所からの資金はそれほど厳しく監視されていないためです。また、取引所経由であっても、その取引所アカウントがKYC(本人確認)を通過していない、あるいはKYC情報が偽造されていた可能性があります。

ステップ2: コントラクトの展開とテスト
実際の攻撃を開始する前、攻撃者は一連のテストを実施しました。テストには、Safeウォレットの展開、攻撃用コントラクトの展開、そして自身で展開したSafeウォレットを使用してアップグレード操作を行い、アップグレードされたSafeウォレットから資金を抽出する手順が含まれていました。さらに、テスト中、攻撃者は限られた資産のみを使用して実験を行っていました。これは、最終的にBybitで流出させられたウォレット内の資産と一致するものであり、攻撃がBybitのSafeウォレットを明確に標的としていたことを示しています。

攻撃者はテスト目的でSafeウォレットを作成しました。テスト用Safeウォレットのアドレスの一つは以下の通りです:
0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55

攻撃者はSafeコントラクトのアップグレードをテストしました。関連する情報は、以下のリンクからPhalcon Explorerで確認できます:

アップグレードのテスト後、攻撃者は出金プロセスのテストに移りました。彼らはアップグレードされたSafeコントラクトから、以下の宛先でstEth資産を直接抽出しました:
0x509b1eda8e9ffed34287cce11f6de70bff5fef55

ステップ3: トランザクション構築・署名をユーザーに誤認させる
テスト完了後、攻撃者はユーザーを騙してSafeコントラクトのアップグレードトランザクションを構築させ、署名させる必要がありました。テストは2日前に実施されていたため、欺瞞行為はその後の2日間のうちに行われたと考えられます。これがSafeのサーバーへの攻撃によるものか、ウォレット運営者のコンピュータへの攻撃によるものかは、現時点では公に確認されていません。
ステップ4: 攻撃の開始

攻撃者は十分な署名数を確保すると、オンチェーンでトランザクションを送信し、コントラクトのアップグレードを正常に実行しました。アップグレード後、攻撃者は資金を抽出しました。この悪意あるアップグレードトランザクションは、先述のテスト時のトランザクションと同一であったことが判明しています。

教訓と考察
実際、同様の攻撃は昨年、Radiantやインドの取引所WazirXからの盗難(2億ドル以上の損失)など、2度発生しており、いずれもSafeウォレットを使用して署名された悪意あるトランザクションが原因でした。今回の事故との違いは、今回署名されたトランザクションが「コントラクトのアップグレード」であったという点です。したがって、これらのセキュリティインシデントから教訓を得て、将来の攻撃を防ぐことは、多額のデジタル資産を保有する取引所やプロジェクトチームにとって取り組むべき課題であり続けます。これは、日々の運用管理、内部プロセス管理、機密性の高い操作に対するセキュリティプロトコル、および攻撃リスクを軽減するための分散設定を改善することによって達成可能です。
第二に、トランザクションへの署名時にウォレットがより良くセキュリティプロセスに参加できるかという問題は、依然として未解決のままです。現状、特にハードウェアウォレットは複雑なトランザクションを解析する能力に欠けています。さらに、ハードウェアウォレットは直接インターネットに接続しないため、ブラインド・サイニングを避けるためにいかにしてトランザクションをシミュレートし(そしてその結果をユーザーに分かりやすく提示するか)ということが課題として残ります。
さらに、BlockSec Phalconのようなセキュリティモニタリングプラットフォームを採用してSafeウォレットを監視し、異常な動作を即座に検知・対処できるようにするなど、多重のセキュリティ対策を実装する必要があります。実際、Phalconは既にSafeウォレットを監視する機能を備えており、私たちは今後、このような監視が自動的に構成されるよう製品をアップグレードし、ユーザーがSafeを使用して多額の資産を管理する際のリスクを回避できるよう支援していきます。今回のインシデントはSafeウォレットの使用によって発生しましたが、「Safe」を恐れる必要はありません。Safeはマルチシグウォレットの事実上の標準であり、そのコントラクトのセキュリティは長期間にわたって証明されてきました。
最後に、強調しておきたいのは、セキュリティ防御は決して単一の突破口を防ぐための戦場ではなく、万能な「魔法の杖」も存在しないということです。運用のセキュリティを確保しながら、業界関係者はBlockSec Phalconを資産を守るための最後の防壁として活用できます。



