Silverfort Forscher entdecken KDC-Spoofing-Schwachstelle in F5 Big-IP [CVE-2021-23008]

Letztes Jahr haben wir drei Spoofing-Schwachstellen im Key Distribution Center (KDC) gemeldet Cisco ASA, Palo Alto Networks PAN-OS und IBM QRadar. Wir haben erwähnt, dass noch einer kommt, und jetzt das F5 hat einen Fix herausgegebenveröffentlichen wir die vierte KDC-Spoofing-Schwachstelle, die wir identifiziert haben – dieses Mal in Big-IP. Die KDC-Spoofing-Schwachstelle ermöglicht es einem Angreifer, die Kerberos-Authentifizierung beim Big-IP Access Policy Manager zu umgehen, Sicherheitsrichtlinien zu umgehen und uneingeschränkten Zugriff auf sensible Workloads zu erhalten. In einigen Fällen kann dies auch verwendet werden, um die Authentifizierung an der Big-IP-Verwaltungskonsole zu umgehen. Wir haben eng mit F5-Ingenieuren zusammengearbeitet, um dieses Problem zu beheben kürzlich herausgegebener Ratgeber. Dieser Blogbeitrag beschreibt die Schwachstelle und erklärt, wie diese Fehler bei der Implementierung vermieden werden können Kerberosund erörtert Abhilfemaßnahmen für Kunden, die Big-IP und andere Kerberos-basierte Systeme verwenden.

Erläuterung der Schwachstelle

F5 Big-IP Application Delivery Services ist eine Lösung, die Anwendungen sicher und skalierbar bereitstellt. Eine seiner Kernkomponenten ist der Access Policy Manager (APM), der Richtlinien verwaltet und durchsetzt, um sicherzustellen, dass der Zugriff ordnungsgemäß authentifiziert und autorisiert wird. APM wird manchmal auch verwendet, um den Zugriff auf die Big-IP-Verwaltungskonsole zu schützen.

Die Schwachstelle liegt in der Implementierung des Kerberos-Protokolls durch F5. 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.

Kerberos kann als Authentifizierungsprotokoll für die von einer APM-Richtlinie geforderte Authentifizierung verwendet werden. Wenn ein Benutzer über Big-IP auf eine Anwendung zugreift, wird ihm möglicherweise ein Captive-Portal angezeigt und er muss einen Benutzernamen und ein Passwort eingeben. Der Benutzername und das Passwort werden mit dem Kerberos-Protokoll gegen AD verifiziert, um sicherzustellen, dass der Benutzer der ist, für den er sich ausgibt. Daher ermöglicht die Umgehung der Kerberos-Authentifizierung einem Angreifer den Zugriff auf Big-IP-Anwendungen, 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 erschwert. Wenn sich das KDC jedoch nicht beim Server authentifiziert, ist die Sicherheit des Protokolls vollständig gefährdet, was es einem Angreifer, der den Netzwerkverkehr kapert hat, ermöglicht, sich bei Big-IP mit einem beliebigen Passwort zu authentifizieren, sogar mit einem ungültigen.

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

Unten ist ein Screenshot der Anweisungen zum Konfigurieren der AD-Authentifizierung für eine Zugriffsrichtlinie, entnommen aus der F5-Website.

Wenn ein Benutzer nach dieser Konfiguration versucht, sich bei einer App zu authentifizieren, die sich hinter dem Proxy befindet, wird der Benutzer aufgefordert, einen Benutzernamen und ein Kennwort einzugeben. Wenn der Benutzer sein Kennwort eingibt, verwendet das Produkt Kerberos, um sich beim Domänencontroller (DC) zu authentifizieren. APM fordert jedoch kein Dienstticket an und gewährt Zugriff basierend auf einem erfolgreichen AS_REP.
Im Gegensatz zu anderen Szenarien können Sie mit F5 einen Administratorbenutzernamen und ein Kennwort konfigurieren.

Theoretisch könnte dieses Passwort verwendet werden, um den DC zu authentifizieren und die Schwachstelle zu verhindern. Es wird jedoch nicht für diese Zwecke verwendet, sondern nur zum Abrufen von primären oder verschachtelten Gruppen, zum Auffordern des Benutzers zu einer Kennwortänderung oder zum Durchführen einer Komplexitätsprüfung oder eines Zurücksetzens des Kennworts.

Spoofing der Kerberos-Authentifizierung

Hier sind die Schritte, die ein Angreifer unternehmen kann, um einen DC zu spoofen, um diese Art der Authentifizierung zu umgehen. Nehmen wir an, dass wir die Netzwerkkommunikation zwischen Big-IP 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 Big-IP und verwenden den von uns gewählten Benutzer und das Passwort. Big-IP authentifiziert sich mit Kerberos, und wir entführen die Kerberos-Kommunikation und geben einen AS_REP zurück, der dem von uns gewählten Passwort 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 in diesen Phasen die einzige Überprüfung, die auf der Big-IP-Seite durchgeführt wird, auf dem von uns gewählten Passwort beruht, lässt Big-IP die Authentifizierung zu.

Ausbeutung

Wir haben einen Angriff simuliert, indem wir den Datenverkehr zwischen Big-IP und dem KDC (in diesem Fall einem Domänencontroller) auf Port 88 (dem Kerberos-Port) auf unseren eigenen umgeleitet haben Windows Server. Wir haben auf dem Windows-Server eine gefälschte Domäne eingerichtet und sichergestellt, dass es in der echten Domäne einen Benutzer mit demselben UPN wie der Big-IP-Administrator gibt. Wir haben das Passwort dieses Benutzers in der gefälschten Domäne auf „1“ konfiguriert.

Wir haben dann folgende Szenarien ausprobiert:

• Reguläre Anmeldung (Datenverkehr nicht umgeleitet) – wir haben es wie erwartet geschafft, uns mit dem ursprünglichen Passwort des Benutzers 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.

Prävention und Minderung

Minderungsschritte für Sicherheitsexperten

1. Rüsten Sie Ihre Big-IP auf eine feste Version auf
2. Wenn für die von Ihnen verwendete Version von Big-IP keine feste Version verfügbar ist, stellen Sie sicher, dass dies der Fall ist MFA aktiviert.
3. Aktualisieren Sie Ihre Silverfort Richtlinie für Big-IP 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. Verwenden Sie die 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 und selbst konfigurierte Systeme implementieren.

Für 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 Kerberos 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 dies ein rotes Flag.
3. Wenn Sie selbst ein Authentifizierungsprotokoll implementieren möchten, müssen Sie die Protokollspezifikation 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

Ich bin mir sicher, dass dies die letzte KDC-Spoofing-Schwachstelle ist, auf die wir jemals stoßen werden.

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 gemäß dem Hauptschlüssel, 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) Exchange

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. Besorgen Sie sich einen Benutzernamen, der berechtigt ist, auf den Dienst zuzugreifen, den sie angreifen möchten.
3. Erstellen Sie im gefälschten KDC einen Benutzer mit einem vom Angreifer gewählten Passwort. Nennen wir dieses Passwort zum Beispiel „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.

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.

Danksagung

Die Erforschung und Entdeckung dieser Schwachstelle war eine gemeinsame Anstrengung mit Thierry Van Steirteghem, der zum Zeitpunkt der Entdeckung bei Exclusive Networks arbeitete.