Logo
x logo
2025-04-30

MCP（Model Context Protocol）における重大なセキュリティ脆弱性と企業が講じるべき対策

要約

Anthropic社が導入したMCP（Model Context Protocol）には、過剰な権限付与や保護機構の欠如など重大な脆弱性が存在します。脆弱性を悪用した攻撃により、データ漏洩やシステム侵害のリスクが生じる可能性が高いです。企業は最小権限原則の適用、プロセス分離型実装、厳格なコード検証など、包括的なセキュリティ対策の導入を求められています。本日はこのMCPの脆弱性について深掘りしていきます。

解説

MCP（Model Context Protocol）における重大な脆弱性とAI利用企業が注意すべき点

文字を読むのが面倒って方は、ポッドキャストでいかがですか？ ポッドキャストでお聞きになりたい方はこちらから

MCPの技術的概要と基本アーキテクチャ

MCP（Model Context Protocol）は、Anthropic社が2024年11月に導入したオープンスタンダードで、生成AIアプリケーションと外部データソースやツール間の統合を可能にする標準プロトコルです。 MCPは多層アーキテクチャで構成されます。

  1. MCP ホスト/クライアント：Claude Desktop、統合開発環境（IDE）、またはMCPを通じてデータにアクセスしたいAIツール
  2. MCP サーバー：標準化されたプロトコルを通じて特定の機能を提供する軽量プログラム
  3. ローカルデータソース：MCPサーバーがセキュアにアクセスできるコンピュータのファイル、データベース、サービス
  4. リモートサービス：MCPサーバーが接続できるインターネット経由の外部システム

技術的には、MCPサーバーはstdio（標準入出力）を介して実行することも可能で、HTTPサーバーを起動する必要なく、ローカルサーバーとのシームレスな連携を実現しています。これにより、低い技術ハードルでMCPの導入が可能になっていますが、同時にセキュリティリスクも生じています。

本日はココを深掘っていきたいと思います。

MCPにおける重大な脆弱性：技術的分析

1. 過剰な権限を持つ統合（Overprivileged Integrations）

  • 権限管理の欠如 MCPサーバーは、多くの場合、ファイルシステムへの完全なアクセス権などの広範な権限で動作します。これは、最小権限の原則に反する実装です。
  • OAuth トークンの不適切な保管 MCPサーバーは通常、複数サービス（Gmail、Google Drive、カレンダーなど）の認証トークンを保存します。攻撃者がMCPサーバーを侵害すると、これらすべてのサービストークンにアクセスでき、パスワード変更後も有効なままである場合があります。
  • URLベースのセッションID MCPプロトコル仕様では、URLにセッション識別子（GET /messages/?sessionId=UUID）を含めることが義務付けられており、これはセキュリティのベストプラクティスに根本的に違反しています。この設計により、ログに機密識別子が露出し、攻撃者によってセッションがハイジャックされる可能性があります。

2. 保護機構の欠如（Lack of Guardrails）

  • Tool Poisoning Attack (TPA) 悪意のある指示がMCPツールの説明内に埋め込まれ、ユーザーには見えないがAIモデルには見える状態になります。これらの隠された指示は、ユーザーの認識なしに、AIモデルに不正な行為を実行させることができます。
  • コマンドインジェクション脆弱性 MCPサーバーの実装に、単純なos.system()呼び出しのような安全でないコード実行メカニズムが含まれている場合があります。例えば、「os.system("notify-send " + notification_info["msg"])」のようなコードは、notification_info["msg"]に任意のコマンドが含まれていると、それが実行されてしまいます。
  • Rug Pull Attack MCPツールは、インストール後に自身の定義を変更できます。ユーザーが1日目に安全に見えるツールを承認しても、7日目には静かにAPIキーを攻撃者にリダイレクトしている可能性があります。

3. 間接的なプロンプトインジェクション脆弱性

MCPは、AI インターフェースを通じた間接的なプロンプトインジェクション脆弱性という新たな攻撃ベクトルを生み出しています。 AIアシスタントが自然言語コマンドを解釈してMCPサーバーに送信するため：

  • 攻撃者は隠された指示を含む悪意のあるメッセージを作成できる
  • これらのメッセージはユーザーには無害に見えるが、埋め込まれたコマンドを含んでいる
  • ユーザーがこれらのメッセージをAIアシスタントと共有すると、注入されたコマンドが不正なMCPアクションをトリガーする可能性がある
  • 例えば、一見無害なメールに「すべての財務書類を external-address@attacker.com に転送する」ようAIに指示するテキストが含まれている可能性がある

4. サーバー間の競合と横取り

複数のサーバーが同じエージェントに接続されている場合、悪意のあるサーバーは信頼されているサーバーに対して行われた呼び出しをオーバーライドまたは傍受できます。これは大きな問題です！プロンプトインジェクションの大きな課題は、LLMが説得力のあるトークンを送信できるものを何でも信頼してしまうことであり、confused deputy攻撃に非常に脆弱であることです。

