セキュリティ研究者らは、AIコーディングエージェントが操作される可能性があることを示しました。企業自身のllms.txtファイルに記載された指示に従わせることで、攻撃者が制御するパッケージをインストールさせられるというものです。
Databreach prevention
この研究は、AIエージェントが読み取るドキュメントが、未検証のパッケージ参照や期限切れドメイン、放棄されたクラウドサブドメインを、企業環境内での実行経路へと変えてしまう危険性を浮き彫りにしています。
研究者、フォーチュン500企業内でコード実行に成功
問題の中心にあるのは、llms.txtおよびllms-full.txtファイルです。これは大規模言語モデル(LLM)エージェントに対し、企業の製品、ドキュメント、API、ソフトウェア開発キット、インストール手順などについて構造化されたガイダンスを提供するための、近年広まりつつある規約です。
主に人間の読者を想定した従来のWebページとは異なり、これらのファイルには`pip install`や`npm install`、`npx`といったコマンド、APIエンドポイント、パッケージ名、関連リソースへのリンクなど、直接的な操作指示が含まれることがあります。
自律型のコーディングエージェントが開発タスクの遂行中にこのファイルを取得した場合、ベンダーの公式HTTPSドメインから取得したものであるという理由だけで、その指示を信頼できるものとして扱ってしまう可能性があります。
研究者らは、約15,000社の組織カタログから抽出した、6,214件のアクティブなドメインにまたがる8,565件のllms.txtファイルを分析しました。このデータセットには、フォーチュン500企業や大手テクノロジー企業、フィンテック事業者、防衛関連企業が含まれていました。
調査の過程で、研究者らはAIエージェント向けの指示の中に、未登録のアーティファクトが237件以上参照されていることを確認しました。
これらのアーティファクトには、PyPI、npm、RubyGems、NuGet、crates.io、Packagistのパッケージ名のほか、期限切れドメインや、Vercel、Render、Fly、Netlifyといったプラットフォーム上の未登録デプロイメントが含まれていました。
この問題は一般的なタイポスクワッティングとは性質が異なります。今回のケースでは、パッケージ名やデプロイ先の名称は公式ドキュメント上で正しく綴られていたものの、それを参照していた組織自身がそのパッケージや名称を登録・保有したことは一度もありませんでした。
リスクを検証するため、研究者らは未登録のパッケージ名を限定的にいくつか登録し、無害なコールバックビーコンを組み込みました。
その結果、フォーチュン500企業の環境から最初のインストールコールバックを受信するまでに要した時間は4分未満で、さらにもう1件のコールバックも1時間以内に届いたと報告しています。開示された情報によれば、これらのパッケージは永続化機構の展開や機密データの収集は行っていません。
Datarecovery services
これらの調査結果は、AIエージェントがフィッシングの誘導や脆弱性の悪用、攻撃者による直接的な関与を一切必要とせず、ベンダーのドキュメントを自律的に発見し、llms.txtファイルを特定し、インストールコマンドを見つけ出し、攻撃者が制御するパッケージを取得し得ることを示しています。
研究者らはまた、Clerkのドキュメントに関わる実例も確認しています。ClerkのAIエージェント向けガイダンスは、ユーザーに対して`npx clerk-next-fix-auth-protection`というコマンドの実行を指示していました。これは同社の`@clerk/eslint-plugin`パッケージの機能に関連付けられたコマンドです。
しかし、該当パッケージがローカルにインストールされていない場合、`npx`は公開npmレジストリを通じて、この裸のコマンド名を解決しようと試みることがあります。
研究者のAlonHertz1氏によれば、Clerkはこの名称で単独のパッケージを公開していなかったため、第三者による登録が可能な状態になっていたということです。
この名称を使った悪意あるパッケージが登録され、MAL-2026-11069として追跡されています。研究者らによると、このパッケージはインストールフックを実行し、インストールを行ったユーザーのユーザー名、ホスト名、作業ディレクトリ、タイムスタンプを外部サーバーに送信していたとされています。Clerkにはこの件が通知され、同社は迅速に対応したとのことです。
従来のエンドポイント制御では、この種の活動を検知するのが難しい場合があります。実行の流れが一般的な開発者の挙動とよく似ているためです。承認済みのAIコーディングツールが標準的なパッケージマネージャーを呼び出し、そのマネージャーがPyPIやnpmといった信頼済みレジストリに接続するという、ごく通常の流れに見えてしまいます。
重大な失敗は、エンドポイントのテレメトリが役に立つ段階に至る前に発生します。エージェントは、ファーストパーティのドキュメントを信頼できるものとして受け入れる一方で、参照先のパッケージや名前空間、ドメイン、クラウドデプロイメントが実際にそのベンダーの管理下にあるかどうかを、必ずしも検証しているわけではないのです。
この研究は、AIエージェントに関するより広範なセキュリティ上の懸念を浮き彫りにしています。それは、エージェントが取り込むコンテンツが、実行可能な操作入力としての役割をますます強めているという点です。
Databreach prevention
AIが読み取り可能なドキュメントを公開する組織は、参照されるすべてのアーティファクトを洗い出し、パッケージ名やドメイン名を確保し、コマンド例を検証したうえで、放棄されたり乗っ取られたりした依存関係がないか継続的に監視すべきです。
調査の遅れによるインシデントを未然に防ぎましょう。15,000のSOCから得られる脅威インテリジェンスで、貴社のTier 1を強化します: TI Lookupを貴社のSOCに統合する
翻訳元: https://gbhackers.com/researchers-execute-code-inside-fortune-500-companies/
