Einführung

Die gegnerische Denkweise ist eine unverzichtbare Eigenschaft für offensive Operatoren in einem roten Team. Jede Beurteilung bringt ihre eigenen Einschränkungen und „Trophäen“ mit sich. Die Betreiber müssen sich an die Einschränkungen der Umgebung anpassen, wie z. B. sichere Tiering-Modelle, modernste Lösungen zur Endpunkterkennung und -reaktion usw. Durch die Fähigkeit, diese sogenannten „Hindernisse“ anzupassen und zu bewältigen, können die Teammitglieder optimal arbeiten und arbeiten Die kreativsten Wege, die möglich sind, um die Kontrolle über kritische Anlagen und Umgebungen zu erlangen.

In einer aktuellen Beurteilung begann es, wie bei jedem anderen Einsatz des Roten Teams, mit der Aufklärungsphase. In dieser Phase sammeln wir mit dem Internet verbundene Assets, die mit der Organisation des Kunden verknüpft sind. Nach dem Sammeln und Analysieren der Aufklärungsdaten stellten wir fest, dass die Angriffsfläche recht schmal war, es keine ausnutzbaren Versionen internetbasierter Software gab und Social Engineering als letztes Mittel reserviert war. Einige der von uns gefundenen Assets wurden als GlobalProtect VPN-Portale identifiziert. Nach mehreren Verbindungs- und Authentifizierungsversuchen wurde festgestellt, dass die Authentifizierung beim GlobalProtect-Portal mit einer Multi-Faktor-Authentifizierung erzwungen wurde. Da dies unsere einzige Möglichkeit war, im internen Umfeld der Organisation Fuß zu fassen, entschieden wir uns, die GlobalProtect-Schnittstellen weiter zu untersuchen.

GlobalProtect VPN-Grundlagen

GlobalProtect VPN von Palo Alto basiert auf HTTPS-Anfragen und -Antworten sowie XML-Konfigurationsdatensätzen. Das VPN besteht aus zwei Hauptkomponenten, die vom Endbenutzer genutzt werden: dem Portal und dem Gateway . Die Aufgabe des Portals besteht darin, zunächst als Webserver zu fungieren, der den GlobalProtect-Client für Windows und MacOS hostet. Zweitens stellt es die offiziellen Client-Konfigurationen von Palo Alto und die Liste der verfügbaren Gateways bereit. Der Zweck des Gateways besteht darin, den rohen SSLVPN-Tunnel bereitzustellen, den wir kennen und lieben, um die Endbenutzersitzung im Unternehmen zu sichern.

Der offizielle Kundenablauf von Palo Alto ist:

1. Melden Sie sich beim Portal an
2. Rufen Sie eine Konfiguration und eine Liste der Gateways ab
3. Das Gateway wird automatisch oder durch die manuelle Auswahl des Benutzers ausgewählt
4. Melden Sie sich am Gateway an
5. Stellen Sie einen HIP-Bericht (Host Information Profile) bereit
6. Wenn alles funktioniert, stellen Sie eine VPN-Verbindung her und sichern Sie die Sitzung

TL;DR Es scheint, dass die Durchsetzung von MFA sowohl im Portal als auch im Gateway von entscheidender Bedeutung ist, da es sich um unabhängige Komponenten handelt .

Eintauchen in den Authentifizierungsfluss

Wenn wir uns zum ersten Mal mit dem offiziellen GlobalProtect-Client verbinden, sehen wir, dass die erste POST-Anfrage an das Portal gesendet wird, dessen URL darauf verweist/global-protect/prelogin.esp

An die Anfragen werden die Umgebungsvariablen des Clients angehängt, wie zum Beispiel: „kerberos-support“, „client-os“, „os-version“, „ipv6-support“ usw.

Der Server antwortet dann mit einem „PHPSESSID“-Cookie und einem XML-Datensatz mit dem Status der Anfrage und fügt im Erfolgsfall auch die Login-Labels für den Client hinzu, wie zum Beispiel: „MFA-Token eingeben“ oder „Eingeben“. Passwort."

Nachdem der Benutzer Anmeldeinformationen eingegeben hat, sendet der Client die nächste Anfrage an /global-protect/getconfig.espund sendet dabei dieselben Informationen wie bei der vorherigen Anfrage mit den angehängten Anmeldeinformationen.

Wenn die Authentifizierung erfolgreich ist, sendet der Server einen XML-Datensatz, der Folgendes enthält: die Serverkonfiguration, die Version, die zu erfassenden Hostinformationen des Clients und, sofern vorhanden, durchzuführende benutzerdefinierte Prüfungen. Benutzerdefinierte Prüfungen sind spezielle Konformitätsprüfungen, die von den VPN-Administratoren erstellt werden, beispielsweise spezielle Registrierungsschlüssel, die der Computer festlegen muss, um konform zu sein. In der Antwort ist auch die Liste der Gateways und ihrer Konfigurationen enthalten.

