不止于私钥：从钱包、L2 到供应链，如何守护 Web3 的安全边界？

過ぎ去った6月、暗号資産の世界は、複数の領域にまたがる一連のセキュリティインシデントを経験しました。

PeckShieldが発表した最新の月次セキュリティレポートによると、6月には合計40件の重大なハッキング事件が発生し、総損失は7587万ドルに上りました。さらに警戒すべきは、これらの攻撃が特定の攻撃経路に集中しておらず、ウォレットの署名実装の欠陥、L2プロトコルの脆弱性、サードパーティサービスのサプライチェーン攻撃に及び、複数の防御ラインが同じ月のうちに次々と突破されたことです。

Web3のセキュリティリスクが単一の入口からチェーン上の相互作用経路全体に拡大する中、すべてのユーザーは改めてこの疑問に向き合わざるを得ません。私の暗号資産は、一体まだ安全なのでしょうか？

1. 秘密鍵以外の、ウォレットの基盤となる署名実装の重要性

6月にCardanoエコシステムのウォレット「SecondFi」で発生したセキュリティインシデントは、最も直接的な例です。

SecondFiは、Cardanoエコシステムのウォレット「Yoroi」が前身です。6月21日から23日にかけて、攻撃者は一部のSecondFiユーザーのアドレスから約1600万ADA（当時のレートで約240万ドル相当）を約374のウォレットから送金しました。SecondFiはその後、緊急措置により、影響を受ける可能性があった約1億2900万ADAを追加で保護したと発表しました。

このインシデントの最も特異な点は、影響を受けたユーザーが能動的にシードフレーズを攻撃者に渡したわけではないこと、問題はウォレットの基盤となる署名実装にあったことです。セキュリティ機関BlockSecの分析によれば、公開されたトランザクションメッセージから署名のnonceを誤って導出し、標準実装で要求される秘密のnonceプレフィックスが欠落していたとのことです。

これにより、ユーザーが影響を受けるバージョンのウォレットを使用してトランザクションに署名するたびに、チェーン上に公開される署名データから、アドレスの秘密鍵を導出するのに十分な情報が露呈してしまいました。そのため、攻撃者はユーザーのスマートフォンに侵入したり、シードフレーズを入手したりする必要はなく、公開されたオンチェーンデータを分析するだけで、該当するアドレスの署名秘密鍵を復元できた可能性があります。

ユーザーの視点から見ると、ウォレットは正常に動作しており、シードフレーズがポップアップで漏洩したわけでもなく、パスワードが破られたわけでもなく、トランザクションも確かに本人が発行したものです。しかし、暗号学的な観点から見ると、ユーザーのアドレスが影響を受けるバージョンで有効な署名を生成したことがある限り、公開されたトランザクションと署名データは、攻撃者がそのアドレスの署名秘密鍵を導出する助けとなる可能性があります。

結局のところ、ウォレットのセキュリティは、秘密鍵が正しく生成されているか、暗号学的な標準に従って署名が厳密に行われているか、そしてこれらの重要なコードが外部で監査・検証可能かどうかにかかっています。これこそが、コアとなるウォレットコンポーネントをオープンソースに保つことの重要性です。

もちろん、これは特定のウォレットの特定のバージョンにおける実装の欠陥であり、すべての自己管理型ウォレットに共通する普遍的な問題ではありません。例えば、imTokenのTokenCoreは、そのコアコードリポジトリがGitHubで公開されており、鍵管理、アドレス導出、トランザクション署名などの基盤的なウォレット機能をカバーしています。

オープンソースであることがコードに脆弱性が全くないことを保証するわけではなく、ユーザーが警戒を完全に放棄できることを意味するわけでもありませんが、ウォレットの中で最も機密性の高い暗号・署名コンポーネントについて、オープンソースであることは少なくとも重要な前提条件を提供します。すなわち、セキュリティ研究者、開発者、コミュニティがコードを検査し、問題を再現し、継続的にテストできるということであり、検証不可能なブラックボックスを信じるしかないという状況を避けられます。

一般のユーザーにとって、この種のインシデントは、いくつかのより現実的なセキュリティ原則を示しています。

