Bybitによる15億ドルのハッキング:悪質なSafe Walletアップグレード攻撃の徹底分析

このブログでは、攻撃プロセスの包括的な技術的内訳と、デジタル資産保護のための不可欠なセキュリティ教訓を提供します。ブロックチェーンのセキュリティを強化し、同様の攻撃を防ぐための効果的な戦略を学んでください。

Bybitによる15億ドルのハッキング:悪質なSafe Walletアップグレード攻撃の徹底分析

Bybit取引所は2025年2月21日午後14時頃(UTC時間)にハッキングされ、15億に迫る損失が発生した-これまでの暗号史上最大のセキュリティ事件である。これまでのセキュリティ侵害とは異なり、今回の盗難はスマートコントラクトの権限に関する問題ではなく、Bybitが使用するSafe multisig walletの悪意のあるアップグレードが原因でした。攻撃者は複数のSafeウォレットオペレーターを騙してウォレットアップグレード取引に署名させ、Safeウォレットのコントロールに成功しました。一旦コントロールされると、攻撃者は資金を流出させた。

私たちは、この攻撃がBybitを標的とした綿密に計画された作戦であり、攻撃者は最終的な攻撃を開始する2日前に攻撃用コントラクトをオンチェーンで展開し、テストしていたことを突き止めました。このブログポストでは、Safe walletの紹介から始まり、攻撃プロセス全体を分析し、最後にセキュリティに関する推奨事項を提案します。

安全なマルチシグウォレットとは?

セーフ・マルチシグ・ウォレットはスマート・コントラクト・ウォレットの一種であり、取引を承認するために複数の鍵を使用することを主な特徴としています。このウォレットでは、送金やその他の操作を実行する前に、複数のユーザー(通常はあらかじめ指定された鍵の所有者)が取引に署名する必要があり、それによってセキュリティが強化され、単一障害点(single point of failure)や単一の鍵の漏洩を防ぐことができる。

ウォレットが作成されると、複数の鍵が設定される(通常は「n-of-m」モデルを使用)。これは、複数の鍵保有者の間で、取引を実行するために一定数の署名が必要であることを意味する。例えば、"3-of-5 "のマルチシグウォレットは、5人の鍵所有者のうち、少なくとも3人の署名が取引に必要であることを意味する。

Safeの公式ウェブサイトに依存せずにトランザクションを構築する方法もあるが、ユーザー・エクスペリエンス の観点から、ほとんどのユーザーはSafeのウェブサイト経由でトランザクションを構築し、署名することを選ぶ。通常、ユーザーはhttps://app.safe.globalにアクセスして取引を構築する。Safe のウォレットを使って取引を構築し署名する場合、ユーザーはまず取引のシミュレーションを行い、オンチェーンでの潜在的な結果を理解し、それが自分の期待に沿ったものであるかどうかを検証する。結果が予想通りであった場合のみ、オペレータは署名プロセスの完了に進む。

以下はSafeウォレットの取引構築インターフェースのスクリーンショットである。Safe のウェブサイトは現在一時的に利用できないため、以下のスクリーンショットはインターネットから入手したものである:https://milkroad.com/reviews/safe-wallet/)。

実際には、Safeウォレットを利用する場合、以下のようなセキュリティリスクが存在する:

  • Long security chain: ユーザーは、Safe の公式ウェブサイト、アプリ、バックエンドのサービス、自分のコンピュータとブラウザ、そして最後に署名に使用するウォレット(ブラウザの拡張機能かハードウェアのウォレットかを問わない)を信頼しなければなりません。これらのコンポーネントのいずれかが攻撃者によって侵害された場合、オペレーターは正しくない情報を受け取る可能性があります(例えば、インターフェイスには通常の送金取引が表示されているにもかかわらず、アップグレード取引に署名している可能性があります)。

  • ハードウェアウォレットにおけるトランザクション解析の欠如:*** ハードウェアウォレットは一般的に、安全なトランザクショ ンを解析する機能を備えていません。つまり、ユーザーが Safe インターフェースに惑わされた場合、最終的な署名時に相互検証する手段がないため、いわゆる "ブラインド署名" につながる。

攻撃プロセス

最終的な攻撃を開始する前に、攻撃者はすでに攻撃用コントラクトをオンチェーンに展開し、テストしていた。攻撃プロセス全体には複数の異なるアドレスが関与していた。

ステップ1:資金の獲得

攻撃者はまず、攻撃のための初期資金を獲得する必要があった。通常、攻撃者はその痕跡を隠すために、ミキシング・プラットフォーム(例えばトルネード・キャッシュ)を通じて資金を入手する。しかし、今回のケースでは、攻撃者の資金はBinanceから得ています。通常、ミキシングサービスからの資金やアドレスはセキュリティ会社によって厳重に監視されるのに対し、取引所からの資金はそれほど厳重に監視されないため、これは攻撃者の身元を隠すための方法かもしれないと考えています。さらに、資金の出所は取引所ですが、取引所の口座がKYCを受けていないか、そのKYC情報が改ざんされている可能性もあります。