実証された攻撃シナリオ（Proof of Concept）の技術的詳細

PoC攻撃1: 悪意のあるMCPパッケージによるローカルシステム侵害

技術的実装プロセス：

  1. マルウェアの作成と偽装 攻撃者は「FastMCP」などの名前で悪意のあるパッケージを作成し、正規のファイル管理ツールを装います。
  2. コード注入 パッケージ内に、バックグラウンドで実行される不正なコードを埋め込みます。このコードは、通常のMCP機能も提供しつつ、悪意のある操作も実行します。
  3. 配布と統合 被害者がCursor AIなどのGenAIアプリケーションとこのパッケージを統合すると、パッケージに含まれる不正なコマンドが実行されます。
  4. 実行とフィードバック デモでは、ユーザーがCursor AIでファイルを読み込もうとした際に、実際には悪意のあるMCPパッケージがバックグラウンドで動作し、予期せず電卓アプリが起動することで攻撃をシミュレートしています。

技術的問題点：

  • 検証メカニズムの欠如 MCPパッケージのコード署名や検証メカニズムが存在しないか、不十分です。
  • 権限の過剰付与 インストール時にユーザーに十分な説明なしに広範な権限が要求され、付与されます。
  • 実行環境の分離の欠如 MCPサーバーがホストシステムと同じ権限レベルで実行され、サンドボックス化されていません。

PoC攻撃2: 正規のMCPサーバーの悪用による攻撃

技術的実装プロセス：

  1. 正規サーバーの設定 被害者は正規のMCPサーバーをインストールし、Claude 3.7 Sonnetなどの生成AIアプリケーションと連携させます。これにより、GenAIアプリケーションはローカルファイルへの読み書きアクセスなどの権限を持つようになります。
  2. プロンプトインジェクション文書の作成 攻撃者は悪意のあるプロンプトを埋め込んだ文書（例：偽の監査文書）を作成します。
  3. ソーシャルエンジニアリング 攻撃者は金融アナリストを装って被害者に文書を送信し、MCPサーバーがインストールされた状態のClaudeにアップロードするよう誘導します。
  4. 攻撃の実行 文書が処理されると、隠されたプロンプトがMCPサーバーを操作し、被害者のファイルを暗号化するなどの攻撃が実行されます。

技術的問題点：

  • プロンプト検証の欠如 アップロードされる文書に含まれるプロンプトの検証メカニズムが存在しません。
  • サンドボックス実行の欠如 MCPサーバーがユーザー権限で実行され、重要なシステムやファイルにアクセス可能です。
  • インテント検証の不足 AIモデルが要求する操作の意図や安全性を検証するメカニズムがありません。

MCP脆弱性の具体的影響：産業別リスク分析

業界別にどういうリスクが出てくるのかを考えてみましょう。

金融業界

  • データ漏洩リスク MCPサーバーが財務記録へのアクセス権を持つ場合、攻撃者は顧客の財務データ、取引情報、または内部財務レポートにアクセスし、窃取する可能性があります。
  • 取引改ざんリスク プロンプトインジェクション攻撃により、AIが財務取引や承認プロセスを不正に操作する可能性があります。
  • コンプライアンス違反 金融業界でのMCP脆弱性の悪用は、GDPRなどの規制違反につながる可能性があります。

医療業界

  • 患者情報漏洩 MCPが医療記録にアクセスできる場合、攻撃者はHIPAA違反となる患者の個人情報を窃取する可能性があります。
  • 医療機器制御リスク MCPがネットワーク接続された医療機器と連携している場合、攻撃者が機器の操作や設定を変更する可能性があります。
  • 診断システム改ざん AI支援診断システムと連携するMCPは、悪意のあるプロンプトにより誤診を引き起こす可能性があります。

製造・重工業

  • 生産システム侵害 MCPが産業制御システム（ICS）と連携している場合、攻撃者が製造プロセスを妨害する可能性があります。
  • 設計データ窃取 MCPがCADシステムにアクセスできる場合、攻撃者は知的財産や設計データを窃取する可能性があります。
  • サプライチェーン攻撃 MCPの脆弱性は、サプライチェーン攻撃の新たな経路となり、企業ネットワークに第三者開発者経由で侵入する可能性があります。

AI利用企業が実施すべき対策は？

1. MCPパッケージの出所管理とコード検証

  • ソースコードレビュー 導入前にMCPパッケージのソースコードを詳細にレビューし、悪意のあるコードや安全でない実装がないか確認します。
  • コード署名の義務付け 信頼できるコード署名（Trusted code signing）の仕組みを導入し、署名のない実行を防止します。
  • 依存関係スキャン パッケージの依存関係を分析し、既知の脆弱性を持つライブラリが含まれていないか確認します。
  • サンドボックステスト 導入前に隔離環境でMCPパッケージをテストし、予期しない動作や不審な通信がないか監視します。

