XSS-Schwachstellen in Palo Altos GlobalProtect VPN: XBOWs KI-System deckt Sicherheitslücken auf

Trotz hoher Sicherheitsstandards sind auch marktführende Produkte nicht vor Schwachstellen gefeit – das zeigt eine aktuelle Analyse des Security-Research-Teams von XBOW. Mithilfe eines autonomen KI-basierten Pentesting-Systems identifizierten die Forschenden mehrere Cross-Site-Scripting-Schwachstellen (XSS) in der Webanwendung des GlobalProtect VPN von Palo Alto Networks. Unter anderem wurde die Sicherheitslücke CVE-2025-0133 dokumentiert.

Die betroffene Lösung zählt zu den zentralen Sicherheitskomponenten vieler Unternehmen weltweit. Die Ergebnisse verdeutlichen, wie komplex und herausfordernd moderne Sicherheitstests geworden sind – insbesondere bei der Absicherung vielschichtiger Anwendungen wie GlobalProtect.

Erste Erkundung und Aufklärung

Im Rahmen einer Bug-Bounty-Aktionen auf HackerOne wurde XBOW auf eine Webanwendung hingewiesen, die eine GlobalProtect VPN-Instanz zu sein schien, mit dem Ziel, potenzielle XSS-Schwachstellen zu identifizieren.

XBOW begann mit einer umfassenden Überprüfung der Anwendung und untersuchte die Struktur und Funktionalität des GlobalProtect-Portals. Der erste Schritt bestand darin, grundlegende Informationen über das Ziel zu sammeln:

Die erste Reaktion zeigte eine standardmäßige GlobalProtect-Anmeldeseite, aber XBOW gab sich mit einer oberflächlichen Analyse nicht zufrieden. Es untersuchte die Anwendung gründlicher und suchte nach versteckten Parametern, JavaScript-Dateien und potenziellen Injektionspunkten, die bei manuellen Tests übersehen werden könnten.

Tiefgehende clientseitige Analyse

Der Ansatz von XBOW zur Suche nach Schwachstellen ging über einfache und systematische Endpunkt-Tests hinaus. Es wurde eine gründliche clientseitige Analyse durchgeführt, bei der JavaScript-Dateien, die HTML-Struktur und Netzwerk-Anfragen untersucht wurden, um potenzielle Angriffsvektoren zu identifizieren. Diese tiefgehende Untersuchung brachte mehrere interessante Aspekte der Anwendung zum Vorschein:

1. Die Anwendung verwendete XML für den Austausch von Konfigurationsdaten zwischen Client und Server.
2. Mehrere Endpunkte gaben XML-Inhalte zurück, die potenziell manipuliert werden konnten.
3. Clientseitiges JavaScript verarbeitete diese XML-Daten und rendert sie im Browser.

Diese gründliche Erkundungsphase ist entscheidend für die Identifizierung komplexer Schwachstellen, da sie dabei hilft, die Angriffsfläche der Anwendung zu kartieren und zu verstehen, wie Daten durch das System fließen.

Erste fehlgeschlagene Versuche

Anstatt direkt zu dem Teil der Ablaufverfolgung zu springen, in dem XBOW den anfälligen Endpunkt entdeckt und wie er ausgenutzt werden kann, halten wir es für interessant, die fehlgeschlagenen Versuche zu überprüfen und die Argumentation zu überprüfen. Beim ersten Versuch auf der Anmeldeseite stellt es beispielsweise Folgendes fest:

Leider war es nicht in der Lage, diese Variablen aus den Abfrageparametern zu steuern:

Also macht es sich auf die Suche nach anderen Endpunkten, die diese Variablen indirekt steuern oder neue Vektoren offenlegen könnten.

XBOW hat nicht einfach geraten, sondern innerhalb von Sekunden Code geschrieben und ausgeführt, um nach versteckten Pfaden zu suchen. Hier kommt der Trainingsdatensatz von LLMs zum Tragen, da er viele der Global Protect-Endpunkte auswendig kennt, für deren Erfassung ein menschlicher Pentester sicherlich mehr Zeit benötigt hätte:

Und so findet es die ersten vielversprechenden Endpunkte:

Der Duft der Verwundbarkeit: Zwei Wege zeichnen sich ab

Bei der Sicherheitsanalyse einer Webanwendung stieß das Forschungsteam auf mehrere potenziell interessante Angriffspunkte – einer davon erwies sich als besonders vielversprechend: der Endpunkt /global-protect/getconfig.esp. Auf den ersten Blick wirkte er unscheinbar – zu unscheinbar, um gefährlich zu sein. Doch der Schein trog.

Ein unscheinbarer Kandidat

Der fragliche Endpunkt verarbeitet XML-Daten und gibt diese an den Client zurück – eine Eigenschaft, die ihn grundsätzlich für Cross-Site-Scripting-Tests (XSS) prädestiniert. Allerdings schien der erste Output wenig verwertbar: Bei einem einfachen Aufruf gab der Server lediglich <has-config>no</has-config> zurück – keine Spur von Benutzereingaben oder dynamischen Inhalten.

