ByBitセーフ{ウォレット}ハック

概要

2025年2月21日、暗号資産取引所ByBitのSafe{Wallet}マルチシグウォレットがハッキング被害を受け、約14億6000万ドル相当の資産が流出したことが分かりました。

問題の取引は、Safe{Wallet}のオンチェーンバックエンドを更新するもので、署名者6人のうち3人による正当な署名が含まれており、いずれもByBitのスタッフであったと考えられています。

しかし彼らが気づかないうちに、Safe{Wallet}のウェブUI上で表示されていたトランザクションは、北朝鮮系ハッカーによって差し替えられていました。結果として、この攻撃により、ハッカーはマルチシグウォレットを完全に掌握することに成功したとみられています。

攻撃者は、侵入後わずか13ブロック以内にByBitのウォレットから自身のウォレットへと資産を移動させました。2025年2月時点で、この被害規模は暗号資産市場における史上最大のハッキング事件となりました。

その後、盗まれた資産は、その後オンチェーンミキサーやブリッジを通じて資金洗浄が行われました。

本記事では、このハッキング事案を可能な限り分かりやすく、技術的背景を含めて解説します。
暗号資産取引所、マルチシグウォレット、ハードウェアウォレットの仕組みにすでに詳しい方は、「ハッキングはどのように行われたか」まで読み飛ばしていただいても構いません。

一般的な暗号資産取引所における資産管理の仕組み

暗号資産取引所は、ユーザーに代わって大量のデジタル資産を管理しています。ユーザーが暗号資産を取引所に送金する場合、まずはユーザーごとに割り当てられた入金用アドレスに送られます。

取引所はその後、自動化されたプロセスによって、各ユーザーの入金アドレスから資産をホットウォレットへ集約します。資産自体はホットウォレット上で混在しますが、ユーザーごとの残高はオフチェーンの台帳（データベース）で個別に管理されます。

ホットウォレットの利用により、取引所はユーザーからの暗号資産の出金要求に迅速に対応できます。ホットウォレットからユーザーのウォレットへ、1回のブロックチェーントランザクションで任意の額を送金できるためです。

(図: 暗号交換のホットウォレットへの資産の流れ)

ホットウォレットの仕組みとリスク管理

ホットウォレット自体は、スイープ処理や出金を管理するソフトウェアプロセス内で保護されるべき秘密鍵によって構成されています。もし、このホットウォレットを管理するコンピュータシステムが攻撃者によって侵害された場合、秘密鍵を悪用されてホットウォレット内の全資産が盗まれる可能性があります。ホットウォレットの使用は、出金リクエストに迅速に対応できるという点で、リスクと顧客体験のバランスを取ることになります。

コールドウォレットへの資産移動とセキュリティ対策

ホットウォレット内の残高がある程度以上に増え、取引所が許容するリスクの範囲を超えた場合、暗号資産取引所はその一部をコールドウォレットへ移動させます。

コールドウォレットも通常は秘密鍵のペアによって管理されますが、ホットウォレットとは異なり、自動化されたシステム上でオンラインで保管されることはありません。そのため、コールドウォレットから資産を移動するには、何らかの手動によるプロセスが必要です。

例えば、ある取引所では、コールドウォレットの秘密鍵をハードウェアウォレットに保存し、金庫に保管することがあります。この場合、ホットウォレットを補充するためにコールドウォレットから資産を移動する際は、安全を確保するために、2人の上級スタッフが立ち会い、エアギャップ（ネットワーク接続のない）コンピュータに接続して取引に署名する必要があります。

(図: 暗号交換のホットウォレットとコールドウォレット間の資産の流れ)

今回侵害されたByBitのコールドウォレットは、単一の秘密鍵ではなく、オンチェーンのマルチシグウォレットによって管理されていました。

マルチシグウォレットとは

Ethereum（またはEthereum Virtual Machine、EVM）エコシステムにおいて、マルチシグウォレットは通常、スマートコントラクトとして実装され、スマートコントラクトのコンピュータコードに実装されたルールに従って暗号通貨を保持および配布できます。