Die nächste Anfrage richtet sich an das Gateway und verwendet dieselbe Authentifizierungssequenz wie beim Start des Portals, diesmal jedoch an den Endpunkt des Gateways: /ssl-vpn/prelogin.esp.

Die Phase vor der Anmeldung ist dieselbe wie beim Portal und sendet die Umgebungsvariablen des Clients an den Server. Der Server antwortet mit einem Status, den Beschriftungen des Authentifizierungsformulars und setzt ein „PHPSESSID“-Cookie.

Nach dem Erhalt einer Sitzungs-ID und der Authentifizierung erfolgt die nächste Anfrage, die zwischen der Portal- und der Gateway-Authentifizierung unterscheidet. Die Anfrage wird an gesendet /ssl-vpn/login.esp, mit den Anmeldeinformationen des Benutzers angehängt, und als Antwort sendet der Server mehrere unbenannte Argumente, die wie folgt aussehen: MTU, DNS-Domäne, das „Authcookie“, das in der nächsten Anfrage verwendet wird, und weitere Konfigurationsvariablen.

Der Client analysiert dann den XML-Datensatz korrekt und hängt diese Variablen, einschließlich des „Authcookie“, an seine nächste Anfrage an an /ssl-vpn/getconfig.esp. Der Server antwortet mit einem Antwortstatus und weiteren Konfigurationsvariablen, aber dieses Mal sind diese alle betitelt und es werden mehr Variablen gesendet, wie z. B. zu verwendende Chiffren, Protokolle des Gateways, bevorzugte zu verwendende Tunnel-IP usw.

Die letzte Phase ist eine GET-Anfrage an /ssl-tunnel-connect.sslvpn, an die der Benutzername und „authcookie“ angehängt werden. Dadurch wird die VPN-Sitzung mit der Serverantwort „ START_TUNNEL“ initiiert.

Nur noch eine Fehlkonfiguration von der Umgehung von MFA entfernt

Wie wir im vorherigen Kapitel gesehen haben, basiert die VPN-Sequenz auf zwei unabhängigen Komponenten, die zwei separate Authentifizierungsflüsse erfordern.
Da diese unabhängig voneinander sind, könnte jede der Authentifizierungssequenzen manuell aktiviert werden. Das heißt, wenn wir die Informationen des Gateways bereits kennen, ist es nicht nötig, das Portal zu durchlaufen, um eine Liste der Gateways zu erhalten. Wir könnten uns nur einmal mit gültigen Anmeldeinformationen authentifizieren und trotzdem eine VPN-Verbindung herstellen.

Bei dieser aktuellen Bewertung haben wir festgestellt, dass ein MFA-Token nur vom Portal angefordert wird , während das Gateway nach Domänenanmeldeinformationen fragt. Die IT-Abteilung und die Palo Alto GlobalProtect-Entwickler verließen sich ausschließlich auf die interne Nutzung durch den Kunden und hatten keine externen Anpassungen im Sinn. Während es sicher ist, MFA am Gateway nicht zu erzwingen, wenn Sie den offiziellen Client verwenden, ist es nicht sicher, wenn Sie andere Open-Source- oder selbst erstellte Clients verwenden. An dieser Stelle ist es auch wichtig zu erwähnen, dass die Ursache lediglich eine Fehlkonfiguration und keine Schwachstelle in der VPN-Lösung von Palo Alto ist.

Glücklicherweise haben die Jungs von InfraDead bereits ihre Recherchen zu GlobalProtect durchgeführt, als sie den Open-Source-VPN-Client OpenConnect entwickelten , der mehrere VPN-Anbieter und -Technologien unterstützt, darunter Palo Alto GlobalProtect . In ihrer Dokumentation führen sie aus:

„GlobalProtect VPNs enthalten tatsächlich zwei verschiedene Serverschnittstellen: Portale und Gateways. Die meisten VPNs verfügen über einen Portalserver und einen oder mehrere Gatewayserver. Der Server, der die Portalschnittstelle hostet, hostet häufig auch eine Gateway-Schnittstelle , jedoch nicht immer. Die Portalschnittstelle sendet meist zentral vorgegebene Sicherheits-/Sperreinstellungen, damit die offizielle Client-Software diese befolgen kann. Die einzigen vom Portal gesendeten Informationen, die für einen VPN-Client wie OpenConnect (der versucht, dem Endbenutzer die volle Kontrolle zu geben) eindeutig nützlich sind, ist die Liste der Gateways .

Einige GlobalProtect-VPNs sind so konfiguriert, dass sich der Client beim Portal authentifizieren muss, bevor er auf das Gateway zugreifen kann, während bei anderen VPNs keine Interaktion mit dem Portal notwendig ist . Um das Verhalten der offiziellen Clients nachzubilden, versucht OpenConnect zunächst, eine Verbindung zur Portalschnittstelle des angegebenen Servers herzustellen.

