信じてください、ローカルです：Chrome拡張機能、MCP、およびサンドボックスエスケープ

MCPについて話しましょう。おそらくあなたはそれについて聞いたことがあるでしょうし、それに関連するセキュリティリスクについて読んだかもしれません。確かに、それらは懸念されているように聞こえますが、実際の環境に置くと、想像以上に深刻な懸念になる可能性があります。

先週、私たちのシステムが疑わしいChrome拡張機能にフラグを立てました。それはlocalhostのポートにメッセージを送信していました。一見しただけではそれほど奇妙ではありませんが、より詳しく調査すると、この拡張機能がローカルマシンで実行されているMCPサーバーと通信していることがわかりました。

Chrome拡張機能がMCPと通信できるという事実は、深刻なリスクです。その影響は計り知れません。Chromeのサンドボックスモデルのような通常のセキュリティ対策は全く役に立ちません。

認証なしでファイルシステムへのアクセスを獲得でき、場合によってはマシン全体を乗っ取られるリスクに直面しています。これは小さな問題ではなく、巨大でゲームチェンジャーとなる脆弱性です。

任意のChrome拡張機能がこれを悪用できます。特別な権限は必要ありません。ホストマシン上で脆弱なMCPサーバーが実行されている場合、それで終わりです。ファイルシステムアクセス、Slack、WhatsAppなどのサービスに関連する脆弱なMCPサーバーが既に見つかっています。これはもはや理論的なリスクではなく、現実であり、その影響は壊滅的となる可能性があります。

したがって、MCPをローカルで実行している場合は、セキュリティを真剣に再評価する時が来ました。私たちはこれを発見したときに仰天しましたが、手遅れになる前に他の誰もが気づく時が来ました。

では、準備を整えて、一緒にこれに飛び込みましょう。

疑わしいlocalhostコネクション

ブラウザ拡張機能のアクティビティを監視している間に、私たちの検出エンジンはlocalhost宛のネットワークリクエストを行うChrome拡張機能にフラグを立てました。拡張機能自体は悪意のある動作の兆候を示していませんでしたが、その宛先が私たちの注目を集めました。これはモデルコンテキストプロトコル（MCP）を実装するローカルサービスと通信していました。MCPはAIエージェントをエンドポイント上のシステムツールとリソースと接続するために使用されるプロトコルです。

これは即座に懸念を提起します。ブラウザ拡張機能がユーザーのマシン上で実行されているMCPサーバーと話すことができる場合、MCPを通じて機密リソースにアクセスしたり、特権付きアクションを実行することを止めるものは何ですか？

MCP：デフォルトでオープン

まず、MCPクライアントがMCPサーバーと通信する方法を理解しましょう。2つの標準的なトランスポート実装があります。

1. サーバー送信イベント（SSE）：MCPサーバーがHTTP POSTリクエストを通じて通信できるようにします。
2. 標準入力/出力（stdio）：MCPサーバーがプロセスの標準入力および出力ストリームを通じて通信できるようにします。

MCPサーバーを実装する際、開発者はMCPサーバーがどのように通信するかを選択できます。サーバーは両方のトランスポート方法をサポートできます。

トランスポートレイヤー自体は認証メカニズムを実装したり、要求したりしないことに注意することが重要です。アクセス制御を実装するのはMCPサーバー開発者次第ですが、実際には今日のほぼすべてのMCPサーバーはデフォルトで認証を強制しません。

ローカルで使用する場合、SSE（サーバー送信イベント）に依存するMCPサーバーは通常、localhost上のポートにバインドされ、同じマシン上で実行されているプロセス（MCPクライアントなど）からアクセス可能になります。

サンドボックス、ハンマーに会う

ローカルのSSEベースのMCPサーバーがどのように動作するか、そして一般的に同じマシン上で実行されているプロセスがアクセス可能であることを理解したので、質問を再検討できます。Chrome拡張機能もそれにアクセスできますか？

通信フローはかなり簡単です：