• まず、ウォレットは常に公式ウェブサイトまたは公式アプリストアからダウンロードし、セキュリティアップデートを適時に適用する必要があります。
• 次に、すべての資産を同じ日常的に使用するウォレットに保管すべきではありません。高額で長期保有する資産は、ハードウェアウォレットや独立したコールドウォレットを使用し、頻繁にDAppに接続するホットウォレットから分離して保管することをお勧めします。
• さらに重要なのは、ウォレットの公式が鍵生成や署名実装のレベルで脆弱性を確認した場合、単に元のシードフレーズを別のウォレットにインポートしても、通常は問題は解決しないということです。

なぜなら、同じシードフレーズを他のウォレットにインポートしても、すでに露出したアドレスと秘密鍵は変わらないからです。影響を受けた資産は、脆弱性のあるバージョンで一度も署名したことのない新しいアドレスに移す必要があります。一般ユーザーにとっては、元のアドレスを自分で繰り返しインポートしたり操作したりするよりも、公式の緊急フローに従って新しいウォレットとシードフレーズを生成し、資産を移行する方が、より安全な方法と言えます。

2. L2は「より安いイーサリアム」だけでなく、複雑な信頼の連鎖でもある

ウォレットに加えて、6月の複数のインシデントは、ますます複雑化するL2システムにリスクが及んでいることを示しました。

6月14日と18日、Aztec関連の2つの旧式ロールアップデプロイメントが相次いで攻撃を受け、合計で約435万ドルの損失が発生しました。

特に断っておきますが、攻撃を受けたのは、Aztec Connectなど、すでにレガシー状態となった旧式のデプロイメントであり、現在のAztec Networkメインネット自体が攻撃されたわけではありません。しかし、これらの2つのインシデントが露呈した問題は、ZKロールアップ分野全体にとって非常に示唆に富むものです。

一方のインシデントでは、攻撃者はトランザクション数と実際に処理されたデータとの間の不一致を悪用し、システム内で預金を計上させながら、L1上での対応する残高の差し引き処理を迂回しました。

もう一方のインシデントは、ゼロ知識証明回路における制約の欠如に起因します。システムは形式上有効な証明を検証しましたが、その証明で使用されたプライベートステートツリーが、イーサリアム上で実際の決済に使用される公開ステートルートと完全に一致することを保証していませんでした。そのため、攻撃者は偽造したステートツリーを基に証明を生成し、L1コントラクトから資産を引き出すことができました。

この種の問題は、従来の「コントラクトに特定の脆弱性コードの行が存在するか」という形で概括するのは困難です。ゼロ知識証明は、特定の計算プロセスが所定のルールに従っていることを証明できますが、その前提としてルール自体が正確かつ完全である必要があります。開発者が重要な変数の制約を忘れた場合、証明は数学的に有効であっても、実際の決済状態と一致しない結果を証明することになります。

その後発生したTaikoのセキュリティインシデントは、別の種類のL2信頼連鎖リスクを露呈しました。

6月22日、TaikoのSGXベースの証明検証プロセスが悪用され、約170万ドルの損失が発生しました。BlockSecの分析によると、攻撃者は、公開GitHubリポジトリに以前提出されたSGX enclave署名秘密鍵を使用し、さらにチェーン上の検証コントラクトがDEBUGモードのEnclaveを拒否しなかった欠陥を利用して、悪意のある証明者を正規のインスタンスとして登録しました。

攻撃者はその後、L2の状態証明を偽造し、イーサリアム上のコントラクトに存在しないL2の状態を受け入れさせ、最終的にブリッジ資金から資産を引き出しました。結局のところ、これは、トラステッドエグゼキューション環境の署名に使用される鍵が公開され、リモートアテステーションのルールが実行環境の属性を完全にチェックしていなかったため、「認証済み」の証明が本来持つべき信頼の意味を失ってしまったことに起因します。

同時に、Baseでは6月25日から26日にかけてメインネットのブロック生成が連続して停止しました。Baseは事後の検証で、この2回の停止が同一のブロック構築ロジックの欠陥に起因することを明らかにしました。すなわち、実行に失敗したトランザクションが、以前記録された状態を正しくクリーンアップしなかったため、後続のトランザクションのガス計算が誤って行われ、無効な状態遷移を含むブロックが生成されたということです。他のノードがそのブロックを受け入れられなかったため、ネットワークは最終的に進行を停止しました。Baseは、インシデント中にチェーンの完全性が損なわれることはなく、ユーザーの資金は常に安全であったと述べています。

これは資産の盗難や外部からの攻撃ではなく、ネットワークの可用性と復旧能力に影響を与える技術的な障害でした。しかし、より広義のセキュリティの観点から見れば、可用性自体もL2のセキュリティモデルの一部です。