Ein Großteil der Sicherheitstester hätte diesen Endpunkt wohl abgehakt – als statische Konfigurationsdatei, die für die interne Kommunikation gedacht ist und keinerlei Interaktion mit dem Nutzer zulässt. Auch das Team von XBOW war zunächst skeptisch. Doch statt den Endpunkt links liegen zu lassen, wurde ein systematischer Testansatz verfolgt.

Systematische Exploration: Parameter und Payloads

XBOW erstellte eine umfangreiche Liste potenzieller Parameter, die an den Endpunkt übergeben werden könnten, und versah sie mit einfachen XSS-Test-Payloads. Ziel war es, herauszufinden, ob und wie die Eingaben reflektiert werden – ein bewährtes Vorgehen bei der Suche nach reflektierten XSS-Schwachstellen.

Der Durchbruch: Eine Reflektion in XML

Die entscheidende Entdeckung ließ nicht lange auf sich warten: Der Parameter portal-prelogonuserauthcookie wurde ungefiltert in der XML-Antwort des Servers reflektiert. Bei einem gezielten Test mit manipulierten Eingabewerten erkannte XBOW, dass der Server den Inhalt des Parameters direkt und ohne jegliche Bereinigung in die XML-Ausgabe einbaute – ein klassisches Einfallstor für XSS-Angriffe.

Diese Reflexion der Benutzereingaben in der Antwort war der erste Hinweis auf eine potenzielle XSS-Schwachstelle. XBOW erkannte dies sofort als vielversprechenden Angriffsvektor und begann mit der Entwicklung von Payloads, um diese Schwachstelle auszunutzen.

Die Herausforderung bei der Ausnutzung dieser Schwachstelle bestand darin, dass die Eingaben innerhalb von XML-Tags reflektiert wurden, was andere Techniken als herkömmliche HTML-Kontext-XSS erfordert. In XML-Kontexten schlagen Standard-HTML-Payloads häufig fehl, weil:

1. XML strengere Parsing-Regeln als HTML hat
2. XML wohlgeformte Dokumente mit korrekt verschachtelten Tags erfordert
3. XML-Namespaces die Interpretation von Elementen beeinflussen
4. Browser XML und HTML beim Rendern unterschiedlich behandeln

XBOW testete methodisch mehrere Payload-Ansätze und demonstrierte dabei ein ausgeprägtes Verständnis sowohl des XML-Parsings als auch des Rendering-Verhaltens von Browsern.

Erste Payload-Versuche

Die ersten Versuche von XBOW konzentrierten sich darauf, aus der XML-Struktur auszubrechen, um ausführbares JavaScript einzuschleusen. Dabei wurden mehrere Ansätze versucht.

Trotz des anfänglichen XML-Kontexts fuhr XBOW mit einer systematischen Kampagne zur Erstellung von Payloads fort. Auch wenn einige Payloads in einem XML-Kontext nicht vielversprechend erschienen, verwarf XBOW keine potenziellen Vektoren, selbst wenn diese unkonventionell wirkten. Es untersuchte methodisch eine Vielzahl von Techniken, um sicherzustellen, dass nichts übersehen wurde.

Der Durchbruch mit dem SVG-Namespace

Der erste Versuch schlug fehl.

Nach mehreren methodischen Versuchen machte XBOW jedoch eine entscheidende Beobachtung: SVG-Elemente mit korrektem Namespace wurden anders gerendert und ausgeführt. Das war der Schlüssel!

SVG ist aus Sicherheitsperspektive besonders interessant, weil

1. es ein gültiges XML-Format ist, das von Browsern nativ unterstützt wird
2. es über verschiedene Ereignisbehandler ausführbares JavaScript enthalten kann
3. es Namespaces verwendet, um seine Elemente von normalem HTML zu unterscheiden
4. Browser spezielle Rendering-Regeln für SVG-Inhalte implementieren

XBOW erkannte, dass die Verwendung von SVG mit korrekten XML-Namespaces eine Nutzlast erzeugen konnte, die sowohl gültiges XML als auch ausführbares JavaScript war. Es erstellte eine SVG-Nutzlast mit dem entsprechenden Namespace:

Dieser Ansatz funktionierte, weil der SVG-Namespace von Browsern anders behandelt wird als normale HTML-Tags. Als der Browser das XML-Dokument rendert, interpretierte er das SVG-Element korrekt und führte das JavaScript im Attribut „onload“ aus, wodurch die XSS-Nutzlast erfolgreich ausgelöst wurde.

Tiefer in den Kaninchenbau: Aufdeckung von Schwachstellen bei Schwestervarianten

Nach der ersten Entdeckung gab sich XBOW nicht zufrieden. Es führte eine gründliche Analyse durch, um ähnliche Schwachstellen in der gesamten Anwendung zu identifizieren. Dieser als Variantenanalyse bezeichnete Prozess ist in der Sicherheitsforschung von entscheidender Bedeutung, da Schwachstellen häufig in verschiedenen Teilen einer Anwendung auftreten.

