LedgerからBitgetへ：Cryptoの安全性、見落とされがちな「信頼の盲点」とは？

プライベートキー以外にも、デバイスの流通、サードパーティサービス、内部権限を通じて、ユーザーの資産に至る可能性があります。

執筆：imToken

工場出荷時のチップが正常で、ファームウェアが正規品であり、公式の正規品確認（Genuine Check）を通過したハードウェアウォレットの中の資産が、ハッカーに盗まれる可能性があるとは？

最近のLedgerのセキュリティ事件は、この一見不可能なリスクを露呈しました。

Ledgerのセキュリティチームが後に公開した調査結果によると、攻撃者は問題のデバイス内部に悪意のある回路を追加し、画面に表示されたリカバリーフレーズをキャプチャし、モバイル通信ネットワークを通じて攻撃者に送信することができました。

言い換えれば、工場出荷時のセキュリティチップは攻撃されていなかったものの、リカバリーフレーズは初めて画面に表示された時点で、すでにハッカーの手に渡っていた可能性があります。

さらに、これは最近唯一の注目すべきセキュリティ事件ではありません。

9月以降、Bitgetがサードパーティのセキュリティ製品の脆弱性を利用され、TrezorのメールサービスプロバイダーBrevoが侵入され、MetaMaskの一部インフラにセキュリティ問題が発生するなど、一連の事件が私たちに警告を発しています。Crypto製品がますます複雑になる中で、安全性はもはやプライベートキーを守り、スマートコントラクトの脆弱性を避けるだけでは済まなくなっています。

デバイスの流通、サードパーティサービス、内部権限、ユーザー通信に隠れたリスクも、攻撃者が狙う突破口となる可能性があります。

一、Ledgerが鳴らした「サプライチェーンセキュリティ」の新たな警鐘

まずはLedgerの遭遇を解明しましょう。

通常、ハードウェアウォレットを購入する際に警戒すべきことは、偽物を買うことか、誰かに事前に初期化されたデバイスを受け取ることです。

昔よく見られた手口は、悪意のある仲介者がリカバリーフレーズを生成し、スクラッチカードに印刷してパッケージに戻し、新人ユーザーがルールを理解せずにお金を入れることを賭けるというものでした。

このような詐欺は危険ですが、防御のロジックは非常に明確です------正規のルートを探し、デバイスの状態を確認し、デバイスが自分で新しいリカバリーフレーズを生成するのを見守り、パッケージ内の既存のリカバリーフレーズを使用しないこと。

しかし、今回のLedgerに対する攻撃は、手法が明らかに一段階上がり、ハッカーは筐体内部にマイクロコントローラー、eSIM、セルラー通信機能を持つ電子モジュールを追加しました。ユーザーが初めてウォレットを初期化する際、必ず画面を通じてリカバリーフレーズを読み取り、メモする必要があります。

言い換えれば、埋め込まれた悪意のある回路はリカバリーフレーズの生成プロセスに干渉することはなく、リカバリーフレーズを監視して直接送信するだけです。これが「プライベートキーがセキュリティチップから直接抽出されなかった」という理由であり、ユーザーのウォレットの復元情報が依然として安全であることを意味しないのです。

さらに厄介なのは、デバイスが公式のGenuine Check正規品確認を通過しても、この追加装備されたハードウェアを識別できない可能性があることです。なぜなら、正規品確認は主にセキュリティチップの身元とファームウェアの信頼性を確認するためのものだからです。

したがって、この事件は、日常的に見落とされがちな深刻な「サプライチェーンリスク」を露呈しました：ハードウェアウォレットの安全性は、チップやファームウェアだけでなく、原産地からユーザーの手元に届くまでの全ての納品プロセスにも依存しています。

結局のところ、デバイスは地域のディストリビューター、サードパーティの倉庫、物流、小売業者など、複数の段階を経る可能性があります。デバイスに実際に接触する機会を持つ参加者は、すべて追加評価が必要なリスクポイントとなる可能性があります。

二、TrezorからBitgetへ：攻撃者はどのようにコアセキュリティラインを回避するのか？