• クライアントがサーバーにGETリクエストを送信して、セッションIDとメッセージエンドポイントを取得します。認証形式がありません。
• 初期化されると、クライアントはそのメッセージのエンドポイントにPOSTリクエストを発行して、MCPサーバーによって公開されている利用可能なツールのリストを取得し、それらを直接呼び出すことができます。

まず、mcp.soからローカルSSEベースのMCPサーバーをセットアップしました。特にファイルシステムバリアントを選択しました。これにより、AIクライアントがローカルファイルシステムと相互作用できます。サーバーのREADMEのセットアップ手順に従いました：

node dist/index.js ~/work/mcp/private_directory

次に、バックグラウンドで実行され、localhost:3001への接続を試みるChrome拡張機能を構築しました。ローカルSSEベースのMCPサーバーに一般的に使用されるポートです。もちろん、このポートは異なる場合があるため、実際の拡張機能はローカルポートをスキャンしてアクティブなMCPインスタンスを見つける必要があります。拡張機能はサーバー情報を取得し、ツールリストを取得し、MCPサーバーによって提供されるツールを呼び出そうとしました：

Chrome拡張機能はMCPサーバーのツールに無制限にアクセスでき、認証は必要ありませんでした。そして、ファイルシステムがサーバーの公開されている機能の中核部分であるかのように相互作用していました。これの潜在的な影響は巨大で、悪意のある悪用と完全なシステム侵害への扉を開いています。

異なるMCPサーバーと統合することは、プロトコルの設計目標のおかげでほぼ労力を必要としませんでした。基本的な実装に関係なく、様々なMCPサーバーと相互作用するための統一インターフェースを提供することです。

また、Slack MCPをセットアップしてみました。Chrome拡張機能はそれにアクセスでき、その公開されている機能と相互作用できました：

このPOCはChrome拡張機能アーキテクチャの完全なサンドボックスエスケープを実証しています。Chromeはプライベートネットワークアクセスに関するセキュリティ制御を強化しましたが、ブラウザ拡張機能は依然として注目すべき例外です。

2023年に、Googleはユーザーのプライベートネットワーク（例：localhost、192.168.x.xなど）に到達することを防ぐためのより厳しい措置を導入しました。これは、公開ウェブサイトで実行されている悪意のあるスクリプトによる内部インフラの調査または攻撃から保護することを目的とした動きです。

2023年9月：Chrome 117が安定版にロールアウトされ、廃止予定試行期間が終了します。Chromeはパブリック、非セキュアコンテキストからのすべてのプライベートネットワークリクエストをブロックします。

Chrome拡張機能は通常のウェブページと比較して昇格された機能で動作しますが、明示的に権限を与えられない限り、Chromeのサンドボックス原則を遵守するように設計されています。オペレーティングシステムとローカルリソースから隔離されたままです。

ただし、localhostへの無制限のアクセスはその隔離バリアを破り、ローカルマシンおよびより広い組織環境の両方との予期しない相互作用を可能にします。特にローカルMCPサーバーのような公開されたサービスを通じて。

混乱を封じ込める

MCPエコシステムは導入以来急速に拡大しており、何千ものサーバーが多様な機能を提供しています。これは強力な新しい可能性をもたらしますが、成長するセキュリティリスクのセットも導入します。実証されたように、特別な権限を持たない単純なChrome拡張機能は、サンドボックスを破り、ローカルMCPサーバーに接続し、ユーザーに代わって特権付きアクションを実行できます。これは効果的にブラウザサンドボックスが構築されていた隔離モデルを粉砕しています。そしてこれらのMCPサーバーがファイルシステム、Slack、またはWhatsAppのようなツールへのアクセスを認証を強制せずに公開する場合、理論的な懸念から企業全体の脅威に跳躍します。

セキュリティチームにとって、これは単なる新しいベクトルではなく、完全に新しい攻撃面です。そして危険に過小評価されています。MCPは既に開発環境と本番システムで展開されており、しばしば最小限の監視またはアクセス制御で展開されています。チェックされないままにすると、エンドポイントへのオープンなバックドアを提供し、従来のディフェンスを迂回します。MCP使用を管理し、厳しいアクセスポリシーを強制し、拡張機能の動作を厳密に監視することは、避けられない優先事項になる必要があります。