Kerberos ist ein Authentisierungsprotokoll, das auch in Microsoft Windows zur Benutzerauthentisierung eingesetzt wird. Oliver Kunz erklärte in seinem Labs vom 24. Juli 2014 die Grundlagen zu Kerberos. In diesem Labs stelle ich zwei Angriffe gegen Kerberos vor, die Schwachstellen bei der Ausstellung von Tickets ausnutzen. Um diese Angriffe nachvollziehen zu können, hilft es zu verstehen, wie ein Kerberos Ticket ausgestellt wird.

Ausstellung von Kerberos Tickets

Der Vorgang lässt sich unter Windows in fünf Schritte zusammenfassen:

1. Authentication Service Request (AS-REQ): Ein Client stellt eine Anfrage für ein Ticket-Granting Ticket (TGT) an den Dienst Key Distribution Center (KDC). In der Initialanfrage wird der UTC-Zeitstempel mit einem Long-Term Key (normalerweise Passwort des Benutzers) verschlüsselt. Beim Login generiert Windows für den Benutzer Long-Term Keys mit den folgenden Verschlüsselungsalgorithmen (Interessantes Detail, der NTLM-Hash entspricht dabei dem Wert des RC4-HMAC Hashs Kerberos):
   • RC4-HMAC
   • AES128-CTS-HMAC-SHA1-96
   • AES256-CTS-HMAC-SHA1-96
2. Authentication Service Response (AS-REP): Die Anfrage wird vom KDC geprüft, die Entschlüsselung erfolgt mit dem im Active Directory (AD) hinterlegten Long-Term Key. Nach der erfolgreichen Überprüfung stellt der KDC das TGT aus. Das TGT verfügt über eine beschränkte Laufzeit und wird mit dem Long-Term Key des Benutzers krbtgt verschlüsselt. Das TGT enthält innerhalb eines sogenannten Privilege Attribute Certificate (PAC) unter anderem Informationen zur Benutzeridentität wie die Zugehörigkeit zu Gruppen.
3. Ticket-Granting Service Request (TGS-REQ): Wenn der Client nun auf eine Ressource (zum Beispiel CIFS, RPC, Scheduler, WS-MAN) zugreifen will, muss dazu eine weitere Anfrage gestellt werden. Der Client beantragt beim KDC ein weiteres Ticket namens Ticket-Granting Service (TGS) für den Zugriff auf eine beliebige Ressource. Diese Anfrage enthält unter anderem das vorher ausgestellte TGT sowie den Namen des Servers, der die gewünschte Ressource zur Verfügung stellt.
4. Ticket-Granting Service Response (TGS-REP): Das in der Anfrage TGS-REQ mitgesendete TGT wird durch den KDC entschlüsselt und die PAC-Informationen in das für den Dienst ausgestellte Ticket (TGS) kopiert. Der Benutzer erhält dann dieses Ticket und leitet es an den Zielserver weiter. Das Ticket wird dabei mit dem Long-Term Key des Zielservers verschlüsselt.
5. Application Server Request (AP-REQ): Der Benutzer leitet das Ticket an den Zielserver weiter. Dieser entschlüsselt das Ticket und übernimmt die PAC-Informationen innerhalb des Tickets um die Zugriffsrechte des Benutzers zu prüfen. Dabei werden die PAC Informationen übernommen ohne diese nochmals beim KDC zu verifizieren (aus Performancegründen). Wenn die Überprüfung erfolgreich war, erhält der Client Zugriff auf die gewünschte Ressource.

Ein Artikel des Security Consultants Mike Pilkington behandelt die Ausstellung eines Tickets detailliert und stellt Schwachpunkte in den Schritten vor. Weitere Informationen können im Microsoft TechNet Artikel How the Kerberos Version 5 Authentication Protocol Works nachgeschlagen werden.

Angriff 1: MS14-068