Ledgerの問題を理解した上で、最近のBitgetやTrezorが直面したセキュリティ事件を見てみると、根本的なロジックが驚くほど似ていることに気づくでしょう：攻撃者は同様に最も堅固な正面防御を避け、外部の「サードパーティサービス」から侵入してきました。

まずはTrezorを見てみましょう。

9月初旬、一部のTrezorユーザーは「Critical Security Alert: STM32 Entropy Vulnerability」という件名のメールを受け取り、ハードウェアウォレットに深刻なセキュリティ脆弱性があるため、直ちに対策を講じる必要があるとされました。

このようなメールは、ハードウェアウォレットとセキュリティ脆弱性に関わるため、ユーザーを緊張させるのが容易です。誰も自分の資産が損失を被ることを望んでいません。

これが攻撃者がTrezorが使用しているサードパーティのメールマーケティングプラットフォームBrevoを利用した理由であり、悪意のあるコンテンツが正常なメール送信インフラを通じてユーザーのメールボックスに届くことを可能にしました。

Brevoの後続の事故報告によると、攻撃者はそのシングルサインオンシステムの権限境界の欠陥を利用して、他の顧客アカウントへの無許可アクセスを得ました。最終的に138の顧客アカウントが関与し、その一部はフィッシングメールを送信したり、連絡先データをエクスポートするために使用されました。

Trezorはその後、347149のマーケティングメールの連絡先アドレスが事件でエクスポートされたことを確認し、攻撃メールはユーザーに悪意のあるアプリをダウンロードさせ、ウォレットのバックアップ情報を入力させることを試みました。

注意すべきは、この事件にはTrezorのハードウェアウォレットやプライベートキー保護システムが攻撃されたという証拠はありません。攻撃者が最初に取得したのはユーザー情報と公式通信チャネルの濫用能力です。

しかし、メールを受け取った一般ユーザーにとっては、リスクを識別することが逆に難しくなります。なぜなら、メールは馴染みのある公式ドメインから来る可能性があり、正常なメール認証チェックを通過することができるからです。しかし、その内容はすでに攻撃者によってフィッシング情報に置き換えられています。

もしユーザーがこのためにリカバリーフレーズを入力してしまった場合、元々はサードパーティのメールサービスの問題だったものが、実際の資産損失に発展する可能性があります。

次にBitgetを見てみましょう。

9月24日、Bitgetの一部のホットウォレットとウォームウォレットで無許可の資産転出が発生し、最終的に約3.88億ドルが関与していることが確認されました。

Bitgetの公式発表による調査結果によると、攻撃者はサードパーティのセキュリティ製品の脆弱性を利用して、取引所内部の高権限の証明書を取得し、その後ウォレット関連のバックエンドシステムに侵入し、出金指示を偽造し、元のリスク管理チェックを回避して異常な送金を正常な実行プロセスに入れました。

Bitgetは、この事件でプライベートキーの漏洩は発見されておらず、コールドウォレットも影響を受けていないと述べています。これは一見矛盾しているように聞こえます。プライベートキーが盗まれていないのに、なぜお金が転送されるのでしょうか？

実際、理解するのは難しくありません。

取引所のような管理型プラットフォームでは、ユーザーが出金を開始した後、必ずしも人間がプライベートキーを持って一件ずつ署名するわけではなく、アカウント確認、リスク管理審査、取引生成、ウォレット署名など、一連の内部プロセスを経る必要があります。

これは銀行の金庫のようなものです。金庫の鍵が非常に厳重に保管されていても、内部の高権限の身分を偽装できる人がいれば、承認された転送指示を偽造し、金庫内の資金が誤って転送される可能性があります。

Bitgetが暴露したのは、上流の権限と指示の検証が失われた後、リスクがどのように資産実行システムに伝播するかということです。したがって、「プライベートキーが漏洩していない」と「資金が不正に転送されない」は、実際には別のことです。

9月末にMetaMaskが発表したインフラセキュリティ事件は、別の次元の運用リスクを示しています。

当時、MetaMaskは予防措置を講じ、影響を受けた一部のステーキングバリデーターから積極的に退出しました。公式の10月1日の調査更新によれば、MetaMaskウォレットや顧客資金に影響を与える兆候は見つかっていませんが、関連するステーキング業務は顧客の引き出しキーを管理することはありません。