たとえば、「N人中M人（例：3人中2人）」の署名が揃わなければ、資産移転が実行されない、といったルールがコードとして定義されます。

署名者とは、ソフトウェアウォレットやハードウェアウォレットで秘密鍵を管理する個人を指します。署名の閾値は、マルチシグコントラクトのデプロイ時に設定されます。

オンチェーンマルチシグウォレットのセキュリティは、攻撃者が資産を盗むために、署名者の秘密鍵の少なくとも署名しきい値（たとえば、2の3）を侵害する必要があるという事実にあります。

オンチェーンマルチシグの安全性は、攻撃者が資産を盗むためには署名閾値（たとえば：3人中2人）を満たす数の秘密鍵を同時に侵害する必要がある点にあります。

(図: マルチシグウォレットの署名者による資産の承認と転送)

最も広く使われているマルチシグウォレットの一つが、GnosisからスピンアウトしたSafeによるSafe{Wallet}です。これは、以前人気があったGnosisマルチシグウォレットの進化版です。Safe{Wallet}はオンチェーンのスマートコントラクトと、それを操作するためのオフチェーンWeb UI（app.safe.global）から構成されています。Safe{Wallet}のオンチェーンスマートコントラクトとオフチェーンウェブUIはどちらもオープンソースであり、つまりソースコードは公開され、誰でも検査、再コンパイル、ホストできます。

署名者としてのハードウェアウォレット

秘密鍵とは、極めて長くランダムな数値であり、理論上推測不可能なものです。
ソフトウェアウォレット（例：MetaMask）は、PCやスマートフォン上で秘密鍵を生成・管理しますが、インターネット接続された汎用デバイスである以上、フィッシングや脆弱性攻撃のリスクを抱えます。

ハードウェアウォレット（例：Ledger、Trezor）は、秘密鍵をデバイス内に安全に保持し、署名前のトランザクションを受け取り、ユーザーの承認後に署名済みトランザクションを返します。USB経由で接続され、耐タンパー設計が施されています。

(図: USBを介してコンピュータに接続されたLedgerハードウェアウォレット)

ソフトウェアとハードウェアウォレットのどちらのウォレットも最終的には操作する人が必要で、取引を確認・承認後、署名する必要があります。

ハッキングはどのように行われたか

攻撃者は、ByBitのマルチシグウォレットの運用全体を包括的に分析していました：

• ByBitのスタッフが管理する秘密鍵

• オフチェーンSafe{Wallet}ウェブUI

• オンチェーンSafe{Wallet}マルチシグスマートコントラクト

(図: ByBitのSafe{Wallet}セットアップのアーキテクチャ)

攻撃者は、GitHub上のSafe{Wallet}のソースコードを改ざんするのではなく、Amazon Web Services (AWS) 上で運用されていた本番Web UIを直接標的としました。

おそらくスピアフィッシング攻撃を通じて、Safeのスタッフの1人の端末に侵入し、AWSの認証情報を取得。その後、正規のWeb UIを攻撃者が改ざんしたUIに差し替えました。

(図: 攻撃者がSafe{Wallet}従業員のAWS資格情報をフィッシングしてSafe{Wallet}ウェブUIに悪用コードをデプロイする)

この改ざんUIは、見た目や操作感は正規のものとほぼ同一でしたが、裏側ではユーザーが署名しようとしたトランザクションを、攻撃者が用意した別のトランザクションに差し替えていました。

Safe{Wallet}オンチェーンマルチシグスマートコントラクトはプロキシパターンを使用しており、つまり実際には2つのスマートコントラクトです。実装スマートコントラクトはコンピュータコードの大部分を含み、Safe{Wallet}チームによって一度だけブロックチェーンにデプロイされます。将来のすべてのSafe{Wallet}スマートコントラクトは、自身の状態を保持するプロキシですが、元の実装スマートコントラクトのロジックに依存します。これにより、アップグレード可能になり、Safe{Wallet}をデプロイするための取引手数料を削減しますが、複雑さと広範な攻撃面が増加します。

