Model Context Protocolがハッキングされる方法

Victor Moussa | shutterstock.com

オープンソース規格であるModel Context Protocol（MCP）は、AIシステムが多様なデータソース、ツール、サービスと統合の手間なくやり取りできるようにします。これにより、エージェンティックAIなどの基盤も構築されます。しかし、MCPサーバーを自社のAI戦略の一部として導入しようとする企業は、それに伴うリスクも認識しておく必要があります。

そこで本記事では、Model Context Protocolに関連する最大の10の脆弱性をまとめました。

1. テナント間データ漏洩

クロスサイトスクリプティング攻撃のように、テナントをまたぐデータ漏洩は、あるユーザーグループが他のユーザーのデータにアクセスできてしまうことを意味します。これは社内チームだけでなく、ビジネスパートナーや顧客にも影響を及ぼす可能性があります。この脆弱性がすでにAsanaのMCPサーバー実装で発見された事実は、警鐘と捉えるべきです。

この問題を詳細に分析したUpGuardの研究者によると、解決策はMCPサーバーが厳格なテナント分離を徹底することです。また、アクセス時には最小権限の原則を適用すべきです。

2. 隠れたプロンプトインジェクション

攻撃者が従業員やビジネスパートナー、顧客になりすまし、人間のサポート担当者にリクエストを送ります。しかしその中には、AIだけが読み取れる隠れたプロンプトが含まれています。サポート担当者がこのリクエストをMCPサーバー経由で機密データや業務プロセスにアクセスできるAIアシスタントに転送すると、大きな被害が発生する恐れがあります。

この脆弱性を防ぐため、企業ユーザーには以下が推奨されます：

• AIとのやり取りには最小権限の原則を徹底すること
• プロンプトをリアルタイムで不審な内容がないか分析すること
• MCPの全アクティビティの監査ログを記録すること

MCPサーバーのセットアップは難しい場合があります。そのため、多くの「すぐ使える」MCPサーバーがダウンロード可能です。しかし、ユーザーはGoogle検索で最初に見つかったものを安易にダウンロードすべきではありません。もしそれが悪意あるものであれば、MCPサーバーの説明欄が他のシステムから情報を抜き取るよう細工されている場合があり、その際に暗号化やセキュリティ対策も回避されてしまう可能性があります。この手法はInvariant LabsがWhatsAppの事例でブログ記事で実演しています。

悪意ある指示が含まれるのは説明欄だけではありません。攻撃対象はMCPサーバーが生成するすべての情報に及びます。たとえば：

• 関数名
• パラメータ
• パラメータのデフォルト値
• エラーメッセージ
• フォローアッププロンプト
• 必須フィールドや型

これを防ぐため、まずダウンロード元が信頼できるか確認しましょう。次に、要求される権限をチェックすることが推奨されます。例えば、猫のコンテンツを提供するだけのMCPサーバーにファイルシステムへのアクセス権は不要です。可能であればソースコードも確認しましょう。難しい場合は、BackSlash社が提供する「MCP Server Security Hub」のような支援ツールを活用するとよいでしょう。

さらに、MCPサーバーはインストール時に一度だけ確認すれば十分というわけではありません。攻撃者がソフトウェアサプライチェーンを標的にし、正規のパッケージに後からマルウェアを仕込む可能性もあるためです。これはCyberArkのブログ記事でも指摘されています。

4. 「オープン」プロンプトインジェクション

悪意あるプロンプトは隠されている必要はありません。プロンプトインジェクションを公開プラットフォームに移すことで、AIエージェントにデータを漏洩させたり、信頼できるMCPサーバー経由でマルウェアを実行させたりすることも可能です。

この手法は、Variant Labsの研究者がGitHub MCPサーバーの事例で実証しています。攻撃者は公開リポジトリに新しい「Issue」を作成し、プロンプトインジェクションを含めます。企業がAIエージェントにこのリポジトリの全オープンIssueをチェックさせると、エージェントは悪意あるプロンプトを処理してしまいます。たとえば、別のプライベートリポジトリにある全ての個人データを収集するよう指示されることも。GitHubサーバー自体は侵害されず、攻撃の経路として使われるだけです。

対策としては、全てのツール呼び出しを人間のユーザーが承認することが考えられます。しかしInvariantの研究者はブログで「多くのユーザーはAIエージェントに対してすでに『常に許可』ポリシーへ移行しており、個々のアクションを確認しなくなっている」と指摘しています。

