トランザクション検証とは？Bybitハッキングに学ぶUI改ざんのリスクと対策

はじめに

2025年2月21日、ドバイを拠点とする暗号資産取引所Bybitのコールドウォレットが攻撃を受けました。コールドウォレットは、秘密鍵をオフライン環境で管理するウォレットです。推定約14億6,000万ドル相当のイーサリアム関連資産が流出しています。elliptic

史上最大規模の暗号資産盗難です。elliptic halborn 米FBIは北朝鮮の関与を確認済みです。elliptic

ブロックチェーン自体やマルチシグ（複数の署名者が承認して初めて実行される取引方式）の設計には、欠陥がありませんでした。Safe（Bybitが使っていたマルチシグウォレットサービス）自身も、公式に侵害を否定しています。bybit 対象は自社のスマートコントラクト（ブロックチェーン上で自動実行される取引ロジックのプログラム）や依存関係です。bybit

承認者には正しい送金先アドレスと、SafeのURLが表示されていました。しかし実際に承認していたのは、ウォレットの権限を攻撃者に渡す操作でした。侵害されたのは、署名者が取引内容を確認するための画面でした。rekt

Bybitハッキングの手口

Bybitは、コールドウォレットの管理にSafeを利用していました。複数の署名者の承認を要件とするマルチシグ方式のスマートコントラクトウォレットサービスで、取引所や機関投資家が大口の資産を扱う際によく使われる仕組みです。

攻撃者はまず、Safeの開発者にソーシャルエンジニアリング（心理的な誘導や偽装によって、本人から認証情報やアクセス権を引き出す攻撃手法）を仕掛けました。halborn Safeのフロントエンド（AWS上でホストされているWebアプリのコード）を書き換える権限を、そこから手に入れています。halborn

そのうえで、Safeのフロントエンドに悪意のあるJavaScriptを仕込んでいます。このコードは、コールドウォレットからホットウォレット（日常的な送金に使う、常時オンラインのウォレット）へのETH送金を標的にしていました。Bybitが普段から繰り返していた定型的な取引パターンを検知するよう作られていたコードです。halborn

該当する取引が実行されようとすると、コードは裏側でその内容を書き換えました。書き換えの対象は、マルチシグのプロキシコントラクト（実体となるロジックを別のコントラクトに委譲する仕組み）です。

そこに対してdelegatecall（呼び出し先のコードを、呼び出し元自身のストレージ上で実行する命令）を発行する処理が仕込まれていました。EVM（Ethereum Virtual Machine、Ethereumでスマートコントラクトを実行する基盤）が用意する命令の一つです。halborn

delegatecallが通れば、ウォレットの制御権そのものが攻撃者の用意したコントラクトに渡ります。

署名者の目には見慣れた定型送金として映りましたが、実態はウォレットの実装を差し替える操作でした。その中には、攻撃者が資産を一括で引き出すための機能が隠されていました。rekt

Bybit共同創業者兼CEOのBen Zhou氏が署名した直後、攻撃者は間を置かずに資産を移動させています。rekt 署名後、悪意のあるJavaScriptはSafeのフロントエンドを元の見た目に戻し、痕跡を薄めました。halborn

攻撃者はその後、AWS上のコードもクリーンな状態に差し替えています。ただし過去のスナップショットを保存するWayback Machineには、改ざん時点の記録が残っていました。halborn

盗まれた資産は分散型取引所（DEX、特定の運営主体を介さずプログラムが取引を仲介する取引所）を介してETHに交換されました。中央管理者がいないため、Bybit側が資金凍結を要請することもできません。elliptic

その後、オンチェーン分析企業Ellipticの分析では約50個のウォレットに分散され、1つあたりの規模はおよそ1万ETHとされています。elliptic 暗号資産セキュリティ専門メディアRektの集計でも、資産は40超のアドレスに分けて送られたことが確認できます。rekt

なぜ「見えているもの」が信頼できないのか

Bybitの署名者たちは、手順を怠っていたわけではありません。見た目のうえでは正しいアドレスと正しいURLが表示された画面を見て、いつも通りに承認しただけです。その画面自体が、ブラウザ側で改ざんされていました。