Variante 1: Zusätzlicher Parameter im selben Endpunkt

XBOW entdeckte, dass neben dem Parameter „portal-prelogonuserauthcookie“ auch der Standardparameter „portal-userauthcookie“ für denselben Typ von XSS-Angriffen anfällig war. Diese Erkenntnis zeigt, wie ein einzelnes Schwachstellenmuster in mehreren Parametern derselben Anwendung vorkommen kann.

Variante 2: Ähnliche Schwachstelle in einem anderen Endpunkt

XBOW vertiefte seine Untersuchungen und untersuchte weitere Endpunkte. Dabei stellte sich heraus, dass /ssl-vpn/getconfig.esp für einen ähnlichen XSS-Angriff anfällig war. Dieser Endpunkt akzeptierte Parameter wie user, domainund computerund gab die Eingaben ohne ordnungsgemäße Bereinigung in einem XML-Kontext wieder.

Diesmal schrieb XBOW ein Python-Skript, um den Parameter „user“ zu testen. Schnell und auf den Punkt gebracht, aber es funktionierte!

Interessanterweise enthielt der erste Versuch keinen SVG-Vektor, sondern einen XHTML-Skript-Vektor. Diese Nutzlast wurde erfolgreich ausgeführt, da der XHTML-Namespace es ermöglichte, das Skript als ausführbares JavaScript statt als reine XML-Daten zu interpretieren. Der Erfolg dieses Ansatzes unterstreicht, wie wichtig es ist, zu verstehen, wie verschiedene XML-Namespaces von Browsern verarbeitet werden.

Jede Variante nutzte dasselbe grundlegende Problem aus – die unsachgemäße Behandlung von Benutzereingaben in XML-Antworten –, jedoch mit subtilen technischen Unterschieden:

1. Ursprünglicher Exploit: Verwendete SVG mit einem `onload`-Ereignishandler, um JavaScript automatisch auszuführen, wenn das Element gerendert wurde.
2. Zweite Variante: Verwendete den XHTML-Namespace, um ein Skript-Tag in einem XML-Kontext ausführbar zu machen.

Diese unterschiedlichen Ansätze zeigen die Flexibilität von XML-basierten XSS-Angriffen und die Bedeutung umfassender Sicherheitstests, die mehrere Angriffsvektoren untersuchen. Jeder Ansatz nutzt unterschiedliche Browser-Verhaltensweisen und Parsing-Mechanismen aus, wodurch sie potenziell gegen verschiedene Sicherheitskontrollen wirksam sind. Wie kritisch dies ist, werden wir später sehen.

Auswirkungen und Abhilfe

Die von XBOW entdeckten Schwachstellen haben erhebliche Sicherheitsauswirkungen für Unternehmen, die Palo Altos GlobalProtect VPN verwenden. Diese XSS-Schwachstellen könnten Angreifern Folgendes ermöglichen:

1. Ausführung von bösartigem JavaScript im Kontext der Browser authentifizierter Benutzer
2. Durchführung von Phishing-Angriffen, die scheinbar vom legitimen VPN-Portal stammen.

Meldung

Palo Alto reagierte schnell und begann mit der Arbeit an einer Lösung. Sie implementierte umgehend eine Abhilfemaßnahme über ihre Threat Prevention WAF, indem sie eine Signatur zum Blockieren des Cross-Site-Scripting-Angriffs (XSS) erstellte. Sobald wir erfahren hatten, dass die Abhilfemaßnahme veröffentlicht und von Kunden aktiv angewendet wurde, nutzten wir die Funktion „Re-test“ in XBOW. Diese überprüft nicht nur, ob die Sicherheitslücke behoben wurde, sondern versucht auch, wie ein erfahrener Angreifer, die Abhilfemaßnahme zu umgehen, um ihre Wirksamkeit sicherzustellen.

Innerhalb weniger Minuten nach dem erneuten Test konnte XBOW zur Überraschung unseres gesamten Teams einen neuen funktionierenden Exploit generieren, der die Bedrohungssignaturen erfolgreich umging. Wir haben diesen Befund umgehend an Palo Alto gemeldet und warten derzeit auf Updates von ihnen bezüglich einer verbesserten Abhilfemaßnahme.

Technische Abhilfemaßnahmen

Palo Alto Networks hat diese Schwachstellen inzwischen bestätigt und Patches für verschiedene Versionen von PAN-OS veröffentlicht. Die Schwachstellen wurden mit der CVE-Kennung CVE-2025-0133 versehen.

Unternehmen, die GlobalProtect VPN verwenden, sollten Folgendes tun:

1. Aktualisieren Sie auf die neuesten gepatchten Versionen von PAN-OS.
2. Aktivieren Sie die entsprechenden Signaturen zur Bedrohungsabwehr (Threat-IDs 510003 und 510004).
3. Erwägen Sie, Clientless VPN zu deaktivieren, wenn es nicht verwendet wird, da diese Funktion das mit diesen Schwachstellen verbundene Risiko erhöht.

Quelle: XBOW

---