Schwachstelle in ServiceNow ermöglicht Übernahme von KI-Agenten

Authentifizierung ausgehebelt: Wie Angreifer ServiceNow-Systeme übernehmen konnten

Sicherheitsforscher von AppOmni haben eine Schwachstelle in ServiceNow entdeckt, die als schwerste KI-bezogene Sicherheitslücke gilt. Die unter CVE-2025-12420 registrierte Schwachstelle betrifft die Virtual Agent API und die Now Assist AI Agents-Anwendung. Angreifer konnten sich ohne jegliche Authentifizierung als beliebige Nutzer ausgeben und KI-Agenten mit weitreichenden Berechtigungen fernsteuern. Für den Angriff genügte die Kenntnis einer E-Mail-Adresse.

Aaron Costello, Leiter der Sicherheitsforschung bei AppOmni, demonstrierte in einem Proof-of-Concept, wie nicht authentifizierte Angreifer Administrator-Konten anlegen, Passwörter zurücksetzen und vollständigen Systemzugriff erlangen konnten. Die Schwachstelle ermöglichte die Umgehung von Multi-Faktor-Authentifizierung und Single Sign-On.

Abb. 1: Die BodySnatcher-Exploit-Kette auf hoher Ebene. Grafik Quelle: AppOmni

Betroffene Versionen und Patches

ServiceNow-Instanzen mit folgenden Anwendungsversionen waren anfällig:

Now Assist AI Agents (sn_aia)

• Betroffene Versionen: 5.0.24 bis 5.1.17 sowie 5.2.0 bis 5.2.18
• Gepatchte Versionen: 5.1.18 und 5.2.19

Virtual Agent API (sn_va_as_service)

• Betroffene Versionen: bis einschließlich 3.15.1 sowie 4.0.0 bis 4.0.3
• Gepatchte Versionen: 3.15.2 und 4.0.4

Administratoren müssen ihre Systeme umgehend auf die korrigierten Versionen aktualisieren.

Technische Grundlagen der Schwachstelle

Die Sicherheitslücke resultiert aus dem Zusammenspiel mehrerer Komponenten. ServiceNow nutzt Virtual Agent als Chatbot-Engine für dialogorientierte Interaktionen. Die Virtual Agent API ermöglicht externe Integrationen über Provider und Kanäle, wodurch Dienste wie Slack oder Microsoft Teams angebunden werden können.

Die Authentifizierung erfolgt über Message Auth, eine statische Anmeldeinformation, die als Client-Geheimnis fungiert. Die Auto-Linking-Funktion verknüpft externe Nutzer automatisch mit ServiceNow-Konten. Diese Mechanismen sollten eine nahtlose Integration ermöglichen, wiesen jedoch fundamentale Sicherheitsmängel auf.

Gemeinsame Anmeldedaten als Schwachstelle

Mit der Einführung der Now Assist AI Agents-Anwendung führte ServiceNow neue Provider ein, um Agent-zu-Agent-Kommunikation zu unterstützen. Diese KI-Agent-Provider teilten problematische Konfigurationen:

Erstens verwendeten alle ServiceNow-Instanzen denselben statischen Schlüssel. Jeder mit Kenntnis dieses Tokens konnte mit der Virtual Agent API beliebiger Kundenumgebungen kommunizieren. Der Token allein gewährte zwar keine erweiterten Rechte, stellte aber eine universelle Umgehung der Authentifizierung dar.

Zweitens vertraute die Auto-Linking-Logik jedem Anforderer mit dem gemeinsamen Token. Es erfolgte keine Multi-Faktor-Authentifizierung. Lediglich eine E-Mail-Adresse war erforderlich, um eine Verbindung zu einem ServiceNow-Konto herzustellen. Nach erfolgreicher Verknüpfung liefen alle Aktionen unter der Identität des betroffenen Kontos.

Isoliert betrachtet blieb das Risiko überschaubar. Angreifer konnten Nachrichten als vertrauenswürdige Nutzer versenden, was ein Phishing-Risiko darstellte. Die asynchrone Kommunikation verhinderte jedoch, dass Antworten beim Angreifer ankamen, was die praktischen Auswirkungen begrenzte.

Agent-zu-Agent-Protokoll als Einfallstor

Die eigentliche Schwere der Schwachstelle ergab sich aus der Implementierung des Agent-zu-Agent-Protokolls. Die A2A Scripted REST API formatiert eingehende Daten in die Struktur der Virtual Agent API um und fügt sie in die Warteschlange des Virtual Agent-Servers ein.

Die API fungiert als Adapter und ermöglicht externen KI-Agenten die standardisierte Kommunikation mit ServiceNow-Agenten. Obwohl die API authentifizierungspflichtig ist, konnte ihre Funktionalität über die Virtual Agent API erreicht werden, die keine solche Anforderung stellte.

Grafik Quelle: AppOmni

Verstecktes Thema AIA-Agent Invoker AutoChat

Durch Analyse geschützter Skript-Konstanten identifizierte Costello das Thema AIA-Agent Invoker AutoChat. Dieses Thema dient der Ausführung von KI-Agenten über Virtual Agent. Die Entdeckung widerlegte die Annahme, dass KI-Agenten nur auf explizit aktivierten Kanälen laufen.

Das Thema ließ sich nicht über den Virtual Agent Designer öffnen. Stattdessen nutzte Costello Hintergrundskripte, um auf die Konstanten zuzugreifen und die Logik zu entschlüsseln. Die Analyse zeigte: Aktive Agenten mit entsprechenden Berechtigungen können direkt über dieses Thema ausgeführt werden.

Exploit-Kette: Von der Ausgabe bis zur Systemkontrolle

Der vollständige Exploit erforderte vier Voraussetzungen:

