Sicherheitsforscher bei Silverfort, Anbieter einer agentenlosen Authentifizierungsplattform, identifizierte eine schwerwiegende Schwachstelle, die es Hackern ermöglichen kann, die Kontrolle über die Cisco Adaptive Security Appliance (ASA) zu erlangen. Betroffen sind alle ASA-Versionen. Nachdem Cisco die Schwachstelle offengelegt hatte, behebt Cisco alle unterstützten Versionen von ASA und veröffentlichte ein Advisory drauf. Der Schwachstelle (CVE-2020-3125) wurde ein CVSS-Risikowert von 8.1 von 10 zugewiesen, was als „Hoch“ gilt. Dies liegt daran, dass die Sicherheitslücke es einem Angreifer ermöglichen kann, die Sicherheitslücke zu umgehen Kerberos Authentifizierung bei Cisco ASA. Silverfort Forscher, denen die Entdeckung der Schwachstelle zugeschrieben wird, sind: Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach.

Cisco hat diese Schwachstelle in allen Versionen von ASA behoben. Wir empfehlen Unternehmen dringend, auf die neuesten ASA-Versionen zu aktualisieren, um sich vor einem Exploit zu schützen.

Dieser Artikel beschreibt die KDC-Spoofing-Schwachstelle und zeigt, wie sie verwendet werden kann, um die Authentifizierung bei Cisco ASA zu umgehen. Es wird erläutert, wie diese Schwachstellen als Entwickler vermieden werden können, der Kerberos implementiert, sowie als Unternehmen, die diese Lösungen bereits in ihren Netzwerken implementiert haben.

Erläuterung der Schwachstelle

Die Schwachstelle liegt in der Kerberos-Implementierung von Cisco. 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.

Cisco verwendet das Kerberos-Authentifizierungsprotokoll in vielen ASA-Schnittstellen – zum Beispiel VPN, das Öffnen von Firewall-Sitzungen und den administrativen Zugriff, entweder über die Webverwaltungskonsole oder über SSH. Daher ermöglicht die Umgehung der Kerberos-Authentifizierung einem Angreifer, die Cisco-Appliance zu übernehmen, ihre Sicherheit zu umgehen und Zugriff auf andere 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 mit einem falschen, bei Cisco ASA authentifizieren kann.

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 meldete Dug Song eine Schwachstelle, die das Kerberos-Protokoll betrifft 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 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.

Wie wir die Schwachstelle in Cisco ASA entdeckt haben

Wir suchten nach einer Möglichkeit, etwas hinzuzufügen Multi-Faktor-Authentifizierung (MFA) für Administratoren, die auf Cisco ASA und Anyconnect VPN zugreifen. Nachdem wir Cisco für die Verwendung von Kerberos als Authentifizierungsprotokoll konfiguriert hatten, untersuchten wir die Authentifizierungsprotokolle Silverfort's Konsole. Silverfort bietet vollständigen Einblick in alle Authentifizierungsaktivitäten im Netzwerk. SilverfortDie Protokolle von zeigten, dass Cisco ASA ein TGT anforderte, ohne ein Serviceticket anzufordern.

Wir gingen zurück zum Konfigurationsleitfaden Cisco. 2007. PIX/ASA: Kerberos-Authentifizierung und LDAP-Autorisierungsservergruppen für VPN-Clientbenutzer über ASDM/CLI-Konfigurationsbeispiel. 30. Juli. ; und sah sich die Parameter an, die zum Konfigurieren der Kerberos-Authentifizierung erforderlich sind:

Wie oben zu sehen ist, gibt es keinen Platz, um das Passwort oder die Keytab-Konfiguration für die Kerberos-Authentifizierung einzugeben. Das Passwort oder die Schlüsseltabelle sind für eine korrekte Implementierung erforderlich, da sie das „Geheimnis“ erstellen, das von Kerberos verwendet wird, um sich auf vertrauenswürdige Weise beim KDC zu authentifizieren. Ohne das „Geheimnis“ kann der Authentifizierung nicht kryptografisch vertraut werden.

Wir haben dasselbe für andere Cisco-Schnittstellen ausprobiert und festgestellt, dass beim Öffnen von Firewall-Sitzungen, bei der administrativen Authentifizierung und sogar bei der Verwendung von SSH für den Zugriff auf die VM dieselbe Schwachstelle besteht. Siehe unter der Kerberos-Spalte in der Tabelle, die die Cisco-Unterstützung für verschiedene Authentifizierungsprotokolle zusammenfasst.

Ausbeutung

Als nächstes wollten wir sehen, ob diese Schwachstelle ausgenutzt werden kann. Dafür haben wir den für den DC bestimmten Kerberos-Verkehr gekapert und auf unseren Server umgeleitet. Anstatt unsere eigene KDC-Logik zu entwickeln, haben wir einfach AD-Domänendienste auf unserem Rogue-Server installiert und unseren Server zu einem Domänencontroller hochgestuft. Da wir kein Administrator der ursprünglichen Domain sind, haben wir natürlich eine neue gefälschte Domain erstellt.

Da wir den Benutzernamen für den Cisco-Administrator in der ersten Domäne (in diesem Beispiel Bob) kennen, haben wir in unserer gefälschten Domäne einen Benutzer namens Bob erstellt. Wir haben das Passwort dieses Benutzers in unserer gefälschten Domain 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 zunächst Ihre Cisco ASA auf eine Fixed-Version und nehmen Sie die erforderlichen Konfigurationsänderungen vor, die im beschrieben sind Cisco-Beratung
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 Silverfort 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 Serviceticket-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 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 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)