Weitreichendes Potenzial von VPN-Angriffen: Post-Exploitation-Techniken
Zusammenfassung
In diesem Blogbeitrag untersuchen Forscher von Akamai die übersehene Bedrohung der VPN-Post-Exploitation. Wir besprechen also Techniken, mit denen Cyberkriminelle nach der Kompromittierung eines VPN-Servers noch tiefer in Netzwerke eindringen können.
Wir haben mehrere Sicherheitslücken aufgedeckt, die die VPNs Ivanti Connect Secure und FortiGate betrafen.
Neben den Schwachstellen werden mehrere nicht behobene Umgehungsmethoden beschrieben, die sich auf die Produkte Ivanti Connect Secure und FortiGate sowie potenziell auch auf andere VPN-Server auswirken können.
Unsere Untersuchungen zeigen, dass ein kompromittierter VPN-Server in vielen Fällen Angreifern die Kontrolle über weitere kritische Ressourcen im Netzwerk ermöglichen kann.
Dieser Blogbeitrag soll das Bewusstsein für diese Risiken schärfen und Best Practices vorstellen, die von Sicherheitsexperten befolgt werden sollten, um Risiken durch Post-Exploitation-Techniken im VPN zu minimieren.
Einführung
Wir alle haben diese Story schon einmal gehört: In einem VPN-Server wird eine kritische Sicherheitslücke entdeckt. Sie wird von Angreifern ausgenutzt. Administratoren stellen eilig Patches bereit. Panik breitet sich in sozialen Medien aus.
Das letzte Jahr war ziemlich hart für die VPN-Sicherheit. Scheinbar wurde jeden zweiten Monat eine kritische Schwachstelle gepatcht oder aufgedeckt, nachdem sie von Cyberkriminellen ausgenutzt wurde. Obwohl derartige Aktivitäten im Jahr 2023 erheblich zugenommen haben, sind sie nichts Neues. Angreifer versuchen schon lange, VPN-Server auszunutzen, da sie über das Internet zugänglich sind, eine vielseitige Angriffsfläche offenlegen und es oft an Sicherheit und Überwachungsfunktionen mangelt.
VPN-Server wurden klassisch in erster Linie ausgenutzt, um ein einziges Ziel zu erreichen: den Erstzugang. Angreifer kompromittierten den VPN-Server auf der Internetseite und nutzen ihn, um Zugriff auf das interne Netzwerk zu erlangen und dort Angriffe durchzuführen.
Obwohl dieser Ansatz sehr effektiv ist, haben wir uns gefragt: Sollte die Kontrolle über einen VPN-Server ausschließlich als Tor zum internen Netzwerk angesehen werden?
Wir wollten sehen, was noch damit möglich ist.
Im folgenden Blogbeitrag werden Post-Exploitation-Techniken im VPN beschrieben, die von Angreifern verwendet werden können, die bereits auf andere Weise einen VPN-Server kompromittiert haben, z. B. durchSchwachstellen odergestohlene Anmeldedaten, um weitere Vorhaben umzusetzen.
Weitreichendes Potenzial von VPN-Angriffen
Zu den wichtigsten Post-Exploitation-Techniken, die Angreifer verwenden, zählt die Kompromittierung des Betriebssystems. Nachdem ein Angreifer die Möglichkeit zur Remoteausführung von Code (RCE) erlangt hat, kann er individuell entwickelten Schadcode im Betriebssystem des Geräts platzieren. Dann kann der Angreifer jeden Aspekt des VPN steuern. Er kann beispielsweise Funktionen zum Ausgeben vertraulicher Informationen ausnutzen, durch Manipulation von Protokollen Erkennungsmechanismen umgehen oder die Systemkonfiguration ändern, um Persistenz auf dem Gerät zu erhalten.
Dieser Ansatz hat zwar viele Vorteile, aber auch einen großen Nachteil: Er ist teuer. Da Geräte in der Regel auf einem maßgeschneiderten gehärteten Betriebssystem ausgeführt werden, kann der Aufwand für die Entwicklung und Wartung von individuellem Schadcode für ein VPN-Gerät erheblich sein. Dies bedeutet, dass Post-Exploitation-Techniken im VPN in der Regel nur von hocherfahrenen Angreifern mit staatlicher Unterstützung genutzt wurden.
Ein anderer Ansatz
Wir entschieden uns für einen anderen Ansatz – eine „einfachere“ Form der VPN-Post-Exploitation. Anstatt nutzerdefinierten Schadcode zu verwenden, der auf dem Betriebssystem ausgeführt wird, haben wir beschlossen, die vorhandene Funktionalität des Geräts auszunutzen. Wir haben uns gefragt: Was können Angreifer erreichen, wenn sie nur die VPN-Verwaltungsschnittstelle ausnutzen?
Dieser Ansatz hat mindestens zwei Vorteile.
Diese Art des Zugriffs kann einfacher in der Umsetzung sein als eine vollständige RCE: Der Zugriff auf die Verwaltungsschnittstelle kann durch eine Sicherheitslücke zur Umgehung der Authentifizierung, schwache Anmeldeinformationen oder Phishing erreicht werden.
Dieser Ansatz kann kostengünstiger sein, da wir den Aufwand für die Entwicklung von maßgeschneidertem Schadcode vermeiden.
Als Testobjekte wählten wir zwei der führenden VPN-Server auf dem Markt: Ivanti Connect Secure und FortiGate. Wir haben 2 CVEs und eine Reihe von Umgehungsmethoden entdeckt, die von Angreifern verwendet werden können, die den VPN-Server kontrollieren, um andere kritische Assets im Netzwerk zu übernehmen, wodurch eine VPN-Kompromittierung potenziell zu einer vollständigen Netzwerk-Kompromittierung werden kann.
Obwohl sich unsere Ergebnisse auf FortiGate und Ivanti beziehen, gehen wir davon aus, dass Variationen der ermittelten Techniken auf weitere VPN-Server und Edge-Geräte anwendbar sind.
Ausnutzen von Remote-Authentifizierungsservern
Einige der interessantesten Assets, die von einem VPN-Server verarbeitet werden, sind externe Anmeldeinformationen. Obwohl VPN-Server die Verwendung lokaler Nutzer für die Authentifizierung unterstützen, wird in vielen Fällen ein externer Authentifizierungsserver verwendet.
Anstatt einen separaten Satz von Anmeldeinformationen pro Nutzer zu verwalten, können Administratoren einen vorhandenen Identitätsprovider verwenden, um ihre Nutzer zu authentifizieren. Der Nutzer sendet seine „normalen“ Anmeldeinformationen an den VPN-Server, die über den Remote-Authentifizierungsserver validiert werden (Abbildung 1).
Abb. 1: Verwendung eines Remote-Authentifizierungsservers zur Authentifizierung von Nutzern
Zu diesem Zweck können verschiedene Arten von Authentifizierungsservern verwendet werden. Die beiden wichtigsten Optionen sind LDAP und RADIUS.
Wir haben einige Techniken identifiziert, mit denen Angreifer dieses Verhalten ausnutzen können, um diese externen Anmeldeinformationen zu kompromittieren. Dadurch erhalten Angreifer möglicherweise Zugriff auf zusätzliche Ressourcen im Netzwerk.
LDAP-Zugangsdaten abfangen
LDAP ist eine beliebte Wahl für VPN-Authentifizierungsserver, meist ein Active Directory (AD) Domaincontroller. Mit dieser Konfiguration können Nutzer über ihre Domain-Anmeldeinformationen auf das VPN zugreifen, was dies zu einer besonders praktischen Option macht.
Bei der Konfiguration eines LDAP-Authentifizierungsservers werden die Anmeldeinformationen eines AD-Servicekontos bereitgestellt, damit Nutzerinformationen durch das VPN abgefragt werden können. Ein Beispiel für diese Konfiguration in FortiGate ist in Abbildung 2 zu sehen.
Abb. 2: Konfiguration des LDAP-Authentifizierungsservers in der FortiGate-GUI
Wenn ein Nutzer versucht, sich mit LDAP-Anmeldeinformationen bei FortiGate oder Ivanti zu authentifizieren, überprüft das VPN diese, indem es den LDAP-Server kontaktiert. Die genaue Umsetzung variiert zwischen den beiden Optionen leicht, weshalb wir hier beide untersuchen.
LDAP-Authentifizierung bei FortiGate
Um die Anmeldeinformationen zu validieren, versucht FortiGate, sie für die Authentifizierung beim Remote-Server zu verwenden. Dieser Prozess erfolgt über einfache Authentifizierung. Das bedeutet, dass FortiGate das Kennwort in Klartext an den Server sendet (Abbildung 3).
Abb. 3: LDAP Simple Bind gibt das Nutzerkennwort in Klartext an
Während dieses Vorgangs werden zwei Gruppen von Anmeldeinformationen übertragen: die Anmeldeinformationen des LDAP-Servicekontos, das auf FortiGate konfiguriert ist, und die Anmeldeinformationen, die vom authentifizierenden Nutzer bereitgestellt werden. Beides wird in Klartext gesendet.
Während LDAP die Standardkonfiguration ist, unterstützt FortiGate auch LDAPS und TLS, was eine Klartext-Kommunikation verhindern sollte.
LDAP-Authentifizierung bei Ivanti
Die Implementierung von Ivanti für die LDAP-Authentifizierung unterscheidet sich geringfügig und unterstützt zwei Typen von LDAP-Authentifizierungsservern: Normales LDAP und Active Directory (Abbildung 4).
Abb. 4: Optionen des Ivanti-Authentifizierungsservers, einschließlich LDAP- und Active Directory-Server
LDAP-Authentifizierungsserver
Bei einem LDAP-Authentifizierungsserver bestehen Ähnlichkeiten zum FortiGate-Prozess. Das heißt, wenn nur LDAP verwendet wird, wird eine einfache Verbindung hergestellt, und sowohl das AD-Servicekonto als auch die authentifizierenden Nutzeranmeldeinformationen werden in Klartext übertragen (Abbildung 5).
Abb. 5: Ivanti überträgt LDAP-Zugangsdaten in Klartext
Wenn Sie jedoch einen LDAP-Authentifizierungsserver konfigurieren, ist die Standardeinstellung TLS, und LDAPS wird ebenfalls unterstützt. Daher verwenden Ivanti-Instanzen seltener nur LDAP.
AD-Authentifizierungsserver
Der zweite Typ des LDAP-Authentifizierungsservers, der konfiguriert werden kann, ist ein AD-Server. Bei Verwendung dieser Option erfolgt die Authentifizierung über Kerberos, d. h. es werden keine Kennwörter übertragen (Abbildung 6).
Abb. 6: Sichere LDAP-Authentifizierung mit Kerberos
Aufgreifen von LDAP-Anmeldeinformationen in Klartext
Bei FortiGate und Ivanti können alle an den VPN gesendeten Anmeldeinformationen kompromittiert werden, wenn ein Nutzer über einfaches LDAP authentifiziert wird. Diese Kompromittierung kann von einem Angreifer ausgeführt werden, der sich zwischen dem VPN- und dem LDAP-Server befindet, oder von einem Angreifer, der den VPN-Server kontrolliert.
Wie können wir die Anmeldeinformationen erfassen, ohne Schadcode auf dem Gerät auszuführen? FortiGate und Ivanti haben jeweils eine integrierte Funktion zur Paketerfassung, was unsere Arbeit hier erleichtert. Indem ein Angreifer die Funktion zum Erfassen von LDAP-Paketen verwendet, kann er alle Anmeldeinformationen abfangen, die das VPN durchlaufen (Abbildung 7).
Abb. 7: Verwendung der Paketerfassungsfunktion von FortiGate oder Ivanti zur Erfassung von LDAP-Kommunikationen
Wird ein sicheres Protokoll verwendet, werden keine Klartext-Anmeldeinformationen vom Server gesendet. Trotzdem kann ein Angreifer, der Kontrolle über das VPN hat, die Anmeldeinformationen einfach erfassen. Wenn wir das VPN kontrollieren, hindert uns nichts daran, die Konfiguration zu ändern und wieder auf einfaches LDAP herunterzustufen.
Bei normalen LDAP-Servern können wir die Konfiguration unkompliziert in einfaches LDAP ändern. Um den AD-Server von Ivanti herunterzustufen, können wir die AD-Verbindungsdetails verwenden, um anstelle des vorhandenen einen neuen, normalen LDAP-Server zu konfigurieren. In beiden Fällen sollte diese Änderung gegenüber den Nutzern transparent sein und dazu führen, dass das VPN die Kennwörter in Klartext sendet.
Die Quintessenz: Wenn LDAP-Authentifizierung verwendet wird, kann ein Angreifer, der das VPN kompromittiert, problemlos Anmeldeinformationen abrufen und in die Domain eindringen.
Einen manipulierten Authentifizierungsserver registrieren
Wie bereits erwähnt, wendet sich das VPN bei der Authentifizierung eines Remote-Nutzers an den entsprechenden Authentifizierungsserver, um die angegebenen Anmeldeinformationen zu überprüfen. Wir haben eine Methode ermittelt, die diesen Authentifizierungsablauf ausnutzt, um alle Anmeldeinformationen zu kompromittieren, die von Nutzern an das VPN gesendet werden.
Bei dieser Technik wird ein manipulierter Authentifizierungsserver registriert, der vom VPN bei der Authentifizierung von Nutzern verwendet wird. Um Ihnen zu erläutern, wie diese Methode implementiert werden kann, beschreiben wir zunächst einige Einzelheiten des Authentifizierungsvorgangs beider VPNs.
Nutzergruppen bei FortiGate
FortiGate-Nutzer können unterschiedliche Berechtigungen erhalten, und es können unterschiedliche Richtlinien auf sie angewendet werden. Anstatt jeden Nutzer einzeln zu verwalten, können Nutzer in Nutzergruppen aufgenommen werden, d. h. Gruppen von Nutzern, auf die Richtlinien und Berechtigungen angewendet werden können.
Bei der Konfiguration einer solchen Gruppe können auch Nutzer aus Remote-Gruppen einbezogen werden – Gruppen, die auf einem Remote-Authentifizierungsserver vorhanden sind. Beispielsweise können Nutzer aus einer bestimmten AD-Gruppe einbezogen werden (Abbildung 8).
Abb. 8: Nutzergruppen-Konfiguration bei FortiGate
Wir haben ein interessantes Verhalten beobachtet, das bei der Verwendung von Remote-Gruppen auftritt. Nehmen wir an, wir konfigurieren eine Nutzergruppe, die zwei Elemente umfasst: einen lokalen FortiGate-Nutzer und eine Remote-Gruppe, die auf einem LDAP-Server vorliegt.
In Bezug auf die Authentifizierung erwarten wir folgendes Verhalten:
Wenn sich der lokale Nutzer der Gruppe bei FortiGate authentifiziert, werden seine Anmeldeinformationen anhand der lokalen Nutzerdatenbank von FortiGate überprüft.
Wenn sich ein Mitglied der Remote-Gruppe bei FortiGate authentifiziert, werden seine Anmeldeinformationen anhand des LDAP-Servers der Remote-Gruppe überprüft.
Wie sich herausgestellt hat, ist das jedoch nicht so. Wenn sich nach dem Hinzufügen einer Remote-Gruppe zu einer Nutzergruppe ein beliebiges Mitglied der Nutzergruppe authentifiziert, versucht FortiGate, seine Zugangsdaten mit der lokalen Nutzerdatenbank und dem Remote-Authentifizierungsserver zu validieren. Wenn wir einer Nutzergruppe mehr als einen Remote-Server hinzufügen, versucht FortiGate, Nutzer mit allen konfigurierten Authentifizierungsservern zu authentifizieren.
FortiGate gleicht einen spezifischen Nutzer nicht mit der passenden Authentifizierungsmethode ab, sondern probiert einfach alle aus. Wenn dies erfolgreich ist, wird der Nutzer authentifiziert.
Authentifizierungsbereich (Realm) bei Ivanti
Ivanti implementiert eine Funktion, die Nutzergruppen ähnelt: Authentifizierungsbereiche. Im Gegensatz zu den Nutzergruppen von FortiGate ist jeder Authentifizierungsbereich von Ivanti auf einen einzigen Authentifizierungsserver beschränkt. Um Nutzer von verschiedenen Servern aus zu verwalten, müssen separate Realms verwendet werden.
Trotz dieser Einschränkung ermöglicht uns Ivanti (zu unserem Vorteil) die Konfiguration eines „zusätzlichen Authentifizierungsservers“ (Abbildung 9). Diese Option dient zur Aktivierung bestimmter SSO-Konfigurationen.
Abb. 9: Konfigurieren eines zusätzlichen Authentifizierungsservers für einen Nutzer-Realm bei Ivanti
Wenn ein zusätzlicher Authentifizierungsserver konfiguriert ist, versucht Ivanti, die Anmeldeinformationen bei beiden Servern zu validieren. Die Authentifizierung ist nur erfolgreich, wenn beide Server sie bestätigen.
Erstellen eines manipulierten Authentifizierungsservers, um Zugangsdaten zu erlangen
Ein Angreifer kann diese Verhaltensweisen ausnutzen, um die Anmeldeinformationen eines Nutzers preiszugeben, der sich bei FortiGate oder Ivanti mit einem beliebigen Remote-Authentifizierungsserver authentifiziert. Durch Hinzufügen eines manipulierten Authentifizierungsservers zu einer Nutzergruppe oder einem Realm können wir bewirken, dass der VPN-Server Anmeldeinformationen gegenüber einem vom Angreifer kontrollierten Server preisgibt (Abbildung 10).
Abb. 10: Hinzufügen eines manipulierten Authentifizierungsservers, um die Anmeldeinformationen des Clients zu kompromittieren
Diese Anmeldeinformationen können von Clients stammen, die eine Verbindung zum VPN herstellen, oder von Administratoren, die eine Verbindung zur Verwaltungsschnittstelle herstellen. Jede Authentifizierung, die mit einer Nutzergruppe oder einem Realm verwaltet wird, kann mit dieser Methode kompromittiert werden.
Um die Methode auf FortiGate zu implementieren, haben wir eine Remote-Gruppe erstellt, die unseren manipulierten Server verwendet, und diese dann unserer Zielgruppe hinzugefügt. Bei Ivanti haben wir einfach unseren manipulierten Server als einen zusätzlichen Authentifizierungsserver für unseren Ziel-Realm hinzugefügt.
Wenn sich nun ein Mitglied der Ziel-Nutzergruppe bzw. des Ziel-Realms authentifiziert, versucht das VPN, die Anmeldeinformationen des Mitglieds über unseren Server zu validieren (Abbildung 11).
Abb. 11: Hinzufügen eines manipulierten RADIUS-Authentifizierungsservers zu einer Nutzergruppe
Um die Anmeldeinformationen zu erfassen, verwenden wir einen RADIUS-Authentifizierungsserver. Die RADIUS-Authentifizierung ist in diesem Szenario aus zwei Gründen praktisch:
Zugangsdaten werden während der ersten Anforderung an den Server gesendet, ohne dass vorher geprüft wird, ob der Nutzer auf dem Server vorhanden ist.
Anmeldeinformationen werden verschlüsselt mit einem Key an den Server gesendet, der vom Angreifer bestimmt wird, sodass der Angreifer die Anmeldeinformationen im Klartext abgreifen kann (Abbildung 2).
Abb. 12: Ein verschlüsseltes Kennwort in einer RADIUS-Authentifizierungsnachricht
Das folgende Skript (basierend auf RFC 2865) kann RADIUS-Kennwörter entschlüsseln:
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
Eine abschließende Bemerkung: Wie bereits erwähnt, wenn Ivanti einen zusätzlichen Authentifizierungsserver verwendet, müssen beide Server den Nutzer validieren, damit die Authentifizierung erfolgt. Wenn unser Server die angegebenen Anmeldeinformationen nicht genehmigt, können sich Nutzer nicht bei Ivanti authentifizieren. Um dies zu verhindern, müssen wir sicherstellen, dass unser RADIUS-Server alle Anmeldeinformationen genehmigt, die ihm zur Verfügung gestellt werden, was ganz einfach konfiguriert werden kann.
Extrahieren der Secrets von Konfigurationsdateien
Was uns die größten Sorgen bereitet, sind die VPN-Konfigurationsdateien.
Unter den zahlreichen interessanten Einstellungen, die wir aus der Konfigurationsdatei auslesen können, fällt eine Kategorie besonders auf: die Secrets. VPNs speichern viele Secrets in ihrer Konfiguration, darunter lokale Nutzerkennwörter, SSH-Schlüssel, Zertifikate und, was am interessantesten ist, Konten für von Drittanbietern bereitgestellte Services.
Diese sensiblen Dateien können von einem Angreifer auf zwei Arten abgerufen werden:
Nachdem ein Angreifer die Kontrolle über ein VPN erlangt hat, kann er über die Verwaltungsschnittstelle die Gerätekonfiguration exportieren.
Ein Angreifer kann eine zuvor exportierte Konfigurationsdatei auffinden, die an einem öffentlichen Speicherort gespeichert wurde, z. B. in einem freigegebenen Ordner.
Um sie zu schützen, werden Secrets in verschlüsselter Form in der Konfigurationsdatei gespeichert. Abbildung 13 zeigt ein Beispiel für ein verschlüsseltes Secret in einer FortiGate-Konfigurationsdatei.
Abb. 13: Ein verschlüsseltes Kennwort in einer FortiGate-Konfigurationsdatei
Entschlüsseln wir nun ein paar Secrets.
Entschlüsseln von Secrets aus einer FortiGate-Konfigurationsdatei
Man könnte meinen, dass die Secrets gehasht sind und daher nicht abgegriffen werden können. Tatsächlich ist das aber nicht der Fall. Ein Beispiel sind Integrationskennwörter. Da das Klartext-Kennwort für die Verbindung mit dem Drittanbieter erforderlich ist, muss es mittels reversibler Verschlüsselung gespeichert werden.
Dies wurde in einem Blogbeitrag von Bart Dopheide bewiesen, der sich ausführlich mit der Kennwortverschlüsselung in FortiGate befasst hat. FortiGate verwendet AES, um alle Secrets in der Konfiguration zu verschlüsseln. Welcher Schlüssel wird dafür verwendet? Dopheide hat herausgefunden, dass ein einzelner fest programmierter Schlüssel für alle FortiGate-Geräte verwendet wird. Dieser Schlüssel konnte nicht geändert werden. Der ursprüngliche Blogbeitrag gibt ihn nicht preis, aber eine schnelle Google-Suche führt Sie direkt zu ihm.
Fortinet hat diesem Problem die CVE-Nummer CVE 2019–6693 zugewiesen und eine Korrektur implementiert, indem Nutzer den fest programmierten Schlüssel in einen nutzerdefinierten ändern können.
Auch nach dieser Problemlösung ist das Thema aktuell noch sehr relevant. Der Schlüssel wurde nicht geändert, also verwenden FortiGate-Geräte immer noch standardmäßig alle denselben Schlüssel. Das bedeutet, wenn eine Angreifer eine Konfigurationsdatei eines FortiGate-Geräts mit der Standardkonfiguration erhält, alle auf dem Gerät gespeicherten Secrets entschlüsseln kann. Dieser Code implementiert den Entschlüsselungsprozess.
Okay, aber was ist, wenn der FortiGate-Administrator die Best Practice befolgt und einen nutzerdefinierten Schlüssel anstelle des Standardschlüssels verwendet? Wir haben herausgefunden, dass wir, wenn wir das VPN kontrollieren, immer noch die Secrets beschaffen können.
Die Einstellung private-data-encryption wird verwendet, um den nutzerdefinierten Kodierungsschlüssel zu steuern. Überraschend ist, dass Administratoren diese Funktion einfach deaktivieren können. Dies erfordert keine Kenntnis des aktuell konfigurierten Schlüssels und setzt die Verschlüsselung aller Secrets auf den ursprünglichen, fest programmierten Schlüssel zurück.
Widerrufen der Verschlüsselung
Zum Widerrufen der Verschlüsselung können wir die folgenden Befehle der FortiGate-Befehlszeilenschnittstelle verwenden:
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
Jetzt können wir die Konfigurationsdatei herunterladen und die Secrets mithilfe des bekannten Standardschlüssels entschlüsseln (genau wie zuvor gezeigt).
Viele interessante Secrets können mit dieser Methode kompromittiert werden. FortiGate unterstützt Integrationen mit verschiedenen Anwendungen über die Funktion „external connector“. Diese Konnektoren dienen verschiedenen Zwecken, jedoch haben die meisten von ihnen einen wichtigen Aspekt gemein: Sie benötigen Anmeldeinformationen für die Anwendung (Abbildung 14).
Abb. 14: FortiGate-Option „external connector“
Das bedeutet, dass FortiGate Anmeldedaten für kritische Services wie Cloudanbieter, SAP, Kubernetes, ESXi und mehr enthält.
In einigen Fällen erfordern die Anmeldeinformationen hohe Privilegien für die jeweilige Anwendung. Beispielsweise erfordert die Integration „Poll Active Directory Server“ die Anmeldeinformationen eines Kontos mit Administratorzugriff auf einen Domaincontroller,wodurch eine Kompromittierung von FortiGate unmittelbar zu einer vollständigen Kompromittierung der Domain führen würde.
Entschlüsseln von Secrets aus Ivanti-Konfigurationsdateien
Die Situation bei Ivanti ist ziemlich ähnlich. Sie könnte sogar noch schlimmer sein.
Ivanti speichert ebenfalls Secrets mit reversibler Verschlüsselung. Wenn wir den Code aus dem Gerät extrahieren und ihn untersuchen, finden wir schnell den Wert des Secrets, der als Kodierungsschlüssel verwendet wird und (schon wieder) eine statische Zeichenfolge ist (Abbildung 15).
Abb. 15: Statischer Ivanti-Kodierungsschlüssel
Zwar haben wir den Schlüssel zensiert, indem wir jedoch seinen Anfang untersuchen, können wir davon ausgehen, dass er sich seit mindestens 2015, als Connect Secure zuletzt Eigentum von Juniper war, wahrscheinlich nicht geändert hat.
Ivanti scheint größere Anstrengungen unternommen zu haben, um die gespeicherten Secrets zu schützen und einen komplexeren Verschlüsselungsalgorithmus als FortiGate zu implementieren. Dennoch ist dieser Prozess natürlich immer noch reversibel. Das bedeutet, dass Secrets über alle Ivanti-Instanzen hinweg mit einem statischen Schlüssel verschlüsselt werden, der nicht geändert werden kann. Angreifer könnten dieses Wissen nutzen, um eine Ivanti-Konfigurationsdatei zu entschlüsseln.
Ivanti entschlüsselt Kennwörter für uns
Unser ursprünglicher Ansatz bestand darin, den Verschlüsselungsprozess zu widerrufen, um ein Entschlüsselungsprogramm zu entwickeln. Das ist sicherlich möglich. Nachdem wir uns aber ein paar Stunden mit dekompiliertem Code beschäftigt hatten, entschieden wir uns für einen anderen Ansatz als Proof of Concept. Wir ließen die aufwendige Arbeit von Ivanti für uns erledigen.
Das Konzept besteht darin, eine manipulierte Ivanti-Instanz bereitzustellen, das verschlüsselte Kennwort an diese Instanz zu geben und sie dazu zu bringen, das Kennwort für uns zu entschlüsseln (Abbildung 16).
Abb. 16: Entschlüsselung eines Ivanti-Kennworts in der Laborumgebung eines Angreifers
Diese Entschlüsselung kann über die folgenden Schritte erfolgen:
Rufen Sie ein verschlüsseltes Kennwort aus einer Ivanti-Konfigurationsdatei ab.
Richten Sie in einer Laborumgebung eine Ivanti-Instanz und einen LDAP-Server ein (z. B. einen Windows-Server, auf dem Active Directory ausgeführt wird).
Konfigurieren Sie auf der Labor-Ivanti-Instanz unseren LDAP-Server als Authentifizierungsserver mit einfacher Authentifizierung.
Exportieren Sie die Labor-Ivanti-Konfiguration in eine Datei.
Ersetzen Sie das vorhandene verschlüsselte LDAP-Kennwort in der Konfigurationsdatei durch das verschlüsselte Kennwort, das wir entschlüsseln möchten.
Importieren Sie die geänderte Konfigurationsdatei zurück in die Ivanti-Instanz.
Wenn wir nun einen Authentifizierungsversuch an den LDAP-Server auslösen, entschlüsselt Ivanti das Kennwort aus der Konfiguration und sendet es in Klartext an den LDAP-Server. Durch das Erfassen der Pakete können wir das entschlüsselte Kennwort abrufen (Abbildung 17).
Abb. 17: Ivanti entschlüsselt unser angegebenes Kennwort und gibt das Ergebnis über LDAP aus
Wir verwenden die LDAP-Serverauthentifizierung als „Schnittstelle“ für den Entschlüsselungsprozess, aber es sollte beachtet werden, dass wir nicht auf LDAP-Kennwörter beschränkt sind. Unsere Tests haben gezeigt, dass diese Technik für alle Secrets funktioniert, die in der Konfigurationsdatei gespeichert sind, darunter (aber nicht beschränkt auf) AD-Kennwörter, RADIUS-PSKs und API-Schlüssel.
MDM-Server-Kennwörter in Klartext
Ivanti unterstützt einige gängige MDM-Server (Mobile Device Management) als Authentifizierungsmethode (Abbildung 18).
Abb. 18: Konfiguration des Ivanti-MDM-Servers
Wie bei anderen Authentifizierungsservern erfordert diese Integration Anmeldeinformationen für den MDM-Server. Wenn wir die Konfiguration für den MDM-Server untersuchen, entdecken wir zwei interessante Felder: „password-encrypted“ und „password-cleartext“. Und entgegen dem, was die Bezeichnungen vermuten lassen, werden beide Felder in Klartext gespeichert (Abbildung 19). ♂️
Abb. 19: Ivanti-MDM-Konfiguration, die Kennwörter in Klartext enthält
Anwendung der Post-Exploitation-Techniken im VPN
Es ist wahrscheinlich, dass einige der Techniken, die wir in diesem Beitrag besprochen haben, bereits aktiv eingesetzt werden. In Ihrem Bericht „Cutting Edge“, in dem mehrere Exploitstrategien für Ivanti-Geräte besprochen werden, geben die Forscher von Mandiant bekannt, dass Angreifer das auf dem Ivanti-Gerät konfigurierte Konto des LDAP-Services kompromittieren konnten (Abbildung 20).
Abb. 20: Bericht von Mandiant, der ein kompromittiertes LDAP-Konto erwähnt
Der Mandiant-Bericht geht nicht im Detail darauf ein, wie die Angreifer dies erreichen konnten. Wir glauben aber, es ist ziemlich wahrscheinlich, dass die Angreifer die Anmeldedaten mithilfe einer der in unserem Blogbeitrag erläuterten Methoden erlangen konnten, also entweder durch Extrahieren aus der Konfigurationsdatei oder durch Sniffen des Netzwerkverkehrs.
Derartige Techniken sind einfach zu implementieren und können von Angreifern aller Erfahrungsstufen eingesetzt werden.
Empfehlungen für den Betrieb von VPN-Servern
Wir empfehlen vier Prinzipien, die bei der Verwendung von VPN-Servern beachtet werden sollten, um Risiken durch die hier besprochenen Techniken zu minimieren:
Verwenden von Zero Trust Network Access
Berechtigungen von Servicekonten einschränken
Verwenden dedizierter Identitäten für die VPN-Authentifizierung
Überwachen von Konfigurationsänderungen
1. Verwenden von Zero Trust Network Access
Eines der Hauptprobleme herkömmlicher VPNs ist ihr „Alles oder Nichts“-Konzept bei der Erteilung des Netzwerkzugriffs: Die Nutzer sind entweder „in“ (und haben vollständigen Zugriff auf das Netzwerk) oder „out“ (und können auf nichts zugreifen).
Beide Szenarien sind problematisch. Einerseits müssen wir Nutzern Fernzugriff auf interne Anwendungen gewähren. Andererseits möchten wir nicht, dass ein Angreifer vollen Zugriff auf das Netzwerk erhält, wenn er einen VPN-Server kompromittiert.
Zero Trust Network Access (ZTNA) bietet einen Lösungsansatz. Durch die Definition von einzelnen Netzwerkzugriffsrichtlinien pro Entität können wir Nutzern zulässige Remote-Vorgänge gewähren und gleichzeitig die Auswirkungen einer potenziellen Sicherheitsverletzung reduzieren.
Akamai Enterprise Application Access ist eine ZTNA-Lösung, die basierend auf Identität und Kontext präzisen Zugriff auf private Anwendungen bietet. Sie verwendet identitätsbasierte Richtlinien und Echtzeitdaten wie den Nutzerstandort, die Zeit und die Gerätesicherheit, um sicherzustellen, dass Nutzer nur Zugriff auf die Anwendungen haben, die sie benötigen und eliminiert so den Zugriff auf Netzwerkebene. Zum Bereitstellen einer starken Nutzerauthentifizierung arbeitet es nahtlos mit Akamai MFA zusammen.
2. Berechtigungen von Servicekonten einschränken
Wie in diesem Beitrag veranschaulicht, ist es trivial, die Klartext-Kennwörter der Servicekonten wiederherzustellen, die auf VPN-Servern gespeichert sind. Es gibt keine wirkliche Möglichkeit, dies zu vermeiden, da VPNs in einigen Fällen die Verwendung von Klartext-Kennwörtern erfordern.
Um die Auswirkungen einer potenziellen VPN-Gefährdung zu verringern, empfehlen wir die Verwendung von Servicekonten mit weniger Berechtigungen – vorzugsweise schreibgeschützt. Sicherheitsexperten sollten verstehen, wie ein Angreifer die im VPN gespeicherten Anmeldeinformationen nutzen kann, und sollten dafür sorgen, dass durch eine Kompromittierung des VPN keine anderen kritischen Assets gefährdet werden.
Für den Betrieb einiger Integrationen ist ein Servicekonto mit starken Berechtigungen erforderlich. Wenn möglich, sollte dies vermieden werden.
3. Verwenden dedizierter Identitäten für die VPN-Authentifizierung
Wie wir jetzt wissen, ist es für Angreifer mit Kontrolle über das VPN trivial, die Anmeldeinformationen für die Authentifizierung von VPN-Nutzern zu kompromittieren. Obwohl es verlockend sein könnte, vorhandene Authentifizierungsservices wie AD zu verwenden, um Nutzer beim VPN zu authentifizieren, empfehlen wir, dies zu vermeiden. Angreifer, die die Kontrolle über das VPN haben, können Anmeldeinformationen abrufen und diese für den Zugriff auf interne Assets verwenden, wodurch das VPN zu einer zentralen Schwachstelle wird.
Wir empfehlen Ihnen, stattdessen eine separate, dedizierte Methode zu verwenden, um Nutzer beim VPN zu authentifizieren. Beispielsweise können Sie eine zertifikatsbasierte Authentifizierung umsetzen und dabei Zertifikate verwenden, die speziell für diesen Zweck ausgestellt werden.
4. Überwachen von Konfigurationsänderungen
Die Techniken, die wir hervorgehoben haben, spiegeln sich auf die eine oder andere Weise in der Gerätekonfiguration wider. Da sich die Konfiguration von Netzwerkgeräten nicht häufig ändert, bieten derartige Veränderungen eine Möglichkeit zur Erkennung von Angriffen.
Um Konfigurationsänderungen aufzudecken, empfehlen wir, die Gerätekonfiguration regelmäßig mit einem „Golden Image“ (eine vorkonfigurierte VM-Vorlage) zu vergleichen. Die meisten Geräte verfügen zudem über interne Protokollierungsfunktionen für System- und Sicherheitsereignisse. Wir empfehlen Ihnen, alle verfügbaren Protokolle zu untersuchen, um verdächtige Änderungen an der Gerätekonfiguration zu identifizieren.
Diese vier Prinzipien führen zu einem Ergebnis: Man sollte VPNs nicht blind vertrauen.
Zusammenfassung
Angreifer sind hinter Ihrem VPN her. Das ist eine Tatsache. Es ist nur eine Frage der Zeit, bis sich Angreifer Zugriff auf Ihr VPN verschaffen. Davon sollten Sicherheitsexperten ausgehen und daher umgehend entsprechende Maßnahmen ergreifen. Es muss sichergestellt werden, dass ein kompromittiertes VPN nicht zu einem vollständig kompromittierten Netzwerk führen kann.
Chronik der Veröffentlichung
Ivanti
26.03.2024: Ursprünglicher Bericht an den Anbieter
05.04.2024: Ivanti bestätigt den Bericht und kündigt an, dass an einer Problembehebung gearbeitet wird.
03.06.2024: Erste Mitteilung an Ivanti, dass wir die Veröffentlichung der Studie für den 7. August planen.
27.06.2024: Ivanti gibt an, dass an einer Problembehebung gearbeitet wird, kann aber nicht bestätigen, dass die Probleme vor dem Veröffentlichungsdatum behoben werden.
08.07.2024: Ivanti weist dem Problem bezüglich des fest programmierten Schlüssels und den Klartext-MDM-Kennwörtern die CVE-Nummern CVE-2024-37374 bzw. CVE-2024-37375 zu, hat aber noch keine Patches veröffentlicht.
15.07.2024: Zusätzliche Mitteilung an Ivanti über den geplanten Veröffentlichungszeitplan
07.08.2024: Forschungsbericht wird veröffentlicht
Fortinet
22.03.2024: Ursprünglicher Bericht an den Anbieter
17.04.2024: Erste Antwort von Fortinet, in der angegeben wird, dass für keines der beschriebenen Probleme eine Lösung erforderlich ist.
21.04.2024: Erste Mitteilung an Fortinet, dass wir beabsichtigen, die Studie am 7. August zu veröffentlichen.
30.04.2024: Fortinet informiert uns über das Vorhaben, die von uns beschriebene Umgehung, die nutzerdefinierte Kodierungsschlüssel ausnutzt, zu beheben.
15.07.2024: Zusätzliche Mitteilung an Fortinet über den geplanten Veröffentlichungsplan
23.07.2024: Fortinet gibt an, dass der Patch wahrscheinlich nicht vor unserem Veröffentlichungsdatum bereitgestellt werden kann.
02.08.2024: Fortinet teilt uns mit, dass nach weiteren Überlegungen entschieden wurde, die Umgehung, die nutzerdefinierte Kodierungsschlüssel ausnutzt, nicht zu beheben, da sie „keine Sicherheitsgrenze überschreitet“.
07.08.2024: Forschungsbericht wird veröffentlicht