しかし、インフラに問題があったからといって、他の影響が生じないわけではありません。非管理型の解決策は主に資産の制御権の問題を扱いますが、外部インフラの運用リスクを自動的に排除することはできません。

これらの出来事をまとめて見ると、脈絡は非常に明確です：

• Ledgerが暴露したのはハードウェア流通段階の物理的改ざんリスクであり、最終的にはリカバリーフレーズが盗まれる可能性があります。
• Trezor / Brevoが暴露したのはユーザー情報の漏洩と公式通信チャネルの濫用リスクであり、ウォレット自体が攻撃されたわけではありません。
• Bitgetが暴露したのはサードパーティ製品の脆弱性が内部の高権限システムに伝播するリスクであり、資金の実行に直接影響を与える可能性があります。
• MetaMaskは、資産の制御権とサービス運用リスクは同じ概念ではないことを思い出させてくれます。

全体的に見て、今日のCrypto製品はもはや孤立した存在ではありません。

ウォレットは外部のRPCノードを通じてオンチェーンデータを読み取り、集約インターフェースを通じて市場データを取得します。取引所は外部のセキュリティ監視、KYC認証、リスク管理コンポーネントを必要とします。さらに、ノードオペレーター、クラウドプロバイダー、カスタマーサポートチケット、Brevoのようなメールシステムなど、外部サービスが必要です。

これらの外部サービスは製品の運用をより効率的にし、ユーザー体験を改善しますが、一方で新しい外部依存関係を導入するたびに、製品には管理すべき信頼関係が一層増えることになります：

サードパーティが何にアクセスできるか、どれだけの権限を持っているか、そしてそれが一旦失われた場合、リスクが他のコアシステムに伝播するかどうか？

三、製品とユーザーはどう防ぐべきか？

ますます複雑なサードパーティ依存リスクや、相互に関連する依存関係に直面して、製品チームが「外部サービスを一切利用しない」原始的な状態に戻ることを期待するのは明らかに現実的ではなく、市場の規則にも合致しません。

本当にセキュリティアーキテクチャの力量を試すのは、可能な限り各リスクの露出を縮小することです。

例えば、マーケティングメールを送信するだけのSaaSサービスプロバイダーが、なぜ全ユーザーの連絡先データを長期間保持する必要があるのでしょうか？サードパーティのセキュリティ監視ツールが、独立した多重認証なしにコアの生産環境にアクセスできる理由は何でしょうか？特に資金の移動に関わる敏感なアクションについては、内部システム間で「デフォルト信頼」を持つべきではなく、厳格な権限の分離と独立した交差検証を行う必要があります。

これがセキュリティアーキテクチャでよく言われる「最小権限」と「職務分離」です：メールを送信するプラットフォームは、メール送信に必要な権限のみを持つべきであり、セキュリティ監視ツールは資金移動を自由に実行すべきではありません。また、大額の出金は、単に内部システムからの指示に基づいて直接承認されるべきではありません。

Ledger事件は、ハードウェアウォレットメーカーに対して、セキュリティ管理が製品の物理的流通段階にまで及ぶ必要があることをさらに思い出させます。

出荷、倉庫、物流からディストリビューターへの納品まで、どのように追跡可能な管理プロセスを確立し、デバイスの異常な分解や交換を発見し、問題が発生した場合に影響を受けたバッチやユーザーを特定するかは、単なるチャネル管理の仕事として見なされるべきではありません。

なぜなら、プライベートキーを保護するハードウェアデバイスにとって、納品プロセス自体が安全体系の一部だからです。

もちろん、一般ユーザーにとっては、ウォレットのソフトウェアサプライチェーンを監査することも、ハードウェアウォレットの各倉庫や物流段階を一つ一つ調査することもできません。

しかし、これがリスクを受動的に負担するしかないことを意味するわけではありません。少なくとも、日常的な使用の中で習慣として身につけるべきことがいくつかあります。

まず、ハードウェアウォレットの購入過程で不必要な中継をできるだけ減らすこと。

