Web3フロントエンド攻撃：ハッカーにとっての新たなパラダイス

私たちが守ることを忘れている見えないレイヤー

多くの人がWeb3のセキュリティについて語るとき、通常はスマート・コントラクトを思い浮かべる。これは理にかなっています。結局のところ、これらのコードの断片は実際の資産を保持し、プロトコルのロジックを定義し、何十億ドルものユーザーのお金を保護します。何年もの間、セキュリティ・チームは、再侵入の脆弱性、アクセス制御の問題、演算エラー、特定の実行経路でのみ発生する微妙な脆弱性を発見することに、際限のない労力を費やしてきた。しかし、チェーン内で何が起こっているかに執着するあまり、大多数のユーザーが実際に接する最初のもの、つまり、フロントエンドを見失ってきました。

フロントエンドは常に、ピカピカのシェル、つまりユーザーがブロックチェーンと対話するためのインターフェースと見なされてきました。しかしこの「シェル」は、エコシステム全体で最も悪用されるレイヤーのひとつに急速になりつつある。スマートコントラクトが不変で監査可能であるのに対し、フロントエンドは変更可能で中央集権的であり、ブロックチェーンの保証から完全に外れたインフラがサービスを提供する。しかし、ウォレットがユーザーに署名を求める取引ペイロードを構築するのはフロントエンドなのだ。それが怖くないのなら、怖がるべきだ。

インターフェースを信頼するということは、攻撃者を信頼するということです

フロントエンドの本当の危険性は、必ずしも技術的な複雑さではありません。信頼の見当違いです。ほとんどのユーザーは、トランザクションを確認するときに実際に何に署名しているのか知らない。彼らはフロントエンドが見せてくれるものに完全に依存しているのです。

「スワップ」ボタンが承認のトリガーになっているかもしれません。ステーキングインターフェースはデリゲートコールを渡しているかもしれません。ウォレットがデータを人間が読める形式でデコードしない限り（多くのウォレットはまだデコードしていませんが）、ユーザーは自分が何をしているのか確認できません。

このため、フロントエンドへの侵入は、Web3でお金を盗む最も効果的な方法の1つとなっています。攻撃者は契約を破ったり、コア・プロトコルの脆弱性を見つけたりする必要はない。必要なのはフロントエンドを一時的にでも改ざんする方法だけで、ユーザーとブロックチェーンの間に見えないように入り込むことができる。すべてのクリックが、意図を乗っ取る機会となるのだ。

これらの攻撃はどのように行われるのか

これらの攻撃が実行される方法に、特別なものはありません。攻撃者がプロジェクトのドメイン レコードにアクセスし、悪意のあるサーバーに向けることができる、DNSハイジャックのように単純な場合もあります。他のケースでは、攻撃者は感染した依存関係を介してコードを注入し、悪意のあるロジックを置き換え、ウォレットに渡す前にトランザクションデータを変更する。さらに他のケースでは、クラウドダッシュボードまたはCDN設定にアクセスすることでフロントエンドが直接侵害され、攻撃者がリアルタイムでUIスクリプトを変更できるようになっています。

効果は常に同じです。ユーザーはいつものようにアプリにアクセスし、ウォレットに接続し、安全な取引だと思って署名します。通常、信頼できない契約を承認したり、攻撃者が管理するウォレットにトークンを送金したりする。そして、ブロックチェーンは署名された通りに実行されるため、取り消しボタンは存在しない。

これを証明する最近の出来事

私たちはこの痛ましい例をいくつか見てきました。最も有名な例の1つは、2022年のカーブ・ファイナンス事件で、攻撃者がカーブのDNSをコントロールし、偽のフロントエンドをユーザーに提供しました。サイトはまったく同じように見えた。ウォレットのアラートも普通に見えた。しかし、裏ではすべての取引が攻撃者のウォレットにルーティングされていた。わずか数時間で60万ドル近くが失われた。

もう一つの例は、 BadgerDAOです。攻撃者がそのフロントエンドに悪意のあるJavaScriptを注入した後、1億ドル以上を失った。このコードは、特定のユーザー（特にクジラ）のトランザクションのペイロードをサイレントで変更し、それらのユーザーが自分で破壊にクリックスルーできるようにしました。

これらの出来事に共通しているのは、スマートコントラクトがそのまま残っていることです。ロジックは健全で、監査はクリーンですが、フロントエンドが異なるストーリーを語るときには、すべて無関係です。

なぜこの問題はなくならないのか

フロントエンドのセキュリティがWeb3で特に難しいのは、奇妙なグレーゾーンに陥るからです。ゾーンに入るからです。フロントエンドはチェーンの下流にあるため、ほとんどのアップザチェーンのセキュリティツールでは監視できません。特に、セキュリティよりも納期を優先するプロジェクトでは、監査の際に見落とされがちである。また、DNSやクラウドストレージ、JavaScriptのパッケージレジストリといった中央集権的なインフラに大きく依存しており、ブロックチェーンと同レベルの保証を提供するものはない。

さらに悪いことに、フロントエンドの検証ツールはまだ未成熟だ。オンチェーンで検証できるコントラクトのバイトコードとは異なり、フロントエンドのコードは頻繁に変更され、修正されたりハッシュ化されたりすることはほとんどなく、ユーザーが検査できる形でリリースされることもほとんどありません。このため、特にトークンのローンチやエアドロップ、UIのアップグレードなどの敏感な時期には、標的型攻撃には最適な環境となります。

何が変わる必要があるのか

Web3が安全に進化するためには、セキュリティはスマートコントラクトを超えて拡張する必要があります！開発者はフロントエンドをバックエンドと同じ偏執狂的な厳しさで扱わなければなりません。これは、依存関係をロックダウンし、不要なサードパーティのスクリプトを避け、DNS設定を保護し、フロントエンドの監査をすべてのメジャーリリースの一部として扱うことを意味します。

ウォレットプロバイダーも役割を果たすべきです。ユーザーは、自分が何に署名しているのかをより明確に把握する必要があります。これは、デコードの改善、より良い警告、さらにはフロントエンドの真正性チェックなどを意味する。現在、インターフェイスへの信頼が高すぎて、その完全性を検証する努力が十分ではありません。

ユーザーの視点からのアドバイスは、厳しいですが正直です:どんなUIも盲目的に信用してはいけませんです。価値の高いプロトコルとやりとりする場合は、ドメイン名をチェックするだけではありません。ソースコードを確認してください。悪意のある契約を追跡するブラウザ拡張機能を使用する。何かおかしいと感じたら、署名しないこと。

結論

Web3は、信頼なしで実行することだけではありません。それは、信頼の境界全体についてであり、どこから始まり、どのように移り、どこで終わるのかについてです。今現在、フロントエンドはその境界のちょうど真ん中に位置し、ユーザーが見るものと彼らが署名するものとの間のギャップを悪用するのに十分なほど賢い誰にとっても遊び場になっています。

契約は完璧でも、フロントエンドが攻撃されれば結果は同じです。お金は失われ、信頼は壊れ、ユーザーはどうしてうまくいかなかったのかを知りたがる。業界は、フロントエンドを余計なものと考えるのをやめる時だ。ハッカーにとって、フロントエンドは攻撃の最初のターゲットになっているのですから。