2. 厳格な権限管理の実装

  • 最小権限の原則の適用 MCPサーバーには、動作に必要な最小限の権限のみを付与します。
  • 権限の細分化 ファイルアクセス、ネットワーク通信、システムコマンド実行などの権限を個別に制御し、必要なものだけを有効にします。
  • 時間制限付き権限 重要な操作に対しては、一定時間のみ有効な一時的な権限を付与する仕組みを導入します。
  • 権限の定期監査 付与されている権限を定期的に見直し、不要になったものは速やかに削除します。

3. プロンプトインジェクション対策

  • プロンプトスキャニング AIモデルに送信される前にすべての入力をスキャンし、悪意のあるプロンプトパターンを検出します。
  • サニタイズフィルタ 特殊文字や制御シーケンスをエスケープまたは除去し、プロンプトインジェクションのリスクを低減します。
  • コンテキスト分離 ユーザー入力とシステム指示を明確に分離し、入力がシステム指示を上書きできないようにします。
  • 意図確認メカニズム 重要な操作（ファイル削除、外部データ送信など）の前に、ユーザーに明示的な確認を求める仕組みを導入します。

4. ネットワークセキュリティ強化

  • 通信の暗号化 MCPサーバーとAIモデル間、およびMCPサーバーと外部サービス間のすべての通信にTLS 1.3以上の暗号化を適用します。
  • ネットワークセグメンテーション MCPサーバーを専用のネットワークセグメントに配置し、アクセス可能なシステムを制限します。
  • 通信監視 MCPサーバーの通信を監視し、不審なトラフィックパターンや予期しない外部接続を検知します。
  • API呼び出し制限 MCPサーバーが行えるAPI呼び出しの頻度と量に制限を設け、大量データ漏洩のリスクを軽減します。

5. ツール定義の変更監視

  • 定義ハッシュ検証 MCPツールの定義のハッシュ値を保存し、定期的に検証して不正な変更を検知します。
  • ユーザー通知システム クライアント実装は、ツールの説明が変更された場合にユーザーに通知するべきです。
  • バージョン管理 MCPツールの定義に厳格なバージョン管理を適用し、承認されていない変更を防止します。
  • 定期的な再検証 導入済みのMCPツールを定期的に再検証し、後から悪意のある変更が加えられていないか確認します。

6. MCPサーバー・AI連携の監視と制御

  • 行動分析システム MCPサーバーの動作を継続的に監視し、異常なパターン（大量のファイルアクセス、不審なファイル暗号化など）を検知します。
  • データ流出防止（DLP） 重要データが権限のないMCPサーバーやAIモデルに送信されないよう、DLPソリューションを実装します。
  • リアルタイムアラート 危険な操作（システムコマンド実行、大量データ転送など）が検出された場合、即時にセキュリティチームに通知します。
  • 自動遮断メカニズム 明らかに悪意のある行動が検出された場合、自動的にMCPサーバーの実行を停止または隔離します。

7. MCPセキュリティ監査ツールの導入

  • MCPSafetyScanner Brandon Radosevichらが開発したMCPSafetyScannerのような、MCP環境の脆弱性を自動的に検出するツールを導入してみる。
  • 自動セキュリティ評価 定期的にMCPサーバーとその設定に対して自動セキュリティ評価を実行します。
  • ペネトレーションテスト 定期的にMCP環境に対するペネトレーションテストを実施し、実際の攻撃シナリオに対する耐性を検証します。
  • コードの静的解析 MCPサーバーのコードを定期的に静的解析し、潜在的なセキュリティ問題を早期に発見します。

プロセス分離型MCPサーバーによるセキュリティ強化

1. 最小権限プロセスとしてのMCPサーバー実装

より安全なMCPサーバー運用のためには、プロセスレベルの分離とサンドボックス化が効果的です：

# 例：最小権限でMCPサーバーを起動するシェルスクリプト
sudo -u mcp_restricted_user \
  systemd-run --user --scope \
  -p MemoryMax=100M \
  -p CPUQuota=10% \
  -p CapabilityBoundingSet='' \
  -p NoNewPrivileges=true \
  -p PrivateDevices=true \
  -p PrivateNetwork=false \
  -p PrivateTmp=true \
  -p ProtectHome=true \
  -p ProtectSystem=strict \
  ./mcp_server --allowed-paths=/data/shared,/tmp/mcp

このアプローチでは、MCPサーバーが以下の制約の下で実行されます。

  • 専用の制限付きユーザーアカウントで実行
  • メモリと CPU 使用量の制限
  • 重要なシステム領域へのアクセス制限
  • デバイスやホームディレクトリへのアクセス禁止
  • 特定のディレクトリへのアクセスのみを許可

