Google ドキュメントにログインしたり、ブラウザでのキー入力を読み取ったり、通信中のリクエストを傍受したり、常時実行され、黙って更新され、さらにはパスワードを盗み出すほどの能力を持つようなアプリケーションを、まさかインストールしたりはしないでしょう？ 実は、ブラウザ拡張機能はこれとほぼ同等のことを行えるのです。そして、それらは単一のコンピュータや企業にとどまらず、より広範囲にわたる脆弱性を生み出しています。
数ヶ月前、Vercelの従業員が、比較的新しく人気のある「Context.ai」というブラウザ拡張機能をインストールしました。これは「AIオフィススイート」を提供するものでした。アプリに接続するにはOAuthの許可が必要だったため、権限画面でGoogleアカウントへのアクセスを許可するよう求められた際、その従業員は「許可」をクリックしました。この拡張機能はVercelが社内で承認したものではありませんでしたが、ブロックされていたわけでもありませんでした。
2月末、Context.aiの従業員が、情報窃取型マルウェアを含むRobloxのチートツールをダウンロードしてインストールした。この「 」と呼ばれるマルウェアがVercelのOAuthトークンを発見し、それがVercelに対する大規模な攻撃の侵入経路となった。攻撃者はVercelをハッキングする必要はなかった。必要なのは、Vercelの従業員がすでにアクセス権限を付与していたAIスタートアップをハッキングすることだけだった。
あるマルウェアが、シャドウブラウザ拡張機能から収集したデータを盗み出しました。この手口、どこか聞き覚えがありませんか？ これはサプライチェーン攻撃のように見えますが、まさにその通りです。
Vercelのセキュリティ侵害がいかにしてサプライチェーン攻撃であったか
ブラウザ拡張機能は、企業セキュリティにおいて最も過小評価されている攻撃経路の一つとなっており、Vercelへの侵害はその最新の事例に過ぎません。この攻撃は、セキュリティ業界がオープンソース依存関係においてよく知るパターンに従ったもので、サードパーティのコードが暗黙のうちに信頼された後、上流で侵害されるというものです。このパターンには固有の名称があり、それに基づいて構築された一連のツールも存在しますが、業界全体として、それらをブラウザ拡張機能に適用できていません。
サプライチェーン攻撃には、いくつかの主要な要素があります。実際の権限を持って実行されるサードパーティのコード、暗黙の信頼、そして最初の侵害源と直接的な関係を持たない被害者が必要です。 Vercelの侵害事件は、これら3つの要素をすべて満たしています。Context.aiは実在する製品であり、実際に業務を遂行していました。また、Google Workspaceに対して付与されていたOAuthアクセス権は、その目的を考えると妥当な要求でした（ただし、信頼と権限の付与がやや過剰だったという見方もあります）。つまり、Context.aiのAWSバックエンドには、非常に高い権限を持つOAuthトークンが保管されており、従業員のデバイスが1台侵害されるだけで、攻撃者の手に渡る危険性があったのです。
Context.aiの従業員が自身のマシンに情報窃取型マルウェアをインストールした際、たった一人の従業員が、以前は正当な拡張機能だと信じていたものに対して抱いていた信頼が、同社の内部環境への侵入経路となってしまった。本来の侵害はどこか別の場所で発生したものだったが、被害を受けたのはVercelだった。これこそが、いわゆるサプライチェーン攻撃である。
Vercelの事例は、サプライチェーン攻撃の一環としてブラウザ拡張機能を利用したマルウェア攻撃としては初めてのものではありません。例えば、2024年後半に発生したCyberhavenへの侵害事件も、同様のシナリオを標的型に展開したもので、攻撃者は特に開発者向けの拡張機能を狙っていました。 CyberhavenのChrome拡張機能は、開発者アカウントに対するフィッシング攻撃を通じて侵害され、誰にも気づかれる前に悪意のある更新がユーザーに配信されました。この悪意のあるバージョンは約24時間にわたり稼働していました。
サイレントアップデート方式は、より大きな危険をもたらす
セキュリティの観点から見ると、拡張機能の更新モデルは少々問題があります。OSのソフトウェアとは異なり、ブラウザ拡張機能はユーザーに通知することなく自動的に更新されます。今日ブラウザ上で実行されているコードは、インストール時に同意したアプリとは異なる可能性があります。更新を促すメッセージが表示される他のソフトウェアの更新（「後で更新」をクリックし続けて数ヶ月が経つような場合でも）とは異なり、拡張機能の更新についてはユーザーから同意を得るための通知は一切ありません。 通知が表示されるのは、拡張機能が追加の権限を要求する場合のみです。先月までは安全だった拡張機能でも、今夜悪意のある更新を受け取り、それをインストールしているすべてのユーザーが自動的にその更新を受け取ってしまう可能性があります。もしその拡張機能がすでに多くの権限を持っていたら、大変なことになります。開発マシン上でソフトウェア依存関係 黙って自動依存関係 想像してみてください。
うまくいっていないこと
企業はこれまで、許可する拡張機能のリストを作成して（それ以外はすべてブロックする）か、あるいはその逆のブロックリストを作成するかのいずれかの方法を試みてきました。しかし、どちらの場合も、リストを適切に管理し、最新の状態に保つことには明らかな障壁があります。拡張機能の開発者の約半数は身元が不明であり、また、多くの開発者は1つの拡張機能しか公開していないため、評判に基づいて拡張機能を管理する方法は、ごく一部の拡張機能にしか有効ではありません。そもそも、大手企業でさえ、完全にクリーンとは言えない拡張機能を公開しているのが実情です。 正確かつ最新の社内リストを手作業で維持することは不可能です。
SCA 、パッケージにおけるこの問題を解決するために考案されました。オープンソースの依存関係 に対して機能するメカニズムは、パッケージの動作内容（名前や公称の機能ではなく）に基づいて依存関係 。 コードスキャンや脅威インテリジェンスを一切行わず、パッケージ名だけでnpmパッケージを承認することは、依存関係におけるサプライチェーンセキュリティとは見なされません。しかし、「npmパッケージ」を「Chrome拡張機能」に置き換えてみると、それがここ数年のブラウザセキュリティに対するアプローチとほぼ同じであることがわかります。
ブラウザ拡張機能を、他のサプライチェーン上の攻撃経路と同様に扱おう
マーケットプレイスにはその実態が反映されていませんが、インストール時の信頼性だけでは不十分です。ここでは、パッケージのセキュリティと同様の考え方を適用する必要があります。組織は、すべてのマシンに何がインストールされているかを把握し、一見クリーンに見える拡張機能が後に悪意のあるものへと変化しても、見逃さないよう継続的な監視を行う必要があります。
多くのセキュリティチームは、依存関係に関するサプライチェーンの脅威モデルを明確に説明できます。彼らは、メンテナンス担当者のアカウントが侵害されることや、前四半期までは安全だったパッケージが今日では攻撃の媒介となり得ることを理解しています（実際、最近では注目を集めるサプライチェーン攻撃が数多く発生しています）。しかし、業界全体として、その知見をブラウザ拡張機能に対して同程度に適用できてはいません。
依存関係 有効な手法は、ブラウザ拡張機能にも依存関係 。ソフトウェアの依存関係スキャンが機能するのは、その基盤となる脅威インテリジェンスが常に最新の状態に保たれているためです。つまり、前四半期に誰かが作成したリストではなく、新たな脅威が発見されるたびに更新されるデータベースと照合しているからです。ブラウザ拡張機能のインストール前ブロックも、同様の仕組みで機能する必要があります。サプライチェーン攻撃は急速に変化するため、先月正確だった許可リストでは、先週その拡張機能が所有者を変更したり、悪意のある更新を受けたりした事実を把握できないからです。
また、組織としては、開発者の各デバイスに何がインストールされているかを把握しておく必要があります。パッケージマネージャーは、リポジトリ内にロックファイルや依存関係リストといった記録を残しますが、ブラウザ拡張機能にはそのような記録がありません。これを把握する唯一の方法は、組織内のすべてのデバイスを積極的に監査することです。存在すら知らない脅威には対応できませんが、多くの企業では、これを行うためのツールが整備されていません。
最後に、エンジニアから人事部門に至るまで、組織内の全員がブラウザ拡張機能のリスクを認識しておく必要があります。依存関係の脆弱性については多くの報道がなされていますが、ブラウザ自体のセキュリティについてはそれほど注目されていません。一般的に、ブラウザのセキュリティが万全ではないことは知られていても、認証情報の窃取といった重大な脆弱性については、十分に認識されていないことがよくあります。私たちはチームや組織に対して、リスクやベストプラクティスについて教育を行わなければなりません（例えば、この記事を共有するなど）。
Vercel型サプライチェーン攻撃の再発を防ぐ
Vercelへの侵入事件は、ブラウザ拡張機能がキルチェーンの一環となる最後の事例にはならないだろう。攻撃対象領域の価値は高すぎる上、多くの組織が依存している対策は限定的すぎて、状況が自然に改善されることはない。ブラウザ拡張機能のセキュリティを、すでに現実となっているサプライチェーンの問題として捉えるべきだ。できれば、次の攻撃が起きる前（事後ではなく）に、その対応を講じることを望む。
Aikido 、サプライチェーンセキュリティモデルを適用して開発者のデバイスを保護します。悪意のある拡張機能はインストール前にブロックされ、既知の悪意のあるものについては照合が行われます Aikido Intelによる検証を経て、デバイスに接触する前にブロックされます。 Aikido これを支えるAikido Intelフィードは、1日あたり最大10万件の悪意のあるパッケージを特定しており、intel.aikido.devで公開されており、無料で閲覧可能です。
Aikido 詳細をご覧になるか、Aikido フィードを閲覧して、オープンソース・エコシステム全体で検出された情報をリアルタイムで確認してください。