Am 19. November 2014 veröffentlichte Microsoft ausserhalb des Patchday-Zyklus das Security Bulletin MS14-068. Das Bulletin handelt von einer Schwachstelle in Kerberos, die es einem Angreifer ermöglicht, seine Rechte bis auf Stufe Domänen-Administrator zu erweitern.

In einer Testumgebung habe ich ein mögliches Angriffsszenario nachgestellt.

Ein Benutzer, sein Account ist Mitglied der Gruppe Domain Users, versucht, auf einem domainintegrierten Windows-7-Client seine Rechte zu erweitern. Der Account hat keine lokalen Administratorenrechte. Der Angriff kann auch ausserhalb einer Domäne ausgeführt werden, wie Dave Kennedy, Gründer und CEO von Trustedsec, Schritt für Schritt demonstrierte.

Der vorgestellte Angriff basiert auf dem Python Kerberos Exploitation Kit. Mit PyKEK wird durch die Ausnutzung der Schwachstelle ein Kerberos-Ticket ausgestellt, das einem beliebigen Domänenbenutzer die Berechtigungen der folgenden Gruppen bescheinigt:

• Domain Users (RID 513)
• Domain Admins (RID 512)
• Schema Admins (RID 518)
• Enterprise Admins (RID 519)
• Group Policy Creator Owners (RID 520)

Für diesen Angriff werden folgende Daten benötigt:

• Accountname
• Passwort des Accounts respektive NTLM-Hash
• Sicherheitsidentifikator (SID) des Accounts

Der SID des eigenen Accounts kann mittels des Befehls whoami /USER abgefragt werden. Das folgende PowerShell-Beispiel ermöglicht es zudem auch SIDs von anderen Accounts abzufragen.

Nachdem der SID des Accounts bekannt ist, kann PyKEK ausgeführt werden:

Zuerst führt PyKEK eine Anfrage AS-REQ durch, fordert aber im Gegensatz zu einer normalen Anfrage ein TGT ohne PAC an. PyKEK nimmt das TGT vom KDC (Schritt AS-REP) und generiert dazu ein PAC mit den aufgezählten Gruppenidentifikatoren. Das erhaltene TGT und der generierte PAC werden als Bestandteil für die Anfrage TGS-REQ verwendet. Der verwundbare KDC übernimmt dann diese Information und stellt ein TGS aus, das dem Account nun Rechte auf der Stufe von Domänen-Admins gibt. Dieses TGS wird von PyKEK in eine Datei extrahiert und kann so weiter verwendet werden.

Mit der Hilfe von mimikatz wird das Ticket in bestehende Session des Benutzers geladen.

Durch den Import des Tickets ist der Account während dieser Session Mitglied der Gruppe Domain Admins und kann so unter anderem auf administrative Freigaben eines Domain Controllers zugreifen.

Als Gegenmassnahme sollte umgehend der von Microsoft veröffentlichte Patch MS14-068 installiert werden.

Angriff 2: Golden Ticket

Im zweiten Angriffsszenario geht es darum ein Kerberos-Ticket zu erstellen, das einen Benutzer zum Mitglied der Gruppe Domain Admins macht und zehn Jahre lang gültig ist: ein sogenanntes Golden Ticket.

Der Angriff wird wiederum auf einem domainintegrierten Client mit einem Benutzer ohne lokale Administratorenrechte durchgeführt. Die Anforderungen für diesen Angriff sind wesentlich höher als beim ersten simulierten Angriff: Um ein solches Ticket zu erstellen, wird der NTLM-Hash des Accounts krbtgt benötigt. Dieser Account wird zur Ausstellung von Kerberos-Tickets verwendet und wird während einer AD Installation erstellt. Ein Angreifer kann den NTLM-Hash bei einem erfolgreichen Angriff auf einen Domain Controller (per Hashdump) oder aus einem (ungesicherten) Backup extrahieren. Das Passwort des Accounts krbtgt wird in der Regel bei der Erstellung einer Domäne gesetzt und selten bis gar nicht mehr geändert. Ein Angreifer kann daher auch ein Backup verwenden, das einige Jahre alt ist.

