Palo Alto Networks hat einen Hinweis zu einer KDC-Spoofing-Schwachstelle in PAN-OS veröffentlicht, die von Palo Alto Networks entdeckt und verantwortungsvoll offengelegt wurde Silverfort Forscher Yoav Iellin, Yaron Kassner machen Rotem Zach. Die Sicherheitslücke betraf alle unterstützten Versionen von PAN-OS und alle Schnittstellen, die Kerberos verwendeten Beglaubigung Profil. Nach der Offenlegung der Sicherheitslücke hat Palo Alto Networks alle unterstützten Versionen von PAN-OS behoben und eine veröffentlicht beratend darüber. Die Sicherheitslücke kann es einem Angreifer ermöglichen, die zu umgehen Kerberos Authentifizierung bei PAN-OS und Zugriff auf die Verwaltungsschnittstellen zu PAN-OS sowie Authentifizierung bei Firewall-Sitzungen über das Captive-Portal.

Diese Schwachstelle ähnelt a KDC-Spoofing-Schwachstelle, die unsere Forscher in Cisco ASA entdeckt haben. Es scheint, dass die Implementierung des Kerberos-Authentifizierungsprotokolls nicht immer korrekt abgeschlossen wird, wodurch Systeme anfällig für Exploits werden.

Palo Alto Networks hat diese Schwachstelle in allen Versionen von PAN-OS behoben. Wir empfehlen dringend, diesen Patch bereitzustellen, um sich vor einem Exploit zu schützen.

Dieser Artikel beschreibt die KDC-Spoofing-Schwachstelle in PAN-OS und zeigt, wie sie verwendet werden kann, um die Authentifizierung zu umgehen, ohne das Passwort zu kennen. Es erläutert, wie diese Schwachstellen als Entwickler vermieden werden können, der Kerberos implementiert, sowie als Unternehmen, die die Kerberos-Authentifizierung für ihre Systeme verwenden.

Erläuterung der Schwachstelle

Die Schwachstelle liegt in der Kerberos-Implementierung von Palo Alto Networks. Kerberos ist das gebräuchlichste Authentifizierungsprotokoll für die lokale Authentifizierung. Aufgrund der Beliebtheit ist es in Unternehmensnetzwerken weit verbreitet Active Directoryund wird gegenüber schwächeren Authentifizierungsprotokollen wie NTLM bevorzugt.

Palo Alto Networks verwendet das Kerberos-Authentifizierungsprotokoll in vielen PAN-OS-Schnittstellen – zum Beispiel SSL VPN, Captive Portal oder Administrator-Login. Daher ermöglicht die Umgehung der Kerberos-Authentifizierung einem Angreifer, Palo Alto Networks Strata zu verwalten, seine Sicherheit zu umgehen und Zugriff auf zusätzliche Netzwerke zu erhalten.

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 kapert hat, mit jedem beliebigen Passwort, sogar einem falschen, bei PAN-OS authentifizieren kann.

Entdecken der Schwachstelle in PAN-OS

Wir entdeckten die Schwachstelle, als wir versuchten, sie hinzuzufügen Silverfort's MFA zu Schnittstellen, die auf dem Kerberos-Protokoll basieren, einschließlich SSL VPN, Captive Portal und Admin Login. Um dies einzurichten, haben wir Kerberos als Authentifizierungsmethode konfiguriert und eine passende MFA-Richtlinie auf der konfiguriert Silverfort Seite. Eine ausführliche Erklärung zum Kerberos-Protokoll und KDC-Spoofing finden Sie am Ende dieses Artikels.
Wie unten zu sehen ist, enthält die Netzwerkerfassung eine AS-REQ und eine AS-REP, aber keine TGS-REQ:

Die Authentifizierung war erfolgreich, obwohl das TGS-REQ vom Protokoll verlangt wird und im Authentifizierungsprozess fehlte. Da wir bereits eine entdeckt haben ähnliche Schwachstelle mit Cisco ASA, wir wollten dies überprüfen.

Wir gingen zurück und überprüften den Palo Alto Networks-Leitfaden zur Konfiguration der Kerberos-Authentifizierung – unten ist ein Screenshot des damaligen Leitfadens:

Wir haben festgestellt, dass wir zu keinem Zeitpunkt des Konfigurationsprozesses eine Keytab oder ein Service-Passwort konfigurieren mussten. PAN-OS bietet eine Option zum Konfigurieren eines Schlüsseltabs, die jedoch optional war. Aber selbst wenn das Keytab konfiguriert war, sahen wir, dass es nicht für den Authentifizierungsprozess an den genannten Schnittstellen verwendet wurde. Ohne Keytab oder Passwort verfügt PAN-OS nicht über die erforderlichen Anmeldeinformationen, um die Authentizität des KDC zu validieren. Das bedeutet, dass PAN-OS anfällig für KDC-Spoofing ist.

Versuch, die Schwachstelle auszunutzen

Da wir nun wussten, dass das PAN-OS anfällig ist, simulierten wir einen Angriff, indem wir den Datenverkehr zwischen PAN-OS und dem KDC, in diesem Fall dem Domänencontroller, auf Port 88 (dem Kerberos-Port) auf unseren eigenen Windows-Server umleiteten. Wir haben eine gefälschte Domäne auf dem Windows-Server eingerichtet und sichergestellt, dass es einen Benutzer mit demselben Benutzerprinzipalnamen (UPN) wie der PAN-OS-Administrator in der echten Domäne gibt. Für dieses Beispiel nennen wir ihn „Bob“. 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) – wir konnten uns wie erwartet mit Bobs ursprünglichem Passwort anmelden. Beim Versuch mit dem Passwort „1“ ist die Anmeldung fehlgeschlagen.
• Anmeldung mit umgeleitetem Datenverkehr zu unserem gefälschten DC – Anmeldung mit Bobs ursprünglichem Passwort schlug fehl, aber Anmeldung mit dem Passwort „1“ funktionierte.

Prävention und Minderung

Minderungsschritte für Sicherheitsexperten

1. Aktualisieren Sie in erster Linie Ihr PAN-OS auf eine feste Version und nehmen Sie die erforderlichen Konfigurationsänderungen vor, die in beschrieben sind Beratung von Palo Alto Networks.
2. Ü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.
3. Verwenden Sie die SilverfortDas Open-Source-Tool von um die Authentifizierungsprotokolle nach Diensten zu durchsuchen, die keine Diensttickets anfordern.
4. Siehe Entwicklerempfehlungen für alle intern entwickelten Anwendungen, die Kerberos implementieren, und Systeme, die Sie selbst konfiguriert haben.
5. Silverfort Kunden, die die Step-up-Authentifizierungsfunktion mit Palo Alto Networks nutzen, sollten ihre aktualisieren Silverfort MFA Richtlinie von einer TGT-Richtlinie zu einer Service-Ticket-Richtlinie nach dem Upgrade ihres PAN-OS.

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 3^rd Parteibibliotheken richtig – etwa 3^rd Party-Bibliotheken erfordern eine spezielle Konfiguration, um KDC-Spoofing zu vermeiden. Beispielsweise muss für eine allgemeine Bibliothek namens pam-krb5, 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)

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 Benutzer anmelden, geben sie ihre 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 ist im Folgenden skizziert:

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, der später Duo Security mitbegründete, a Technik Wird verwendet, um das Kerberos-Protokoll in einigen Situationen zu umgehen:

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 im gefälschten KDC einen Benutzer mit einem vom Angreifer gewählten Passwort. 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 beschrieben 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.