なぜなら、ユーザーにとって、あるチェーンが安全かどうかは、ハッカーが資産を偽造できるかどうかだけでなく、ブロックが継続的に生成されるか、クロスチェーンブリッジが正常に機能するか、ノードが迅速に復旧できるか、そしてシステムに障害が発生した場合にユーザーが実行可能な退出経路を持っているかどうかにも依存するからです。

したがって、ユーザーはL2を利用する際に、手数料とエアドロップの期待値だけを比較すべきではありません。規模が小さかったり、稼働開始間もなかったり、セキュリティメカニズムが急速に変化しているL2については、実際の使用ニーズを超える多額の資産を長期間保管することは避けるべきです。クロスチェーンを行う前には、公式ブリッジを使用していることを確認し、出金時間、停止メカニズム、緊急時の退出方法を理解しておく必要があります。ネットワークのブロック生成停止、クロスチェーンの異常、公式のセキュリティ警告が発表された場合には、トランザクションを繰り返し送信したり、資産をブリッジし続けたりしないでください。

より安全な方法は、異なる用途と異なるリスクレベルの資産を分散管理することであり、すべての流動性を単一のL2、単一のクロスチェーンブリッジ、または単一の退出メカニズムに賭けることではありません。

3. コントラクトが破られていなくても、サードパーティサービスがユーザーに攻撃をもたらす可能性がある

ウォレットやL2の問題が依然として比較的基盤的な技術コンポーネントで発生しているのに対し、Polymarketのインシデントは、ユーザーに最も近いウェブフロントエンドもまた、資金への入口となり得ることを示しています。

6月25日、Polymarketは、利用していたサードパーティベンダーの1つが侵害され、攻撃者はこれを利用して一部のユーザーがアクセスするPolymarketのフロントエンドに悪意のあるスクリプトを注入したと発表しました。

セキュリティ機関およびオンチェーンアナリストの集計によると、このインシデントにより約11のウォレットから約300万ドルのユーザー資産が失われました。盗まれた資金はその後、Polygonからイーサリアムへクロスチェーンされ、約1893 ETHに交換されました。しかし、Polymarketはその後、影響を受けた依存関係を除去し、影響を受けたユーザーに全額返金すると発表しました。

このインシデントの重要な点は、ユーザーが正しいPolymarketのドメインにアクセスしていた可能性が高く、現在のところPolymarketのコアスマートコントラクトの脆弱性を示すものではなく、問題は主にウェブページが読み込むサードパーティのフロントエンド依存関係にあったということです。

これは鏡でもあります。今日、ほとんどのWeb3アプリケーションは完全にオンチェーンで動作しているわけではありません。ユーザーが見る取引インターフェースなどのウェブページは、依然として従来のインターネットインフラストラクチャとサードパーティのソフトウェアパッケージに大きく依存しています。これらの依存関係のいずれかが攻撃されると、正規のウェブサイトがユーザーに誤った情報を表示したり、入金先アドレスをすり替えたり、ウォレットに悪意のあるトランザクションへの署名を誘導したりする可能性があります。

したがって、「URLが本物であること」は、必ずしも「今読み込まれているすべてのコードが安全であること」を意味するわけではなく、「コントラクトが監査に合格したこと」は、ユーザーとコントラクト間の相互作用経路全体にリスクがないことを意味するわけでもありません。このようなフロントエンドやサプライチェーン攻撃に対して、一般のユーザーがウェブページに読み込まれるすべてのコードを個別に検査することは困難ですが、単一のインタラクションの権限を下げることで潜在的な損失を制限することは可能です。

• 専用のDApp操作用ウォレットを使用する：長期の貯蓄用ウォレットは、様々なDeFi、NFT、予測市場、エアドロップサイトに直接接続しないようにします。日常操作用のウォレットには、当面使用する予定の資金のみを保管し、フロントエンドや承認に問題が発生した場合でも、影響範囲を比較的限定的に抑えることができます。
• 画面上のボタンだけでなく、署名前の実際の操作内容に注意する：ウェブページに「ログイン」「受け取り」「注文確認」と書かれていても、ウォレットに表示される署名が同じ内容であるとは限りません。
• ウェブページに異常が見られる場合、慣習に従って操作を続けない：ページが突然シードフレーズの再インポートや追加プラグインのダウンロードを要求したり、表示されるトランザクション内容がウェブページの