5. トークンの窃取

OAuthトークンがMCPサーバーの設定ファイルやコードファイルに暗号化せず保存されている場合、盗まれるリスクがあります。攻撃者はバックドアやソーシャルエンジニアリングなど様々な手法でこれを狙います。認証トークンが攻撃者の手に渡れば、攻撃者は自分のMCPサーバーインスタンスを作成できると、Pillar Securityのブログ記事は指摘しています。

「従来のアカウント乗っ取りと異なり、MCPを介した盗難トークンの利用は正規のAPIアクセスのように見えるため、検知が難しくなります」とセキュリティ専門家は警告しています。例えばGmailアカウントの場合、サイバー犯罪者は全メール履歴へのアクセス、偽装メールの送信、データ削除、機密情報の抽出、転送ルールの設定による今後の通信の監視などが可能になります。

6. コンポーザビリティ・チェイニング

前述の通り、サードパーティのMCPサーバーを無検証で使うのは危険です。必ずしもそのサーバー自体が改ざんされていなくても、別のリモートサーバーにリクエストを送る場合があります。このMCPの攻撃ベクトルは、CyberArkの専門家により「コンポーザビリティ・チェイニング」と呼ばれています。

2つ目のMCPサーバーは一見正規の出力を返しますが、実は隠れた悪意あるプロンプトが混入している可能性があります。1つ目のMCPサーバーはそれを自身の出力と組み合わせてAIエージェントに渡し、AIはその指示を実行します。環境変数に機密データが含まれている場合、直接リモートサーバーと接続せずとも情報が流出する恐れがあります。

7. ユーザーの疲弊

AIエージェントの全アクションを人間の専門家が承認している企業でも、安心はできません。Palo Alto Networksはブログ記事で、悪意あるMCPサーバーがAIエージェント（と人間の管理者）に無害なリクエスト（例：読み取り権限）を大量に送りつけ、ユーザーが確認を面倒に感じて承認してしまう状況を作り出せると指摘しています。そうなれば、長文の中に巧妙に隠された悪意あるプロンプトが承認されるタイミングが生じます。

「この攻撃の基本的な考え方は、MFA疲労攻撃と似ています。ユーザーは継続的な認証要求に圧倒され、不正なエンティティにアクセスを許してしまうのが狙いです」とPalo Altoの研究者は説明しています。

8. 管理者バイパス

この攻撃ベクトルでは、ID確認を要求しないよう設定されたMCPサーバーが狙われます。例えば、企業がユーザー向けにAIエージェントが素早く情報を取得できるMCPサーバーを設置した場合などです。

ユーザーが低レベルの情報にしかアクセスできない設定でも、MCPサーバーがIDを確認しなければ、AIエージェントは本来見られない情報まで取得できてしまいます。このMCPサーバーが外部のパートナーや顧客、一般公開されている場合、権限昇格によってさらに大きな被害につながる可能性があります。

9. コマンドインジェクション

MCPサーバーがユーザー入力を正しく検証せず、他システムに直接渡してしまう場合、ユーザーは自分のコマンドを注入できてしまいます。これはSQLインジェクション攻撃と似た手法です。悪意ある攻撃者はこれを利用して、MCPサーバーが公開している全ツールに対しコマンドインジェクションの脆弱性をテストすることができます。

他のインジェクション攻撃と同様、MCPサーバーはユーザー入力をシェルコマンドに直接渡さないよう設定すべきです。入力を正しく検証し、パラメータ化されたコマンドを使うことが推奨されます。

AIエージェントが複数のMCPサーバーにアクセスできる場合、あるサーバーがエージェントを誘導して、別のサーバーを不適切に利用させることもあり得ます。

医療分野の架空の例：ある企業が2つのMCPサーバーを運用しています。1つはサードパーティ製で医療症状の一般情報を提供し、もう1つは患者の請求情報を管理します。請求システム用サーバーは安全で正常に動作していますが、もう1つのサーバーは一見正常に見えて実は悪意があり、AIエージェントにバックグラウンドで請求情報を漏洩するよう指示します。たとえば、メールで情報を送信するなどです。（fm）

ITセキュリティに関する他の興味深い記事もご覧になりたいですか？無料ニュースレターで、セキュリティ担当者や専門家が知っておくべき情報をすべて、あなたの受信箱にお届けします。