1. Öffentlich zugängliche API: Die Virtual Agent API erfüllte diese Anforderung, da sie keine Authentifizierung auf API-Ebene voraussetzte.
2. KI-Agent-Kennung: ServiceNow lieferte mit der Installation Beispiel-Agenten aus. Der Record Management AI Agent verfügte über ein Tool zum Erstellen von Datensätzen in beliebigen Tabellen. Nach der Meldung entfernte ServiceNow diesen Agenten, doch hatte er bis dahin in allen Instanzen dieselbe Kennung.
3. Privilegierte Rollen-ID: Standardrollen wie „admin“ existieren in jeder ServiceNow-Instanz mit identischer Kennung.
4. Benutzer-ID: Durch Kombination von Anfragen zum Erstellen eines Nutzers und Zuweisen einer Rolle in einer Payload erkannte der KI-Agent selbst die ID des neu erstellten Kontos.

Der Angriff erfolgte in mehreren Schritten. Zunächst sendete der Angreifer eine HTTP-Anfrage über die Virtual Agent API, die den KI-Agenten aufforderte, einen neuen Benutzer mit Administratorrechten anzulegen. Der Agent im Supervised-Modus bat um Bestätigung. Nach acht bis zehn Sekunden Wartezeit sendete der Angreifer eine Bestätigungsnachricht.

Der KI-Agent erstellte daraufhin den Benutzerdatensatz und wies die Administratorrolle zu. Nach Abschluss konnte der Angreifer über den Standardprozess „Passwort vergessen“ das Passwort zurücksetzen und sich mit vollständigen Administratorrechten anmelden.

Weitreichende Möglichkeiten über den Proof-of-Concept hinaus

Der demonstrierte Exploit zeigt nur eine mögliche Angriffsform. SSO-basierte Authentifizierung als Schutzmaßnahme ließe sich umgehen, indem der Agent angewiesen wird, direkte Anmeldungen zu aktivieren. Angreifer müssten nicht einmal Konten erstellen, sondern könnten den Agenten veranlassen, nicht authentifizierte API-Endpunkte für CRUD-Operationen auf beliebigen Systemressourcen einzurichten.

ServiceNow reagierte mit der Rotation der Provider-Anmeldedaten und der Entfernung des leistungsstarken KI-Agenten. Diese Maßnahmen stellen jedoch punktuelle Korrekturen dar. Die grundlegenden Konfigurationsprobleme könnten in benutzerdefiniertem Code oder Drittanbieterlösungen weiterhin vorhanden sein.

Empfohlene Schutzmaßnahmen

Multi-Faktor-Authentifizierung bei Kontoverknüpfung

MFA muss standardmäßig im Kontoverknüpfungsprozess erforderlich sein. ServiceNow bietet diese Möglichkeit pro Provider. Sicherheitsteams sollten softwarebasierte Authentifikatoren gegenüber SMS priorisieren. Die Aktivierung von MFA erfordert mehr als das Ändern einer Einstellung – das Skript „Automatic link action“ muss die entsprechende Validierungslogik enthalten.

Genehmigungsprozess für KI-Agenten

Obwohl ServiceNow den Record Management AI Agent entfernt hat, können Nutzer weiterhin leistungsfähige benutzerdefinierte Agenten erstellen. Die Anwendung AI Control Tower ermöglicht die Konfiguration automatischer Genehmigungsprozesse vor der Produktionsbereitstellung.

Nutzer mit der Rolle „AI Steward“ können im Anwendungsnavigator unter „AI Control Tower > Konfigurationen > Kontrollen > Genehmigungen“ die Optionen „AI Steward-Genehmigung erforderlich“ und „Playbooks automatisch auslösen“ aktivieren.

Lebenszyklusmanagement für Agenten

Regelmäßige Audits identifizieren inaktive Agenten. Der AI Control Tower markiert Agenten als „ruhend“, die seit über 90 Tagen nicht verwendet wurden. Im Bereich „Sicherheit und Datenschutz“ unter „Ruhende KI-Systeme“ erhalten Administratoren eine Übersicht aller markierten Agenten zur Überprüfung und Deaktivierung.

KI-Agenten als kritische Infrastruktur

Die Schwachstelle BodySnatcher erweitert frühere Forschungen von Costello zum Agent-to-Agent-Erkennungsmechanismus, bei denen KI-Agenten andere Agenten für böswillige Aufgaben rekrutieren konnten. Die Erkenntnisse zeigen einen Trend: Mit steigender Leistungsfähigkeit von KI-Agenten wächst das Sicherheitsrisiko proportional.

AppOmni hat mit AgentGuard for ServiceNow eine Lösung entwickelt, die Injektionsangriffe in Echtzeit blockiert, KI-DLP-Verstöße verhindert und Verhaltensabweichungen erkennt. Die AISPM-Funktionen überwachen kontinuierlich die Sicherheitskonfiguration der ServiceNow-KI-Agenten.

Fast die Hälfte der Fortune-100-Kunden von AppOmni nutzt die Now Assist- und Virtual Agent-Anwendungen von ServiceNow, was das Ausmaß des Risikos verdeutlicht. Die Verschmelzung von SaaS-Sicherheit und KI-Sicherheit erfordert neue Ansätze im Umgang mit Plattformsicherheit.

„Die in diesem Beitrag bereitgestellten Informationen wurden sorgfältig recherchiert, erheben jedoch keinen Anspruch auf Vollständigkeit oder absolute Richtigkeit. Sie dienen ausschließlich der allgemeinen Orientierung und ersetzen keine professionelle Beratung. Die Redaktion übernimmt keine Haftung für eventuelle Fehler, Auslassungen oder Folgen, die aus der Nutzung der Informationen entstehen.“

Auch spannend:

---