Dritte KDC-Spoofing-Schwachstelle Identifiziert von Silverfort Forscher – diesmal in IBM QRadar [CVE-2019-4545]

*****Von Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach, Silverfort*****

KDC-Spoofing wird nie alt. Wir haben KDC-Spoofing-Schwachstellen in offengelegt Cisco ASA und Palo Alto Networks PAN-OS bereits im Mai 2020. Jetzt können wir mitteilen, dass IBM QRadar aufgrund der Art und Weise auch anfällig ist Kerberos wurde implementiert.
Die KDC-Spoofing-Schwachstelle ermöglicht es einem Angreifer, die Kerberos-Authentifizierung bei QRadar zu umgehen und sich dadurch administrativen Zugriff auf das System zu verschaffen. Wir haben eng mit IBM-Ingenieuren zusammengearbeitet, um dieses Problem zu beheben, was zu der kürzlich herausgegebenen Sicherheitsbulletin . Dieser Blogbeitrag umreißt die Schwachstelle, erklärt, wie diese Schwachstellen als Entwickler vermieden werden können, der Kerberos implementiert, und spricht über Risikominderung für Organisationen, die QRadar und andere Systeme verwenden, die Kerberos verwenden.

Erläuterung der Schwachstelle

IBM QRadar Security Information and Event Management (SIEM) hilft Sicherheitsteams, Bedrohungen im gesamten Unternehmen zu erkennen und zu priorisieren, und liefert wichtige Erkenntnisse, die es Teams ermöglichen, schnell zu reagieren, um die Auswirkungen von Vorfällen zu verringern.
Die Schwachstelle liegt in der Implementierung des Kerberos-Protokolls durch IBM. Kerberos ist das gebräuchlichste Authentifizierungsprotokoll für die lokale Authentifizierung. Aufgrund seiner Beliebtheit wird es häufig in Unternehmensnetzwerken verwendet Active Directoryund wird gegenüber schwächeren Authentifizierungsprotokollen wie NTLM bevorzugt.
IBM verwendet das Kerberos-Authentifizierungsprotokoll zum Authentifizieren des Verwaltungszugriffs. Daher ermöglicht die Umgehung der Kerberos-Authentifizierung einem Angreifer, administrativen Zugriff auf IBM QRadar zu erlangen, vertrauliche Informationen anzuzeigen und möglicherweise Protokolle zu ändern – ohne über legitime Anmeldeinformationen zu verfügen.
Damit das Kerberos-Protokoll funktioniert, sollten drei Dinge passieren:

• 1. Der Benutzer authentifiziert sich beim Server
  2. Der Server authentifiziert sich gegenüber dem Client
  3. das KDC authentifiziert sich beim Server

Anscheinend wird die KDC-Authentifizierung gegenüber dem Server oft übersehen. Vielleicht, weil es die Konfigurationsanforderungen komplizierter macht. Wenn sich das KDC jedoch nicht beim Server authentifiziert, ist die Sicherheit des Protokolls vollständig gefährdet, sodass sich ein Angreifer, der den Netzwerkverkehr missbraucht hat, mit einem beliebigen Kennwort bei QRadar authentifizieren kann, sogar mit einem falschen.

Kerberos-Terminologie und Hintergrundinformationen zur Funktionsweise eines KDC-Spoofing-Angriffs finden Sie am Ende dieses Blogbeitrags.

Wie wir die Schwachstelle in QRadar entdeckt haben

Der Administratorzugriff auf QRadar sollte mit starker Authentifizierung geschützt werden, um unbefugten Zugriff und Systemmanipulationen zu verhindern. Die Verwendung der AD-Authentifizierung ist eine beliebte Option:
Wenn sich ein Administrator bei QRadar authentifiziert, verwendet es eine Reihe von Parametern, um den Administrator zu authentifizieren (siehe unten eine Momentaufnahme des Implementierungsleitfadens aus hier). Zuerst fordert QRadar ein TGT von AD an. Nach Erhalt des TGT fordert QRadar ein Serviceticket für die LDAP-Authentifizierung beim Domänencontroller an. Bei Erfolg verwendet QRadar SASL, um sich mit LDAP beim DC zu authentifizieren. Es verwendet das Dienstticket, um die Identität des Benutzers nachzuweisen.