Das Tool mimikatz wird für die Erstellung eines Golden Tickets eingesetzt. Der Angriff benötigt folgende Daten:

• NTLM-Hash des Passworts des Accounts krbtgt
• Name der Domain
• SID der Domain

Der Befehl kerberos::golden generiert ein Kerberos-Ticket, das einen Account als Mitglied mehrerer Administratoren Gruppen ausweist. Mit den vorhandenen Informationen kann ein beliebiges Ticket ausgestellt werden. Analog zum ersten Angriff hat der Account, durch das Importieren des Golden Tickets in die bestehende Session, die Rechte eines Domain Admins und kann somit auf administrative Freigaben des DC zugreifen. Der folgende Screenshot zeigt das Golden Ticket als geladenes Ticket in der Session:

Die Hauptmassnahme gegen den Golden-Ticket-Angriff ist der Schutz der Credentials des Accounts krbtgt. Das Dokument Mitigating Service Account Credential Theft on Windows, das in Zusammenarbeit von HD Moore (Rapid7), Joe Bialek (Microsoft) und Ashwath Murthy (Palo Alto Networks) entstanden ist, beschreibt wie die Konfiguration des DC gehärtet werden kann. Spezifische Massnahmen gegen den Angriff enthält das Dokument Protection from Kerberos Golden Ticket des CERT-EU. Falls die Credentials des Accounts krbtgt kompromittiert wurden, sollte das Passwort des Accounts zweimal zurückgesetzt werden, damit allenfalls erstellte Golden Tickets ungültig werden. Microsoft veröffentlichte am 11. Februar 2015 in dem Blogartikel KRBTGT Account Password Reset Scripts now available for customers ein Skript zur Passwortänderung des Accounts krbtgt.

Welche Gegenmassnahmen gibt es?

Nebst den beiden vorgestellten Beispielen gibt es weitere Angriffe gegen Kerberos. In der Präsentation Abusing Microsoft Kerberos an der Konferenz black hat USA 2014 haben die Sicherheitsforscher Alva “Skip” Duckwall und Benjamin Delpy (Entwickler von mimikatz) zusätzliche Möglichkeiten vorgestellt.

Um sich vor solchen Angriffen zu schützen, gibt es mehrere Gegenmassnahmen:

• Veröffentlichte Sicherheit-Updates möglichst bald installieren
• Konfiguration härten (unter anderem die Unterstützung des RC4-HMAC Algorithmus deaktivieren)
• Regelmässiges Ändern des Passworts des Serviceaccounts krbtgt
• Betrieb durch gezielte Auswertung von Logdateien überwachen

Wenn diese Massnahmen umgesetzt werden, ist es für einen Angreifer viel schwieriger erfolgreiche Angriffe gegen Kerberos durchzuführen.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://blog.gentilkiwi.com/downloads/Abusing-Microsoft-Kerberos-Sorry-You-Guys-Don-t-Get-It.pdf
• http://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/
• http://cert.europa.eu/
• http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf
• http://digital-forensics.sans.org/blog/2014/11/24/kerberos-in-the-crosshairs-golden-tickets-silver-tickets-mitm-more
• http://technet.microsoft.com/en-us/library/cc772815%28v%3DWS.10%29.aspx
• http://www.scip.ch/?labs.20140724
• http://www.scip.ch/?vuldb.68239
• https://community.rapid7.com/docs/DOC-2881
• https://github.com/bidord/pykek/
• https://github.com/gentilkiwi/mimikatz
• https://technet.microsoft.com/library/security/MS14-068
• https://twitter.com/mikepilkington
• https://www.trustedsec.com/december-2014/ms14-068-full-compromise-step-step/