ローカルだから安心?Chrome拡張機能、MCP、そしてサンドボックス脱出

MCPについてお話しします。おそらく耳にしたことがあり、それに伴うセキュリティリスクについても読んだことがあるでしょう。確かに不安をあおる話ではありますが、実際の現場に当てはめてみると、想像をはるかに超える深刻な事態になりかねません。

つい先週、私たちのシステムが不審なChrome拡張機能を検知しました。localhost上のポートにメッセージを送信していたのですが、一見しただけではさほど奇妙なものではありませんでした。しかし詳しく調べてみると、この拡張機能はローカルマシン上で稼働しているMCPサーバーと通信していたことが判明しました。

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

認証を経ずにファイルシステムへアクセスできてしまうケースや、場合によってはマシン全体を乗っ取られてしまうケースも起こり得ます。これはちょっとした問題ではありません。状況を一変させかねない、大規模な脆弱性なのです。

さらに厄介なのは、あらゆるChrome拡張機能がこの脆弱性を悪用できてしまう点です。特別な権限は一切必要ありません。ホストマシン上に脆弱なMCPサーバーが稼働してさえいれば、それで十分なのです。私たちはすでに、ファイルシステムアクセス、Slack、WhatsAppなどのサービスに紐づく脆弱なMCPサーバーを複数発見しています。これはもはや理論上のリスクではなく、現実の脅威であり、その被害は壊滅的なものになりかねません。

MCPをローカルで稼働させているのであれば、今こそセキュリティ対策を本気で見直すべきタイミングです。私たちもこの事実を発見したときは度肝を抜かれました。手遅れになる前に、すべての人がこの問題に注目すべき時が来ています。

それでは、心して読み進めていただき、一緒にこの問題を掘り下げていきましょう。

不審なlocalhost接続

ブラウザ拡張機能の挙動を監視していたところ、私たちの検知エンジンがlocalhostへネットワークリクエストを送信するChrome拡張機能を検出しました。この拡張機能自体には悪意ある挙動の兆候は見られませんでしたが、通信先が私たちの注意を引きました。通信先はModel Context Protocol(MCP)を実装したローカルサービスだったのです。MCPは、AIエージェントをエンドポイント上のシステムツールやリソースと連携させるためのプロトコルです。

これにより、すぐさま懸念が生じました。ブラウザ拡張機能がユーザーのマシン上で稼働するMCPサーバーと通信できてしまうのであれば、そのMCPを介して機密性の高いリソースへアクセスしたり、特権的な操作を実行したりすることを防ぐ手立てはあるのでしょうか。

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

まず、MCPクライアントがMCPサーバーとどのように通信するのかを理解しておきましょう。標準的なトランスポート実装は2種類存在します。

1. Server-Sent Events(SSE)——MCPサーバーがHTTP POSTリクエストを通じて通信できるようにする方式
2. Standard Input/Output(stdio)——MCPサーバーがプロセスの標準入出力ストリームを通じて通信できるようにする方式

MCPサーバーを実装する際、開発者はサーバーがどちらの方式で通信を行うかを選択できます。両方のトランスポート方式に対応させることも可能です。

重要なのは、トランスポート層自体には認証メカニズムが実装されておらず、また要求もされていないという点です。アクセス制御を実装するかどうかはMCPサーバーの開発者次第ですが、実際のところ、現在ほとんどのMCPサーバーはデフォルトで認証を強制していません。

ローカル利用の場合、Server-Sent Events(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拡張機能を作成しました。3001番ポートは、ローカルの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の利用を管理すること、厳格なアクセスポリシーを強制すること、そして拡張機能の挙動を綿密に監視することは、もはや譲れない優先事項として取り組むべき課題です。