Spoofing Kerberos/SASL-Authentifizierung

Hier sind die Schritte, die ein Angreifer unternehmen wird, um einen DC zu spoofen, um diese Art der Authentifizierung zu umgehen. Nehmen wir an, dass wir die Netzwerkkommunikation zwischen QRadar und dem DC kapern können. In diesem Fall können wir einen gefälschten DC mit einem Benutzernamen erstellen, der mit dem Benutzernamen des Administrators identisch ist, und ein Passwort unserer Wahl. Dann initiieren wir eine Authentifizierung bei QRadar und verwenden den von uns gewählten Benutzer und das Passwort. QRadar authentifiziert sich bei Kerberos, und wir übernehmen die Kerberos-Kommunikation und geben ein AS_REP zurück, das dem von uns gewählten Kennwort entspricht. und ein TGS_REP, das aus einem Dienstticket besteht, das mit einem Dienstsitzungsschlüssel unserer Wahl verschlüsselt ist, und einem Sitzungsschlüssel unserer Wahl, der mit dem von uns gewählten Passwort verschlüsselt ist. Da sich in diesen Phasen die einzige auf QRadar-Seite durchgeführte Überprüfung auf das von uns gewählte Kennwort stützt, sollte QRadar die Authentifizierung an dieser Stelle nicht ablehnen. Nachdem QRadar nun das Serviceticket erhalten hat, kann es eine LDAP-Anforderung an den DC einleiten. Wir werden auch den LDAP-Verkehr entführen. Wir haben an dieser Stelle zwei Möglichkeiten:
1. LDAP wird ohne TLS verwendet. In diesem Fall können wir den LDAP-Verkehr entführen. QRadar sendet eine Bindungsanforderung mit einer Kerberos-AP_REQ-Nachricht an den DC, die das uns vorliegende Serviceticket enthält. Wir können einen AP_REP zurückgeben, der auf dem von uns gewählten Servicesitzungsschlüssel basiert, und QRadar akzeptiert ihn.
2. LDAPS wurde konfiguriert. In diesem Fall können wir keine Antwort im Namen des DC zurückgeben, da TLS zur Authentifizierung des DC verwendet wird, vorausgesetzt, das Zertifikat wurde auf QRadar-Seite konfiguriert.

Spoofing Kerberos/SASL/LDAPS-Authentifizierung für QRadar

Bevor wir Option 2 aufgegeben haben, ist uns folgendes merkwürdiges Verhalten aufgefallen. Wenn wir eine IP-Adresse als Server-URL konfigurieren, funktioniert die Authentifizierung weiterhin. Theoretisch sollte die Authentifizierung mit einer IP-Adresse nicht funktionieren, weil Kerberos lässt keine Authentifizierung an IP-Adressen zu, es sei denn, ein SPN wurde explizit konfiguriert.
Beim Senden von TGS_REQ fordert QRadar ein Ticket an ldap/ an. Da der DC keinen Dienstprinzipalnamen (SPN) mit diesem Namen hat, gibt er einen KRB_ERR_S_PRINCIPAL_UNKOWN-Fehler zurück. Gemäß dem Kerberos-Protokoll soll QRadar die Authentifizierung an dieser Stelle verweigern. Eine Netzwerkerfassung zeigt jedoch, dass eine LDAP-Anforderung auch nach dem Fehler geöffnet und sofort von QRadar zurückgesetzt wird. Anschließend kann sich der Benutzer anmelden. Wir schließen daraus, dass QRadar die Authentifizierung sogar vor Abschluss des Kerberos-Anwendungsaustauschs als erfolgreich betrachtet. Dies kann leicht ausgenutzt werden. Als Angreifer können wir direkt nach dem Spoofing des AS_REP ein KRB_ERR_S_PRINCIPAL_UNKOWN senden und QRadar veranlassen, eine Authentifizierung mit einem Passwort unserer Wahl zu akzeptieren. Der Angriff ist unten dargestellt.

Ein zusätzlicher Fehler in QRadar führt dazu, dass es die Authentifizierung von AD für einen Benutzer anfordert, der nicht unbedingt vorhanden ist. QRadar verfügt über einen integrierten lokalen Administratorbenutzer. Es stellt sich heraus, dass QRadar beim Versuch der Authentifizierung mit dem Admin-Benutzer zuerst versucht, sich mit Kerberos beim DC zu authentifizieren. Dieser Benutzername muss im AD nicht existieren. Dies erleichtert den Angriff, da der Benutzername dem Angreifer im Voraus bekannt ist.