2. プロキシベースのセキュリティレイヤー

MCPクライアントとMCPサーバー間にセキュリティプロキシレイヤーを導入することで、リクエストの検証と制御を強化できます。

# プロキシベースのMCPサーバーの簡略化されたコード例
class MCPSecurityProxy:
    def __init__(self, allowed_paths=None, allowed_actions=None):
        self.allowed_paths = allowed_paths or []
        self.allowed_actions = allowed_actions or ["read"]
        self.audit_log = AuditLogger()
        
    def handle_request(self, request):
        # リクエストの検証
        if not self._validate_request(request):
            self.audit_log.log_security_event("invalid_request", request)
            return {"error": "Invalid request or unauthorized action"}
            
        # 許可されたアクションの実行
        try:
            if request["action"] == "read_file":
                return self._handle_file_read(request["path"])
            # その他のアクション...
            
        except Exception as e:
            self.audit_log.log_security_event("execution_error", str(e))
            return {"error": "Execution error"}
    
    def _validate_request(self, request):
        # アクションの検証
        if request.get("action") not in self.allowed_actions:
            return False
            
        # パスの検証（パストラバーサル攻撃の防止）
        if "path" in request:
            normalized_path = os.path.normpath(request["path"])
            if not any(normalized_path.startswith(p) for p in self.allowed_paths):
                return False
                
        return True
        
    def _handle_file_read(self, path):
        # パスの再検証
        normalized_path = os.path.normpath(path)
        if not any(normalized_path.startswith(p) for p in self.allowed_paths):
            return {"error": "Path access denied"}
            
        try:
            with open(normalized_path, 'r') as f:
                content = f.read()
            self.audit_log.log_access("file_read", normalized_path)
            return {"content": content}
        except Exception as e:
            return {"error": str(e)}

3. リアルタイム監視とレスポンス

MCPサーバーの運用中は、継続的な監視と迅速な対応が必要です。

  • 振る舞い分析 MCPサーバーの通常の動作パターンを学習し、異常を検出するシステムを導入
  • リアルタイムアラート 異常な動作（大量のファイルアクセス、通常とは異なるAPIコール）を検出した際に即時通知
  • 自動応答ポリシー 危険度に応じた自動応答（接続遮断、プロセス一時停止、管理者通知）を設定
  • フォレンジック機能 セキュリティイベント発生時に詳細な分析が可能なログ収集と保存の仕組み

今後の動向と長期的対策

Cato Networksの調査によれば、現時点ではMCPの普及はまだ限定的ですが、その利便性から今後普及が進むことが予想され、それに伴い攻撃のリスクも増大する可能性があります。

長期的には、下記のような動向に注目し対策を講じる必要があると考えます。

  1. プロトコル自体の改善 MCPエコシステムは、プロトコル、サーバー、クライアントレベルでこの基本的なセキュリティ脆弱性に対処する必要があります。

  2. 標準化されたセキュリティフレームワーク MCPの認証、整合性制御、セッション管理に関する標準化されたセキュリティフレームワークが必要です。

  3. Anthropicの対応 Anthropic社が2025年第3四半期に導入を予定しているより粒度の細かい権限制御と開発者セキュリティガイドラインに注目し、早期に対応する必要があります。

  4. セキュリティ対策の進化 MCPSafetyScannerのような専用のセキュリティツールの進化と導入が重要になります。

本日のまとめ

MCPは生成AIアプリケーションとデータソース・ツールとの統合に革命をもたらす可能性を持っていますが、同時に重大なセキュリティリスクも伴います。特に、過剰な権限を持つ統合と保護機構の欠如という2つの主要な脆弱性が、データ窃取、ランサムウェア攻撃、不正アクセスなどの深刻な脅威を生み出しています。

企業はMCP統合を未検証のソフトウェアと同様に慎重に扱い、包括的なセキュリティ対策を講じることが不可欠です。権限管理の厳格化、コード検証の徹底、プロンプトインジェクション対策、そして継続的な監視と監査を組み合わせることで、生成AIの変革的な可能性を安全に活用することができます。

最適なアプローチはユースケースや環境によって異なりますが、最小権限の原則、プロセス分離、プロキシベースのアーキテクチャ、そして多層防御を基本とするセキュリティ戦略が、MCPが提供する革新的な機能を安全に活用するための鍵となります。

エンタープライズ環境では、これらの技術的対策に加えて、包括的なセキュリティポリシー、従業員教育、そして定期的なセキュリティ評価を組み合わせた総合的なアプローチが不可欠です。AI技術の急速な進化と同じペースで、セキュリティ対策も進化させていく必要があります。

世界のセキュリティ最前線
Packet News 一覧へ