信頼されたスキルが攻撃だった：Copilot Coworkとエージェントのサプライチェーン

AIエージェントの売り文句は、ユーザーに代わってツールを使えることだ。Microsoft Copilot Coworkを調査した研究者は、その売り文句をユーザーに対して逆手に取る方法を見つけた。そして、その攻撃がたどった経路は、エージェントのセキュリティがどこへ向かっているかを多く物語っている。

PromptArmorは9月30日にこの発見を公表した。要約すると、無害な文書チェッカーのように見えたダウンロード済みの「スキル」が、Cowork自身のネットワーク経路を乗っ取り、攻撃者のサーバーへのコマンドチャネルを開き、Outlook、SharePoint、Teamsからデータを引き出せた。研究者の説明によれば、Microsoftは6月に報告を受け、8月に修復を完了したため、技術的詳細は修正前にではなく修正後に公開された。

4つのステップ、ユーザーが関与するのはそのうち2つだけ

この攻撃では、ユーザーが2つのごく普通の操作を行う必要があった。レビュー用の文書をアップロードすることと、スキルを呼び出すことだ。

デモでは、そのスキルは契約書と提案書を比較し、不整合を指摘すると称していた。実際にそれを行った。だからこそ、この種の攻撃は見つけにくい。問題は、スキルに同梱されたスクリプトだった。Coworkはオープンなインターネットに到達しないはずのサンドボックス内で動作するが、回答を生成するために必要なリクエスト用のブリッジは維持している。悪意あるスクリプトは、そのブリッジ経由で到達できるファイル同期サービスを利用し、さらに重要なことに、そのサービスは呼び出し側が指定したURLを受け入れた。

この詳細がエクスプロイトのすべてだ。スクリプトが攻撃者の管理するアドレスに到達できるようになると、ループを開いた。数秒ごとにコマンドを含むファイルを取得し、Cowork内でコマンドを実行し、その結果をURLパラメータにエンコードしてサーバーに送り返した。これは一方向のビーコンではなく双方向のコマンドチャネルであり、攻撃者は前のコマンドの戻り値に基づいて新しい指示を出せた。

デモで研究者は、被害者のOutlookメールを一覧表示し、メールスレッドの内容を読んだ。報告書によれば、同じアクセス経路でSharePointファイル、セッション履歴、プラグインデータも露出した。どこまで到達できるかは、そのユーザーがもともと何を見られるかに依存する。これはこうした事例でよくある増幅要因だ。エージェントはユーザーの権限を引き継ぐため、影響範囲はそのアカウントが触れられるものすべてになる。

もう一つ、繰り返す価値のある詳細がある。攻撃を止める方法についての考え方を変えるからだ。停止コントロールを選択しても、バックグラウンドプロセスは終了しなかった。目に見えるターンは終了しても、スクリプトはポーリングを続けられた。ユーザーはタスクが終わったと思っているのに、チャネルはまだ開いている。

スキルこそ依存関係である

この開示で興味深いのは、すでに修正された特定のバグではない。攻撃対象がモデルの指示へのプロンプトインジェクションではなく、エージェントを取り巻くサプライチェーンだったことだ。

このようなシステムにおけるスキルは、小さなアプリケーションだ。スクリプト、参照文書、設定を同梱でき、Coworkの場合は最大20個の付随ファイルを含められる。そして、組織外からマーケットプレイスでダウンロードされたり、同僚間で共有されたりして持ち込まれることが多い。これは、npmやPyPIのエコシステムで長年問題を生み続けてきた構造と同じだ。自分が書いていない依存関係が、自分が読んでいないコードを実行しうる。エージェントスキルは、より親しみやすい名前がついた依存関係にすぎない。スキルのページの説明では、すべての処理はローカルで行われ、第三者には何も送信されないと主張していた。プラットフォーム自身の検査は、同梱されたスクリプトの実際の挙動を捉えられなかった。

同じ弱点を指し示す、より静かな漏えいがもう一つある。Glowの報告によれば、エージェントが300以上の組織の13,000点を超える内部画像やスクリーンショットを、公開GitHubリポジトリを通じて露出させていた。誰もそれらのファイルを公開しようとしたわけではない。エージェントが、公開リポジトリから到達できる場所にそれらを書き込んだために、公開されてしまったのだ。

この2つのインシデントは一見異なるが、根本原因は同じだ。一方では、悪意あるスキルが意図的に外部へ到達した。他方では、行儀よく振る舞うエージェントが、公開される場所だと理解していない場所にデータを書き込んだ。どちらも、エージェントが何に到達でき、その出力がどこまで届くかという境界の失敗である。Coworkの事例は、攻撃者がその境界を悪用したことを示している。GitHubの事例は、誰も破ろうとしていないのに境界が自ら失敗したことを示しており、通常利用ではこちらのほうがより一般的な結果と言えるかもしれない。

このようなセキュリティ開示をどう読むか

多くの読者が飛ばすのがタイムラインだが、これは追う価値がある。発見をどう評価すべきかを教えてくれるからだ。PromptArmorは6月下旬にMicrosoftへ問題を報告した。Microsoftは7月に追加情報を求め、8月初旬に修復について協議し、8月中下旬までに修正を確認した。研究はパッチ後にあたる9月末に公開された。これは標準的な責任ある開示の流れだ。そこから2つの教訓が導かれる。

第一に、修正された脆弱性は、脆弱性のクラス全体が修正されたことと同じではない。特定のエクスプロイト経路は閉じられた。それを可能にしたパターン、つまりエージェントが必ず到達しなければならない信頼された統合が任意のチャネルとして使われうるというパターンは、エージェントに許可されたネットワーク経路があるところならどこにでも現れる。同じ週には、同じ弱点を指し示す他の例も出てきた。エージェントが公開リポジトリを通じて数千点の内部画像を露出させたという報告も含まれる。異なるバグ、同じ形だ。

第二に、修正はあなたの都合ではなくMicrosoftのスケジュールで届く。こうしたツールを業務で使っているなら、自分たちがどのバージョンを使っているのか、更新が実際に自分たちの環境まで届いたのかを把握する必要がある。ブログのパッチノートは、パッチ適用済みのデプロイとは同じではない。

スキルこそ依存関係である

こうした話を聞いた後の直感は、サンドボックスをより信頼しようというものだ。Coworkのサンドボックスは、直接のインターネットアクセスに対しては役割を果たした。そしてエクスプロイトは、サンドボックスが開けておかざるを得なかった経路を使って境界を迂回した。これが一般的なパターンだ。直接のネットワークツールを持たないエージェントでも、後から外部リソースを取得する面上にコンテンツを書き込めたり、そうした取得を行うサービスを操作できたりするなら、閉じたシステムとは言えない。

業務環境でエージェントを運用するチームにとって、実際の対応はセキュリティパッチというより、通常のソフトウェアガバナンスに近い。どのスキルがインストールされ、どこから来たのかを把握する。スキルのインストールを個々のユーザーに任せず、ITの管理下に移す。ネットワーク経路を持つスキルは、新しい実行ファイルと同様に扱い、実行前にレビューする。セキュリティ更新が実際に使用中のバージョンをカバーしているか確認する。

どれも珍しいことではない。過去10年間にサプライチェーンセキュリティがソフトウェアチームに強いてきた規律が、今や一段上のレイヤーに到来しただけだ。違いはリスクの大きさにある。侵害されたnpmパッケージは、開発者のマシン上でコードを実行できる。侵害されたスキルは、すでにあなたのメール、ファイル、チャット履歴にアクセスできるエージェントの内部で動作し、停止するよう伝えたと思った後も動き続けられる。