Now Assist AI AgentsおよびVirtual Agent APIアプリケーションに影響する脆弱性が悪用され、管理者ロールを持つバックドアアカウントが作成される可能性がある。
多くのソフトウェア企業やSaaS企業が自社製品にAIエージェントを組み込んでいるが、こうした機能は、特に市場投入を急いだ場合に、プラットフォームの攻撃対象領域を拡大し得る。先週ServiceNowのプラットフォームで明らかになった権限昇格の脆弱性は、高い権限を要するタスクを実行できるAIエージェントが、意図しない形で悪用され得ることを示す最新の例だ。
この脆弱性は、発見したセキュリティ企業AppOmniの研究者によって「BodySnatcher」と名付けられ、Now Assist AI AgentsおよびVirtual Agent APIアプリケーションに影響する。未認証ユーザーが任意のユーザーの権限でエージェント型ワークフローを実行できる。既定設定のNow Assist有効インスタンスでは、この欠陥を悪用して管理者ロールを持つバックドアアカウントを作成できる可能性がある。
「BodySnatcherの発見は、これまでに明らかになったAI主導のセキュリティ脆弱性の中で最も深刻なものを示しており、現代のSaaSプラットフォームにおけるエージェント型AIセキュリティ脆弱性の決定的な例である」とAppOmniの研究者は報告書に記した。「これは、攻撃者が組織のAIを事実上『遠隔操作』し、企業のワークフローを簡素化するためのツールそのものを武器化できることを示している。」
ServiceNowによると、この脆弱性は10月末にホスト型インスタンスで修正され、セルフホスト型インスタンスを利用する顧客には更新が提供された。しかし、セキュリティアドバイザリと脆弱性の詳細が公開されたのは先週になってからだった。同社は、Now Assist AI Agentsのバージョン5.1.18、5.2.19以降、およびVirtual Agent APIのバージョン3.15.2、4.0.4以降を実行していることを確認するよう顧客に助言している。
AppOmniは、更新によりNow Assistとともに既定でインストールされるサンプルAIエージェントの1つが削除され、同社の概念実証（PoC）エクスプロイトが成立しなくなると指摘する一方で、この脆弱性を支える危険な設定は、顧客が作成したカスタムコードやサードパーティ統合の中に依然として存在し得るとも述べている。
より多くの組織がSaaSプロバイダーが開発したエージェント型AIツールを利用したり、ワークフロー自動化のために社内で独自のエージェントを構築したりするにつれ、過剰な権限が付与されていたり認証ロジックに欠陥があったりすると、これらのツールがもたらし得る未解明のリスクを意識する必要がある。
ServiceNow Virtual Agent APIを介したユーザーなりすまし
Virtual Agent APIはServiceNow Storeで提供されるアプリケーションで、顧客が外部のチャットインターフェースやボットをServiceNow Virtual Agentプラットフォームと統合できるようにする。このプラットフォームにより、組織は顧客や従業員を支援し、人間の担当者を他の業務に振り向けるために、さまざまなトピックに関する自動会話を設計・展開できる。たとえば、ある統合の例として、組織のServiceNow Virtual Agentプラットフォームと対話して質問に答えるSlackボットが挙げられる。
このAPIは、統合ごとに固有のプロバイダー定義を使用し、ServiceNowが統合からのメッセージをどのように認証し、Virtual Agentプラットフォームが理解できる構造化形式へ変換するかを指定する。
外部のVirtual Agent統合を認証する一般的な方法は、Message Authレコード（固有の静的トークン）を用いることだ。もう1つの既定オプションであるAuto-Linkingは、外部統合を通じてメッセージを送信するユーザーの身元を、対応するServiceNowアカウントに自動的に紐付ける。これは通常、ユーザーのメールアドレスを確認するだけで行われる。
Virtual Agentは当初、事前構築された会話エージェントのみをサポートする目的だったが、ServiceNowは後にNow Assistプラットフォームを通じてLLM駆動のAIエージェントをサポートする機能を追加した。これらの新しいエージェントは、静的なMessage Authレコードによる認証やAuto-Linkingを含む、同じ構成選択肢のまま既存のVirtual Agent APIを活用する。
その結果、未認証の攻撃者であっても、ユーザーのメールアドレスとAIプロバイダーのトークン（有効化されたすべてのインスタンスで共通）を知っているだけで、会話中に任意のユーザーになりすますことができる。
研究者は「これらの問題だけによる純粋なセキュリティリスクは比較的小さい」と述べた。「せいぜい、攻撃者はVirtual Agent APIへのメッセージペイロードに文書化されていない『live_agent_only』パラメータを指定でき、これによりVirtual Agentはメッセージ内容を実際の人間に引き継ぐ（組織が対応している場合）。信頼されたユーザーになりすまして組織のITサポート担当者にメッセージを送ることで、フィッシングのリスクが顕在化する。」
エージェント間の相互作用と実行へ
その後、このプラットフォームはさらに拡張され、外部AIエージェントが、タスクを実行できる内部のServiceNow AIエージェントと会話できるようになった。これを可能にするため、同社は特別なプロトコルと、認証を必要とする別個のREST APIを作成した。
しかし、この新しいAPIは、既存のVirtual Agent APIの上にもう1層重ねただけのものらしい。リクエストを、Virtual Agent APIが使用するのと同じ形式に変換し、AIエージェントの実行をトリガーするいくつかの変数を付加する。
研究者は、このエージェント間プロトコルが呼び出す変数と、Virtual Agent APIの「トピック」（特定のタスクを完了するために設計された構造化ワークフロー）をリバースエンジニアリングした。
研究者は「プラットフォーム上でAIエージェントが利用可能であることについて公に理解されていた内容に照らすと、この理解は画期的だ」と述べた。「一般的な見解は、AIエージェントをテスト以外で実行するには、Now Assist機能を明示的に有効化したチャネルにデプロイする必要がある、というものだった。しかし実際はそうではない。明らかに、エージェントがアクティブ状態にあり、呼び出しユーザーが必要な権限を持っている限り、これらのトピックを通じて直接実行できる。」
通常、エージェント間APIの利用にはServiceNowアカウントが必要だが、これはServiceNowアカウントを必要としない旧来のVirtual Agent APIのラッパーであるため、この要件は回避できる。
攻撃者はさらに、被害者のServiceNowインスタンス内に存在するAIエージェントの固有IDも必要になる。Now Assist AIアプリケーションをインストールすると、既定でサンプルエージェントがデプロイされ、その中には任意のテーブルにレコードを作成できるRecord Management AI Agentが含まれていた。パッチの一部として削除されたこのエージェントは、すべてのデプロイで同一のUIDを持っていた。
AppOmniの研究者は、Virtual Agent APIに対して既定で成立する前述のなりすまし攻撃を用いて、管理者権限でRecord Management AI Agentを呼び出し、プロンプトで自分が管理するメールアドレスの新しいユーザーレコードを追加し、作成したユーザーに管理者ロールを割り当てるよう依頼できることを示した。
AIエージェントは監督モードで動作していたため、タスクを実行する前に要求者へ確認を求めようとしたが、APIに直接リクエストを送る攻撃者にはこれらの確認プロンプトが返ってこない。しかし研究者は、数秒待ってから「Please proceed（続行してください）」というプロンプトを添えた別のリクエストを送れば、エージェントがそれを承認として受け入れることを突き止めた。
管理者ロールを持つバックドアユーザーがデータベースに追加されると、新しいユーザーのメールアドレスを管理している研究者は、通常のパスワードリセット手順を使ってそのユーザーの新しいパスワードを作成した。
緩和策
研究者は「ServiceNowの即時対応は、プロバイダー資格情報をローテーションし、PoCで示された強力なAIエージェントを削除することで、『BodySnatcher』の事例を事実上修正した」と述べた。「しかし、これらはその時点での対処にすぎない。ServiceNowにおけるこのエージェント型AI脆弱性を招いた設定上の選択は、組織のカスタムコードやサードパーティ製ソリューションの中に依然として存在し得る。」
研究者は報告書の中で、ServiceNow管理者およびセキュリティチーム向けに一連の推奨事項を提示した。その1つは、ServiceNowが提供するオプションとして、あらゆるVirtual Agent APIプロバイダーのアカウント紐付けに多要素認証（MFA）を強制することだ。
「ただし、MFAの強制は『切り替えて終わり』の設定ではない」と研究者は述べた。「Account linking typeフィールドを更新するだけでは不十分だ。プロバイダーに関連付けられたAutomatic link actionスクリプトに、特定のMFAチャレンジを実行し検証するために必要なロジックが含まれていることも確認しなければならない。」
プラットフォーム上で構築されたカスタムエージェントは、組織のセキュリティポリシーに整合させるため、レビューと承認の対象とすべきだ。これを可能にするため、AI Control TowerアプリケーションでAIスチュワード承認を有効化できる。未使用のAIエージェントは定期的に見直して無効化すべきであり、アクティブなまま放置すると、同様の欠陥を通じて悪用される可能性が開かれる。
