Kerberos

Kerberos

Einleitung

Kerberos ist ein Netzwerkauthentifizierungsprotokoll. In seiner ersten Version wurde Kerberos 1978 durch Steven Miller und Clifford Neumann entwickelt. Die aktuelle Version 5 des Protokolls wurde im RFC 4120 [1] spezifiziert.

In Windows-Domänen kommt Kerberos seit Windows 2000 zum Einsatz. Microsoft hat hierbei die Kerberos Implementierung erweitert, dabei aber die Kompatibilität zu anderen Kerberos 5 Implementierung aufrechterhalten. Hierdurch wird die Komptabilität zu anderen Betriebssystemen gewährleistet. Entsprechend können somit auch MacOS oder Linuxsysteme in eine Windows-Domäne integriert werden. [2]

Komponenten

Kerberos besteht aus 3 Komponenten:

Key Distribution Center:

  • Prüft die Identität des Benutzers
  • Stellt Kerberos Tickets für den Benutzer aus

Authentication Service

  • Authentifiziert und erlaubt Zugriff auf Ressourcen

Ticket Granting Service

  • Stellt Kerberos Tickets für den Zugriff auf Ressourcen aus

Im Regelfall liegen alle drei Komponenten auf dem Windows-Domain-Controller.

Authentifizierung mit Kerberos

Logon Request (AS_REQ)

Der Benutzer gibt am Login Bildschirm seine Eingabedaten ein. Der Kerberos Authentifizierungsprovider erstellt aus dem eingegebenen Passwort einen NTLM-Hash und verschlüsselt damit den aktuellen Timestamp. Nun wird der Benutzername im Klartext und der verschlüsselte Timestamp an den Authentication Service gesendet.

Ticket Granting Ticket (AS_REP)

Der Authentication Service versucht nun den verschlüsselten Timestamp mit dem NTLM-Hash, der im Active Directory hinterlegt ist zu entschlüsseln. Das Ergebnis sollte dann ein Timestamp sein, der nicht mehr als 5 Minuten vom gegenwertigen Timestamp abweicht. Handelt es sich um einen legitimen Logon Request, stellt der Authentication Service ein sogenanntes „Ticket Granting Ticket“ (TGT) aus. Dieses Ticket beinhaltet neben dem Benutzernamen noch weitere Informationen, wie z.B. das Ablaufdatum. Das TGT wird mit dem Passwort-Hash des krbtgt-Accounts verschlüsselt. Zur Sicherstellung der Datenintegrität kann ein TGT durch keinen Benutzer eingesehen noch verändert werden. Um eine synchrone Verschlüsselung zwischen einem Client und dem Domain-Controller zu ermöglichen, sendet der Authentication Service noch einen sogenannte „Ticket Granting Service Session Key“ an den Benutzer. Mithilfe dieses Keys kann eine Vertrauliche Kommunikation realisiert werden. Um die Vertraulichkeit und Authentizität des Keys sicherzustellen, wird dieser mit dem NTLM-Hash des Benutzers vor der Übertragung verschlüsselt.

Client-Server-Authentifizierung durch Kerberos

Service Ticket

Möchte nun der Client eine bestimme Ressource nutzen, muss dieser mit dem Ticket Granting Service kommunizieren. Hierzu sendet der Client den Namen des Servers, den Diensttyp, einen Timestamp (verschlüsselt mit dem Session Key) und seinen Benutzernamen an den Ticket Granting Service. (TGS_REQ)

Der Client erhält nun ein Service Ticket, welches den Benutzer, ein Timestamp und einen Service Session Key beinhaltet. Mithilfe des Service Session Keys wird die Kommunikation mit dem Application Server, auf dem der gewünschte Dienst läuft, realisiert. Zur Sicherung des Service Tickets, ist dieses mit dem Hash des Maschinen Accounts des Application Servers verschlüsselt, welcher im Active Directory hinterlegt ist. (TGS_REP)

Application Server

Der Client wendet sich nun an den Application Server und sendet diesem das Service Ticket, seinen Benutzernamen und ein Timestamp, der mit dem Service Session Key verschlüsselt ist. (AP_REQ)

Plausibilitätsprüfung und die optionale Mutual Authentication

In diesem Schritt authentifiziert sich der Application Server beim Client. Dazu validiert dieser zuerst das Service Ticket des Clients mit dem Passwort-Hash seines Maschinen Accounts. Ist das Service Ticket valide, extrahiert der Application Server den Service Session Key, um eine verschlüsselte Kommunikation mit dem Client zu etablieren.

Optional: Um seine eigene Identität zu beweisen, sendet der Application Server einen Timestamp verschlüsselt mit dem Service Session Key (AP_REP). Damit beweist der Application Server seine Identität, weil nur dieser seinen Passwort-Hash zum Entschlüsseln nutzen kann und damit an den Session Key gelangen konnte.

Verbindung

Nun kann eine Verbindung in beide Richtungen aufgebaut werden, bei der beide sich authentifiziert haben und ihre Nachrichten verschlüsseln können.

Vorteile von Kerberos

Während andere Netzwerkauthentifizierungen auf der Übermittlung von Passwörtern beruht, wird beim korrekten Einsatz von Kerberos darauf verzichtet. Dieses reduziert die Gefahr passwortbasierter Angriffe (z.B. durch Netzwerksniffer oder Brute-Force-Angriffe). Des Weiteren wird hierdurch das sogenannte Single-Sign-On ermöglicht. Entsprechend diesem kann ein einmalig authentifizierter Nutzer (ein gültiges Service Ticket wurde erstellt) alle Ressourcen eine Domäne, ohne weitere Authentifizierungsvorgänge, nutzen.