条件が許すなら、ブランドの公式ウェブサイトから注文し、工場または公式倉庫から直接発送することを優先することで、デバイスが工場の管理を離れた後にサードパーティに接触、分解、交換される機会を減らすことができます。

リスク管理の観点から見ると、デバイスに接触する独立した主体が多ければ多いほど、追加の信頼が必要な段階も増えます。また、デバイスを受け取った後は、パッケージや外観の異常を確認し、公式ソフトウェアを使用して検証を完了し、初期化プロセスを厳守する必要があります。

次に、「公式のメッセージ」が信頼できるかどうかを再理解する必要があります。

Trezorの事件はすでに示しています。たとえメールが公式に使用されているサービスプラットフォームを通じて送信されたとしても、その中のリンクや操作要求が必ずしも安全であるとは限りません。

特にウォレットのアップグレード、アカウントの凍結、資産の移動、脆弱性の修正などの敏感な操作に関しては、メッセージ内のリンクを直接クリックするのではなく、自分が保存している公式ウェブサイトのアドレスやすでにインストールされている公式アプリを通じて積極的に確認することが最善です。

imTokenのような非管理型ウォレットにとっても、ユーザーは公式チャネルを認識し、token.imを基準にダウンロードし、異常な情報に遭遇した場合は、優先的にアプリ内の「ヘルプとフィードバック」などの公式入口を通じて確認する必要があります。

相手が公式のカスタマーサポートやセキュリティチームを名乗っていても、または非常に専門的に見える脆弱性の説明を提供していても、リカバリーフレーズやプライベートキーを開示してはいけません。

最後に、異なるセキュリティ事件が自分に与える実際の影響を区別する必要があります。

メールアドレスの漏洩は、将来的により多くのターゲットフィッシングに直面する可能性があることを意味します。疑わしいリンクをクリックした場合、悪意のあるプログラムをダウンロードまたは実行したかどうかを確認する必要があります。すでにリカバリーフレーズを入力した場合は、ウォレットの制御権が漏洩したと見なして対処する必要があります。

疑わしい取引や承認を行った場合は、具体的なオンチェーン操作を考慮し、継続的な契約承認リスクが存在するかどうかを判断する必要があります。

サードパーティサービスの障害やインフラの異常に関しては、公式に開示された影響範囲を参考にし、自分の資産、サービスの可用性、または収益に影響があるかどうかを判断する必要があります。

「ウォレットセキュリティ事件」と聞いて、すぐにプライベートキーが攻撃されたと仮定するべきではなく、ましてや「緊急のセキュリティ通知」によって、むやみに資産を見知らぬアドレスに移動させるべきではありません。

結局のところ、多くの場合、攻撃者が本当に期待しているのは、最も堅固な技術的防線を突破することではなく、ユーザーが恐怖の中で最後の一歩を自ら完了させることなのです。

最後に

過去、Crypto業界で最も強調されていた言葉は「Not your keys, not your coins」でした。

この言葉は依然として重要です。なぜなら、プライベートキーの制御権がユーザーが資産を本当に自分で管理できるかどうかを決定するからです。

しかし、ウォレット、取引所、オンチェーン金融製品が徐々に成熟する中で、私たちもプライベートキーの保護が全体の安全体系の一部に過ぎないことを認識する必要があります。

本当に安全なハードウェアウォレットは、納品プロセスで物理的に改ざんされる可能性がある；公式のメールシステムからの通知も攻撃者に利用される可能性がある；本来安全を強化するためのサードパーティツールが、コア資金システムの入口になる可能性すらあるのです。

これらの事例は、私たちがすべてのウォレットや外部サービスに対する信頼を失うべきだということを意味するわけではありません。むしろ、業界全体に対して、セキュリティを単一の製品内部から、サプライチェーン、権限管理、ユーザー通信、緊急対応の全過程にまで拡張する必要があることを警告しています。

結局、真に成熟したCryptoセキュリティ体系は、プライベートキーが簡単に漏洩しないことを確保するだけでなく、外部の環境で問題が発生した場合でも、全体のメカニズムがリスクを半ばでしっかりと抑え、ユーザーの資産の最後の防衛線を越えないようにする必要があります。