Darüber hinaus könnte dieser Fehler als eigenständige Schwachstelle betrachtet werden. Unabhängig von KDC-Spoofing kann ein Angreifer, wenn er Berechtigungen zum Erstellen von Benutzern in AD erhalten kann, z. B. durch Übernahme eines Helpdesk-Kontos, einen Benutzer namens admin in AD erstellen. Dann kann der Angreifer diesen Benutzer verwenden, um sich bei QRadar zu authentifizieren.

Ausbeutung

Da wir nun wussten, dass QRadar anfällig ist, simulierten wir einen Angriff, indem wir den Datenverkehr zwischen QRadar und dem KDC (in diesem Fall ein Domänencontroller) auf Port 88 (dem Kerberos-Port) zu unserem eigenen Windows-Server umleiteten. Wir haben eine gefälschte Domäne auf dem Windows-Server eingerichtet und sichergestellt, dass in der echten Domäne ein Benutzer mit demselben UPN wie der QRadar-Administrator vorhanden ist. Wir haben das Passwort dieses Benutzers in der gefälschten Domäne auf „1“ konfiguriert.

Wir haben dann folgende Situationen ausprobiert:
– Normale Anmeldung (Datenverkehr nicht umgeleitet) – wie erwartet gelang es uns, uns mit dem ursprünglichen Passwort des Administrators anzumelden. Beim Versuch mit dem Passwort „1“ ist die Anmeldung fehlgeschlagen.
– Anmeldung mit umgeleitetem Datenverkehr zu unserem gefälschten DC – Anmeldung mit dem ursprünglichen Passwort des Administrators schlug fehl, aber die Anmeldung mit dem Passwort „1“ funktionierte.

IBMs Minderung

Der Ansatz von IBM zur Minderung dieser Schwachstelle ist einfach und sicher. Da mit LDAPS genau dieselbe Funktionalität der Authentifizierung bei QRadar erreicht werden kann, besteht die empfohlene Risikominderung darin, einfach von der Kerberos- zur LDAPS-Authentifizierung zu wechseln. Danach sollten Sie den Patch von IBM installieren. Der Patch überprüft, ob die Authentifizierung tatsächlich auf LDAPS eingestellt ist, und schlägt fehl, wenn Sie noch nicht zur LDAPS-Authentifizierung gewechselt haben. Damit soll sichergestellt werden, dass Ihr System nach dem Patch sicher ist.

Wenn du benutzt hast Silverfort Um die Authentifizierung bei Ihrem QRadar zu sichern, müssen Sie auch die aktualisieren Silverfort Richtlinie für QRadar zum Schutz der LDAPS-Authentifizierung anstelle der Kerberos-TGT-Anforderung.

Prävention und Minderung

Minderungsschritte für Sicherheitsexperten

1. Authentifizierung wechselnin Ihrem QRadar von Kerberos zu LDAPS
2. Aktualisieren Sie Ihr QRadar auf eine Fixed-Version
3. Aktualisieren Sie Ihre Silverfort Richtlinie für QRadar entsprechend
4. Überwachen Sie kontinuierlich Ihre Kerberos-Authentifizierung. Suchen Sie nach Ressourcen, die nur AS_REQ anfordern. Wenn es keine TGS_REQs gibt, ist dies eine rote Flagge.
5. Benutzen SilverfortDas Open-Source-Tool von um die Authentifizierungsprotokolle nach Diensten zu durchsuchen, die keine Diensttickets anfordern.
6. Siehe Entwicklerempfehlungen für alle intern entwickelten Anwendungen, die Kerberos implementieren, und Systeme, die Sie selbst konfiguriert haben.

Als ein Entwickler