Forensische Betrachtung

Bekannte Angriffe

Besondere Beachtung bei der Durchführung von Angriffen auf Kerberos findet das Tool Mimikatz. Damit ist es möglich verschiedenste Angriffe durchzuführen. Dazu zählen:

  • Pass-The-Hash [3]
  • Pass-The-Ticket:

Pass-the-Ticket ist eine Technik zum Diebstahl von Anmeldeinformationen, die es Angreifern ermöglicht, gestohlene Kerberos-Tickets zu verwenden, um sich bei Ressourcen (z. B. Dateifreigaben und anderen Computern) als ein Benutzer zu authentifizieren, ohne das Passwort dieses Benutzers zu kompromittieren. Diese Technik wird häufig von Angreifern verwendet, um sich lateral durch das Netzwerk einer Organisation zu bewegen, während nach Möglichkeiten zur weiteren Privilege Escalation gesucht wird Sowohl TGS-Tickets als auch TGT-Tickets können von Angreifern gestohlen und wiederverwendet werden. Auch ohne administrative Berechtigungen kann ein Angreifer das TGT und alle TGS-Tickets für den aktuell genutzten Benutzer erhalten. Mit administrativen Rechten kann ein Angreifer den LSASS-Prozess „dumpen“ und alle TGTs und TGS-Tickets erhalten, die auf dem System zwischengespeichert sind.

  • Golden Ticket:

Ein goldenes Ticket im Active Directory gewährt dem Inhaber unbegrenzten Zugriff in der Domäne. Die Sicherheit des Kerberos-Protokolls beruht auf der Verwendung von gemeinsam genutzten Geheimnissen zum Verschlüsseln und Signieren von Nachrichten. Einige dieser Geheimnisse sind dem Key Distribution Center (KDC) und den Clients bekannt, aber vor allem eines ist nur dem KDC bekannt: Das Geheimnis des krbtgt-Benutzers, dessen Kennwort-Hash zum Signieren oder Verschlüsseln von Kerberos-Tickets verwendet wird, die vom KDC ausgestellt werden. Sobald ein Angreifer den krbtgt-Hash kompromittiert hat, ist er im Besitz des goldenen Tickets. Damit kann ein Angreifer Kerberos-Tickets erstellen und somit z. B. Tickets für Benutzer ausstellen, die nicht existieren, Benutzer zu Gruppen hinzufügen, denen sie nicht angehören, oder Tickets mit einer Lebensdauer ausstellen, die weit über dem konfigurierten Maximum liegt.

  • Silver Ticket:

Ein Silver-Ticket-Angriff ähnelt vom Konzept her einem Golden-Ticket und beinhaltet die Kompromittierung von Anmeldeinformationen und den Missbrauch des Designs des Kerberos-Protokolls. Im Gegensatz zu einem goldenen Ticket - das einem Angreifer uneingeschränkten Zugriff auf die Domäne gewährt - erlaubt ein silbernes Ticket einem Angreifer jedoch nur das Fälschen von TGS-Tickets (Ticket-granting Service) für bestimmte Dienste. TGS-Tickets sind mit dem Passwort-Hash für den Dienst verschlüsselt - wenn also ein Angreifer den Hash für ein Dienstkonto stiehlt, kann er TGS-Tickets für diesen Dienst fälschen. Auch wenn der Anwendungsbereich kleiner sein mag, ist es immer noch ein mächtiges Werkzeug, das einen dauerhaften und heimlichen Zugriff auf Ressourcen ermöglicht. Da nur der Passwort-Hash des Dienstkontos benötigt wird, ist es auch wesentlich einfacher auszuführen als ein Golden Ticket.

Erkennung von Mimikatz

Um Cyber-Angriff durch Mimikatz (beispielsweise gegen das Netzwerkauthentifizierungsprotokoll Kerberos) frühzeitig zu erkennen und zu verhindern, besteht der Bedarf dieses zu identifizieren. Zur Erkennung von Mimikatz können verschiedene IT-Sicherheitsmechanismen eingesetzt werden. Wesentliche Erkennungsmechanismen werden nachfolgend beispielhaft dargestellt [4].

   import yara
   rules = yara.compile(filepath=‘kiwi_passwords.yar‘)
   matches = rules.match(‘Arbeitsspeicher_Dump‘)
   print(matches)
  • Auswertung von Logdateien, in denen das Ausführung von Mimikatz-Binaries festgehalten wird. Hierfür kann der Windows System Monitoring Service Sysmon verwendet werden, welches die lsass.exe überwacht. Um eine entsprechende Überwachung mit Sysmon zu erreichen, muss dieser Service installiert werden und eine entsprechende xml-Datei zur Erkennung von Mimikatz Befehlen angelegt werden. Diese xml Dateien dienen der Konfiguration von Sysmon.
  • Nutzung von Honey-Hashes oder Honey-Tokens. Honey-Hashes sind Hashes, die extra abgelegt werden, damit ein Angreifer diese entdeckt und versucht zu nutzen, um sich Zugriff auf Ressourcen zu verschaffen. Wenn der Angreifer diese Honey-Hashes dann nutzt, wird seitens des Angegriffenen eine Alarmierung ausgelöst. Durch den Alarm wird klar, dass im internen Netz ein ungewollter Zugriff erfolgt und es können forensische Methoden angewandt werden, um diesen Vorfall aufzuklären.


Quellen