画面に映る内容は、常にどこかのソフトウェアが生成したものです。生成経路のどこか一箇所でも攻撃者に握られれば、画面はいくらでも書き換えられます。手元の端末や、Webサイト、その先のサーバーなど、経路はいくつも考えられます。利用者は、画面の裏で何が起きているかを見た目だけでは見抜けません。

これはSafeに限った問題ではありません。取引の内容を組み立てて画面に表示するサービスは、同じ構造的なリスクを抱えています。ステーキングのためのトランザクション作成画面も、例外ではありません。フロントエンドが侵害されれば、実際に何を承認しているのかは、画面だけでは分からなくなります。

トランザクション検証のベストプラクティス

こうした改ざんの手口には、いくつかの実務的な対策が有効です。

検証を多重化する

1つのツールや1つの表示だけを根拠にしないことが基本です。トランザクションのデコード（署名前のバイト列を人間が読める取引内容に変換すること）は、複数の独立したツールや自前で検証したライブラリで突き合わせます。

承認前にはTenderly（ブロックチェーン取引のシミュレーションサービス）のようなツールで取引を試し、想定通りの結果になるかを確認します。単純な送金に見えても、実はコントラクトの実装を書き換える操作になっているのです。そうしたケースを実行前に見抜けます。

複数の画面や複数の経路でトランザクションハッシュ（取引内容から一意に導かれる識別子で、内容が1ビットでも変われば別の値になる）を突き合わせる方法も有効です。値が一致すれば内容も一致していると判断でき、一致しなければ改ざんを疑います。

コールドウォレットの代表的な形態が、ハードウェアウォレット（秘密鍵を専用機器内に保管する物理デバイス）です。画面が小さいぶん、この確認では見落としが起きやすくなります。特に注意してください。

承認プロセスに検証結果を組み込む

複数人の承認を要件とする運用であれば、承認の一部を独立した検証ツールの結果と直接ひも付けます。「シミュレーション結果が想定通りであること」を承認の必須条件にすれば、画面の見た目だけを信じて押す承認は減らせるはずです。

運用設計で被害範囲を絞る

コールドウォレットは単純な送金だけに使い、複雑な操作は相対的に資産規模の小さいウォレットから実行します。こうした役割分担は、万一の被害が及ぶ範囲を限定するうえでも有効です。バッチ処理で複数の操作を一つの取引に詰め込むと、自動チェックにも人間の目視にも意図が伝わりにくくなります。複雑な操作はできるだけ小さな取引に分けるべきです。

人間の油断を前提にする

起票（取引を作成する役割）と承認（取引を実行に移す役割）は、別の担当者に分けるのが基本です。日常的な送金とコントラクトのアップグレードのような管理操作は、明確に区別して扱います。重要な取引パラメータは、主系統とは別の経路（Slackや電話など）で、信頼できる同僚に直接確認するのが望ましい方法です。

攻撃者はむしろ、Bybitの事例のように見慣れた定型的な操作を狙います。慣れた作業ほど確認が形式的になりやすいためです。通常と異なるパラメータを自動で検知し、追加の人的確認を求める仕組みを組み込めば、こうした油断を突く攻撃も検知しやすくなります。製造業のポカヨケ（作業者がミスをしても、その場で気づける仕組みにする設計思想）に近い発想です。

提供者側の責任範囲

ステーキング関連のトランザクション作成サービスにも、同じ構造が当てはまります。サービス提供者が秘密鍵を管理せず取引にも署名しない、いわゆるノンカストディアル方式で運営されている場合、取引を実行する当事者が最終的な責任を負います。

ステーキングのダッシュボードでバリデータの追加やアンステークを承認する場合も、画面が実際の署名内容を正しく反映しているとは限りません。提供者側にできるのは、透明性のあるツールやベストプラクティスを提供することまでです。

提供者のツールは便利ですが、それだけを信じ切ってしまうと、Bybitと同じ構造のリスクを抱え込みかねません。

まとめ

複数経路での照合や、承認プロセスへの検証結果の組み込みには、相応の運用コストがかかります。それでも、Bybitが失った14億6,000万ドルと比べれば小さな負担です。

Omakaseは、ステーキングの運用代行事業者（SSP）として、こうしたトランザクション検証の実務動向を継続して確認しています。