Safe{Wallet}のオンチェーン・マルチシグ・スマート・コントラクトはプロキシ・パターンを使用しており、実際には2つのスマートコントラクト（実装コントラクトとプロキシコントラクト）であることを意味します。実装コントラクトはコンピュータコードの大部分を含み、Safe{Wallet}によってブロックチェーンに一度デプロイされます。将来のすべてのSafe{Wallet}スマートコントラクトは、自身の状態を保持するプロキシですが、元の実装スマートコントラクトのロジックに依存します。この設計は、アップグレードが可能になり、Safe{Wallet}をデプロイするための取引手数料を削減することができますが、その代償として攻撃対象領域も広げます。

(図: 攻撃者がByBitのSafe{Wallet}の正当な実装コントラクトを完全な制御を与えた自分たちのものと置き換える)

改ざんUIはByBitのSafe{Wallet}に対してのみ作動するよう設計されており、検知されにくい状態でした。

2025年2月21日、ByBitの署名者6人のうち3人が、ByBit Safe{Wallet}コールドウォレットからByBitのホットウォレットに資産を送金するなど、 日常的な取引と思われる取引を承認しました。しかし実際には、Safe{Wallet}の実装コントラクトを攻撃者のものに差し替えるトランザクションに署名していたのです。

(図: 攻撃者がByBitのSafe{Wallet}の制御を得るまでのエンドツーエンドのビュー)

新しいコントラクトには、攻撃者のみが呼び出せる以下の関数が含まれていました。

• sweepETH：ETHを全額攻撃者指定アドレスへ送金

• sweepERC20：指定したERC20トークンを全額送金

(図: 攻撃者がByBitのSafe{Wallet}を使用してその資産を盗む)

攻撃者は、これらを13ブロック以内に連続実行し、ByBitの全資産を奪取しました。ByBitはSafe{Wallet}へのアクセスを完全に失いました。

ブロックチェーンUXの現実

この事件の背景には、トランザクション署名におけるユーザーエクスペリエンスが依然として改善の余地が多く残っていることです。ByBitの署名者は全員、単一のWeb UI（app.safe.global）を使用しており、これはByBit自身が管理していない単一障害点でした。

(図: app.safe.globalでのSafe{Wallet}ウェブUIでの取引のレビュー)

技術的な観点から見ると、Safe{Wallet}取引は複雑であるため、Ledgerハードウェアウォレットの標準モデルでは署名前に人間可読情報をデコードおよび表示できません。

(図: ラップトップに接続されたLedger Nano S PlusハードウェアウォレットでのSafe{Wallet}取引のレビュー)

結論

国家レベルの攻撃者に対抗することは非常に困難です。ByBitは多くの点で正しい対策を講じており、Safe{Wallet}自体も依然として優れたマルチシグウォレットです。

しかし、トランザクション署名フローにおける単一障害点は、必ず排除または緩和すべきです。

例えば、署名承認はSafe{Wallet}のapp.safe.global公式UIで行いつつ、トランザクション生成にはMultiBaasのような別UIを併用する（Safe{Wallet}取引の構成をサポート）、といった分離も有効です。

署名者は、署名する取引の詳細とハッシュを確認する時間を取ることができます。高額資産を扱う暗号資産取引所にとっては、Safe{Wallet}のWeb UIを自社でホスティングし、24時間体制のセキュリティ監視とエンドポイント保護を行うことも、十分に検討に値します。

なお興味深い点として、攻撃者は攻撃自体の数日前に本番Ethereum上で事前に何度も「本番環境でテスト」を行っていました。ガス代供給元のウォレットを通じてSafe{Wallet}をデプロイし、実際の攻撃を繰り返しシミュレーションしていたと考えられます。今後は、こうした兆候を早期に検知できる監視・検出ツールの進化が求められます。

盗難資産の一部は回収されましたが、本件が業界全体の教訓となり、ウォレットUXとセキュリティの両面がさらに進化していくことが期待されます。