Wir empfehlen einige Schritte, um sicherzustellen, dass Ihre Lösung nicht anfällig für KDC-Spoofing ist:
1. Überprüfen Sie, ob für die Implementierung von Kerboros ein Kennwort oder eine Schlüsseltabelle erforderlich ist: Um den DC zu validieren, müssen Sie eine Art gemeinsames Geheimnis verwenden. Wenn Ihre Lösung die Konfiguration einer Keytab-Datei nicht ermöglicht oder a Dienstkonto Wenn Sie kein Passwort eingeben, ist die Anwendung sicherlich anfällig für KDC-Spoofing.
2. Wireshark ausführen – Verwenden Sie Wireshark, um zu sehen, welche Kerberos-Anforderungen während der Authentifizierung gesendet werden. Wenn es kein TGS_REQ gibt, ist es eine rote Fahne.
3. Wenn Sie selbst ein Authentifizierungsprotokoll implementieren möchten, müssen Sie die Protokoll-RFCs sorgfältig befolgen. Wir empfehlen, den einfacheren Weg zu gehen und eine vorhandene Implementierung dieser Protokolle zu verwenden.
4. Verwenden Sie Bibliotheken von Drittanbietern ordnungsgemäß – einige Bibliotheken von Drittanbietern erfordern eine spezielle Konfiguration, um KDC-Spoofing zu vermeiden. Beispielsweise muss für eine allgemeine Bibliothek namens pam-krb3, die für Kerberos verwendet wird, eine Schlüsseltabelle konfiguriert sein, damit sie ordnungsgemäß funktioniert. Hier ist der relevante Absatz aus ihrer Dokumentation (https://github.com/rra/pam-krb5/blob/master/README.md)

Struktur & Organisation
Wir haben eine weitere KDC-Spoofing-Schwachstelle entdeckt und hoffen, bald darüber schreiben zu können, aber nicht bevor der Anbieter einen Patch veröffentlicht. Bis dahin bleiben Sie dran.

Hintergrund

Eine Übersicht über das Kerberos-Protokoll

Das Kerberos-Authentifizierungsprotokoll wurde in den 1980er Jahren von Steve Miller und Clifford Neuman entwickelt. Es ermöglicht Single Sign-On (SSO) in einem verwalteten Netzwerk Active Directory (AD)-Implementierung hat es zum primären Authentifizierungsprotokoll für lokale Unternehmensumgebungen gemacht.
Das Protokoll besteht aus drei Austauschvorgängen, um eine gegenseitige Authentifizierung für den Benutzer und den Server bereitzustellen, auf die zugegriffen wird. Wenn sich der Benutzer anmeldet, gibt er seine Anmeldeinformationen ein und der Austausch des Authentifizierungsdienstes (AS) findet statt. Der Benutzer erhält ein Ticket Granting Ticket (TGT), das später verwendet wird, um Tickets für bestimmte Dienste während des Ticket Granting Service (TGS) Exchange zu erhalten. Das Ticket wird dann während des Client/Server-Austauschs verwendet, um die Authentifizierung abzuschließen:

1. Authentifizierungsdienst (AS)-Austausch

Während des AS-Austauschs authentifiziert sich der Benutzer beim Key Distribution Center (KDC). Im Gegenzug erhält der Benutzer das Ticket und den Schlüssel, die erforderlich sind, um sich bei Diensten im Netzwerk zu authentifizieren, ohne die Anmeldeinformationen erneut eingeben zu müssen. Wenn der Benutzer die Anmeldeinformationen zum ersten Mal eingibt, sendet der Client eine AS_REQ an die Authentifizierungsdienstfunktion (AS) des KDC. Die AS_REQ ist eine vom Hauptschlüssel signierte Nachricht, die eine Funktion des Passworts des Benutzers ist. Der Authentifizierungsdienst, der Teil des KDC ist, verifiziert die AS_REQ anhand des Hauptschlüssels, der auch dem KDC zur Verfügung steht. Nach der Validierung von AS_REQ gibt das KDC ein AS_REP zurück, das einen Anmeldesitzungsschlüssel und ein Ticket-Granting Ticket (TGT) enthält, das mit dem Schlüssel des KDC verschlüsselt ist. Die AS-Börse wird unten umrissen. Das TGT wird von der TGS-Börse verwendet, um Zugang zu bestimmten Diensten zu erhalten.

2. Ticket-Granting Service (TGS)-Austausch

Wenn der Benutzer versucht, auf einen Dienst im Netzwerk zuzugreifen, sendet der Benutzer eine TGS_REQ an die Ticket Granting Server (TGS)-Funktion des KDC. Diese Nachricht wird mit dem Anmeldesitzungsschlüssel verschlüsselt, der während des AS-Austauschs abgerufen wird. Die TGS_REQ wird von der TGS verifiziert, die dann eine TGS_REP zurücksendet. Der TGS_REP enthält einen Dienstsitzungsschlüssel und ein Dienstticket, das mit dem Hauptschlüssel des Servers verschlüsselt ist, der den Dienst hostet. Der Hauptschlüssel des Servers in einem Unix-basierten System wird in einer Datei konfiguriert, die Keytab-Datei genannt wird. Der Hauptschlüssel des Servers in einem Mitgliedsserver wird vom Kennwort des Computerkontos abgeleitet. Die TGS-Börse ist unten beschrieben.

3. Client/Server-Austausch

Jetzt hat der Client alles, was er braucht, um sich beim Dienst zu authentifizieren. Der Client sendet eine AP_REQ an den Dienst, die mit dem Dienstsitzungsschlüssel verschlüsselt ist. Der Dienst entschlüsselt den Dienstsitzungsschlüssel, um die AP_REQ zu validieren. Dann gibt der Server eine AP_REP-Nachricht zurück und die Authentifizierung ist abgeschlossen. Der Client-Server-Austausch wird im Folgenden beschrieben:

Spoof-Proof-Protokoll

Wenn das Kerberos-Protokoll korrekt implementiert ist, kann ein Angreifer, der versucht, sich als KDC auszugeben, die Authentifizierung nicht umgehen. Denn selbst wenn ein Angreifer erfolgreich eine gültige AS_REP als Antwort auf eine gekaperte AS_REQ erstellt, wird der Angreifer niemals in der Lage sein, ein gültiges Dienstticket zu entwickeln. Da das Dienstticket mit dem Serverschlüssel verschlüsselt ist, einem Schlüssel, den der Angreifer nicht hat, wäre das unmöglich.

Was ist KDC-Spoofing?

Im Jahr 2000 berichtete Dug Song a Verwundbarkeit das betrifft das Kerberos-Protokoll (Lied, Dug.2000. Kerberos KDC-Spoofing-Schwachstelle. 28. August.).
Er entdeckte, dass bestimmte Implementierungen und Konfigurationen von Kerberos-Clients den Client/Server-Austausch nicht ausführen und die Authentifizierung basierend auf dem Erfolg des vorherigen Austauschs zulassen. Leider ist dieses Verhalten nicht sicher und kann von einem Angreifer ausgenutzt werden. Ein Angreifer, der in der Lage ist, die Kommunikation zwischen dem Client und dem DC zu kapern, kann die folgenden Schritte unternehmen:
1. Erstellen Sie ein gefälschtes KDC.
2. Beschaffen Sie sich einen Benutzernamen, der berechtigt ist, auf den Dienst zuzugreifen, den Sie angreifen möchten.
3. Erstellen Sie einen Benutzer im gefälschten KDC mit einem Passwort nach Wahl des Angreifers. Nennen wir dieses Passwort zur Demonstration „1“.
4. Authentifizieren Sie sich beim Dienst mit dem erhaltenen Benutzernamen und dem Passwort „1“.
5. Entführen Sie die Kommunikation vom Client zum DC und leiten Sie sie zum gefälschten KDC um.
6. Geben Sie während des AS-Austauschs einen AS_REP zurück, der dem Kennwort „1“, dem gefälschten KDC-Schlüssel und einem gefälschten Anmeldesitzungsschlüssel entspricht.
7. Geben Sie während des TGS-Austauschs alle TGS_REP zurück.
8. Der Client akzeptiert die Authentifizierung, ohne einen Anwendungsaustausch durchzuführen.

Die KDC-Spoofing-Angriffe gehen davon aus, dass der Angreifer den Datenverkehr zum und vom KDC kapern und im Namen des KDC antworten kann. Dies kann mit einer Vielzahl von Techniken erfolgen. Befindet sich der Angreifer beispielsweise im selben physischen Netzwerksegment wie der Client, kann er einen ARP-Spoofing-Angriff ausführen, wie in Netzwerksicherheits-Hacks (Lockhart 2007). Ein weiterer möglicher Ansatz besteht darin, ein Netzwerkgerät wie einen Switch oder Router zu übernehmen und von dort aus die Kommunikation zu steuern.