Wenn --usergroup=gatewayangegeben (oder entsprechend /gatewayan die Server-URL angehängt wird, z. B. https://vpn.company.com/gateway), versucht OpenConnect, die Portalschnittstelle zu überspringen und sofort eine Verbindung zur Gateway-Schnittstelle herzustellen . Dies ist nützlich, wenn das GlobalProtect VPN-Portal falsch konfiguriert ist, beispielsweise weil der gewünschte Gateway-Server nicht in der bereitgestellten Liste aufgeführt ist.“

Es war magisch, diese OpenConnect-Funktion zu finden, da sie uns teure Recherche- und Programmierzeit ersparte.

Hier sind keine Portale erforderlich ...

Da das Portal und das Gateway auf derselben Schnittstelle ausgeführt wurden, war es nicht erforderlich, andere Gateways zu finden (z. B. andere Ports auf demselben Server oder andere externe Ressourcen).

Wir haben den OpenConnect-Client verwendet, um das Portal zu umgehen und zuerst eine Verbindung zum Gateway herzustellen:
openconnect --protocol=gp --user=user_name https://vpn.company.com/gateway

Der Endpunkt ist wahrscheinlich nicht auf dem Server vorhanden, wird jedoch verworfen, während der Client ausgeführt wird, und dient nur als Flag, sodass er mit der Kommunikation des Endpunkts und nicht dieser Endpunkte /gatewaybeginnt ./ssl-vpn//global-protect/

Der VPN-Client fordert uns zur Eingabe der Domänenanmeldeinformationen auf:

Erfolg! Wir sind erfolgreich mit dem internen Netzwerk verbunden!

Obwohl es in dieser Bewertung möglich war, eine Verbindung zu den Domänencontrollern der Organisation herzustellen und mit ihnen zu kommunizieren, konnten wir nicht mit vielen Diensten und Domänencomputern kommunizieren, wie dies über den offiziellen Client möglich war. Nachdem wir das unterschiedliche Verhalten zwischen verschiedenen Betriebssystemen und Clients untersucht hatten, stellten wir fest, dass ein gültiger HIP-Bericht eingereicht werden sollte. Auch hier waren die OpenConnect-Entwickler genial genug, ein Shell-Skript zu automatisieren, das einen gefälschten HIP-Bericht erstellt. Wir haben das von unserem Windows-Rechner kopiert (indem Sie im Einstellungsbereich des offiziellen Clients auf der Registerkarte „Fehlerbehebung“ auf die Schaltfläche „Protokolle sammeln“ klicken. Dadurch wird eine Datei im Benutzerverzeichnis erstellt. Im komprimierten Ordner der HIP- GlobalProtectLogs.zipBericht könnte gefunden werden als pan_gp_hrpt.xml„“)
zu unserem ../openconnect/trojans/hipreport.sh.

Wir versuchen, unseren gefälschten Bericht einzureichen: und versuchen, den segmentierten Dienst zu erreichen:
openconnect --protocol=gp --user=username --csd-wrapper=trojans/hipreport.sh https://vpn.company.com/gateway

Wir haben sowohl MFA als auch die Maschinentrennung erfolgreich umgangen!

Von hier aus war eine Verbindung zu Active Directory und eine weitere Nutzung der internen Umgebung der Organisation möglich.

Schnelle Lösung

Die Behebung dieser Fehlkonfiguration ist ganz einfach:

1. MFA sollte sowohl auf dem Portal als auch auf dem/den Gateway(s) durchgesetzt werden.
2. Überwachen Sie direkte SSLVPN-Verbindungen zum Gateway
3. Trennen Sie das Portal und die Gateways auf verschiedene Schnittstellen und Ports
4. Lassen Sie nach Möglichkeit nur die SAML-Authentifizierung zu

Als Red-Team-Betreiber haben wir stets das Ziel, unseren Kunden einen Mehrwert zu bieten. Jede Bewertung birgt ihre eigenen Hindernisse, aber besonders wachsam zu sein, wenn alles sicher scheint, ist ein langer Weg. Zunächst sah es so aus, als gäbe es keine externen Ressourcen, die angegriffen werden könnten, und MFA wurde auf jeder mit dem Internet verbundenen Schnittstelle durchgesetzt, einschließlich des GlobalProtect VPN. Ein tieferes Eintauchen in die Benutzeroberfläche zeigte jedoch, dass es gefährlich ist, sich auf eine „friedliche“ Benutzerinteraktion zu verlassen .

Obwohl der Client von GlobalProtect sicher ist und nicht für eine andere Verwendung geändert werden kann, ist dies bei anderen VPN-Programmen möglich. Das Portal und die Gateways sind unabhängige Komponenten, was bedeutet, dass wir jede Komponente einzeln authentifizieren können, während die Nichterzwingung von MFA auf dem Gateway dazu führen könnte, dass ein Angreifer in der internen Unternehmensumgebung Fuß fasst.

Verfasst im Rahmen der CYE-Reihe „ CyberTalks “, um persönliches Wissen aus unserer Praxiserfahrung weiterzugeben.