https://metasleuth.io/result/eth/0x3b48fa59c2bBdF8D00D70aC40B2CdA576fC519E3?source=5d9ab32c-e958-4a8d-864f-f1f4e79d0d0c

ステップ2:コントラクトのデプロイとテスト

実際の攻撃を開始する前に、攻撃者は一連のテストを実施した。これらのテストには、Safe ウォレットのデプロイ、攻撃契約のデプロイ、自己デプロイした Safe ウォレットを使用してアップグレード操作を実行し、アップグレードした Safe ウォレットから資金を引き出すことなどが含まれます。さらに、テスト中、攻撃者は限られた範囲のアセット(Bybitで最終的に流出したウォレットのアセットと一致するアセット)のみで実験を行いました。このことは、攻撃者がBybitのSafeウォレットを特に標的にしていたことを示しています。

攻撃者はテスト目的でSafeウォレットを作成しました。テストSafeウォレットのアドレスの1つは 0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55

攻撃者は Safe 契約のアップグレードをテストした。以下のリンクからファルコンエクスプローラーで関連情報を見ることができる:

https://app.blocksec.com/explorer/tx/eth/0x50a51f781567a003662b933fc1224a35d824ba695edce7687473800299c7d1ef

アップグレードをテストした後、攻撃者は引き出しプロセスのテストを行った。アップグレードされた Safe 契約のアドレスから stEth 資産を直接引き出した:

0x509b1eda8e9ffed34287cce11f6de70bff5fef55

https://app.blocksec.com/explorer/tx/eth/0xa284658ddbe5af54bf056ea32147f0842990555510c5b752e3814dbfe0210e0c

ステップ3:ユーザーを欺いてアップグレード取引を構築させ、署名させる

テストを完了した後、攻撃者はユーザーを欺いて Safe 契約のアップグレード取引を構築し、署名させる必要があった。テストは2日前に実施されたため、欺瞞はテスト後2日以内に行われた可能性が高い。これがSafeのサーバーを攻撃したのか、ウォレット運営者のコンピューターを攻撃したのかは、まだ公には確認されていない。

ステップ4:攻撃の開始

攻撃者は十分な数の署名を得ると、取引をオンチェーンに提出し、契約のアップグレードに成功した。アップグレード後、攻撃者は資金を引き出した。悪意のあるアップグレード取引は前回のテスト取引と同一であることが判明した。

https://app.blocksec.com/explorer/tx/eth/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882

教訓と洞察

実際、同様の攻撃は昨年2回発生しており、Radiantインドの取引所WazirX(損失額は2億ドルを超える)からの盗難もその1つで、いずれもSafeウォレットを使用して署名された悪意のある取引によるものだった。今回の事件の違いは、今回署名された取引が契約のアップグレード取引であったことである。したがって、これらのセキュリティ・インシデントから教訓を学び、将来の攻撃を防止することは、大量のデジタル資産を保有する取引所やプロジェクト・チームが取り組むべき課題として残っている。これは、日常業務、内部プロセス管理、機密業務のセキュリティ・プロトコル、攻撃を受けるリスクを減らすための分散化設定を改善することで達成できる。

第二に、ウォレットがトランザクション署名時のセキュリティ・プロセスにどのようにうまく参加できるかという問題は未解決のままである。現在、特にハードウェアウォレットは複雑なトランザクションを解析する能力に欠けている。さらに、ハードウェアウォレットはインターネットに直接接続しないため、ブラインド署名を回避するための取引シミュレーショ ンをどのように実行するか(そしてその結果をユーザーに分かりやすく提示するか)という課題も残っている。

さらに、BlockSec Phalconのようなセキュリティ監視プラットフォームを採用してセーフウォレットを監視し、異常な挙動があれば速やかに検知して対処できるようにするなど、複数のセキュリティ対策を実施する必要がある。実際、PhalconはすでにSafeのウォレットを監視する機能を有しており、将来的にはこのような監視を自動的に設定できるよう、製品のアップグレードを進めていく予定です。今回の事件はSafeウォレットの使用によって引き起こされましたが、"Safe "を恐れる必要はありません。Safeはマルチシグウォレットのデファクトスタンダードであり、その契約上の安全性は長期にわたって証明されています。

最後に、セキュリティ防御は決して一点突破の戦場ではなく、一度きりで効く銀の弾丸も存在しないことを強調しなければなりません。運用とビジネスのセキュリティを確保しながら、業界参加者は資産を守る最後の防御ラインとしてBlockSec Phalconを利用することができます。

Sign up for the latest updates