Blog

Einführung in Kerberos - Teil 1

9.4.2021 | 4 minutes read
Share this:

Tags: kerberos

Grundlagen

Kerberos ist ein Protokoll zur verteilten Authentifizierung und wurde in den 80er Jahre am MIT entwickelt. Heutzutage ist das Protokoll den meisten aus dem Umfeld von Microsoft Active Directory bekannt. Dort wird es in der Version 5 mit zahlreichen Microsoft eigenen Erweiterungen eingesetzt.

Kerberos ist ein auf Tickets basiertes Authentifizierungsprotokoll. Es soll das Problem lösen, wie sich verteilte Systeme untereinander Authentifizieren können, ohne dass alle Systeme das gleiche oder die System-Paare jeweils ein eigenes Passwort kennen müssen. In diesem ersten Teil des Blogs soll es um die Grundlagen des Protokolls gehen, wie es funktioniert und wie man mit frei verfügbaren Werkzeugen mehr darüber lernen kann.

Vorrausetzungen

Jeder Benutzer und jeder Computer im Active Directory hat ein eigenes Passwort. Nur dem Domain Controller, genauer gesagt dem Authentication Service, und dem Benutzer/Computer selbst sind dieses Passwort bekannt. Welche Probleme sich daraus ergeben, wenn dem nicht mehr so ist, kommt in einem späteren Blog Eintrag. Weiterhin gibt es einen Benutzer krbtgt dessen Passwort nur dem Domain Controller bekannt ist.

Grundprinzip Kerberos

Kerberos basiert auf zwei Arten von Tickets. Dem Ticket-Granting-Ticket (Analogie: Personalausweis) und dem Ticket-Granting-Service Ticket (Analogie: Bankkarte). Wenn Sie auf die Welt kommen, bekommen Sie Ihren Personalausweis. Mit dem Personalausweis können Sie jederzeit in eine Bank gehen, ein Konto eröffnen und erhalten dann eine Bankkarte. Mit dieser Bankkarte wiederum können Sie an den Automaten ihrer Bank gehen und - sofern vorhanden - Bargeld abheben. Wenn Sie zu einer anderen Bank gehen wollen, dann nehmen Sie ihren Personalausweis, gehen zu einer neuen Bank und eröffnen dort ein Konto. Im Anschluss erhalten Sie wieder eine Bankkarte.

In vielen Blogs wird die Anfrage für das Ticket Granting Ticket (TGT) und einem Service Ticket (TGS) oft zusammen dargestellt. Jedoch wird in der Regel nur ein TGT am Anfang zur initialen Anmeldung erstellt. Das TGT erlaubt es dann, solange es gültig ist, beliebig viele TGS anzufragen.

Authentication Request

Um auf Dienste in einem Active Directory zugreifen zu können, wird zunächst ein Ticket Granting Ticket benötigt. Für die Anfrage wird zunächst ein Authentication Request (AS-REQ) an den Domain Controller gesendet. Der Request enthält den Name des Benutzers (zukünftig Client) der die Anfrage stellt(HOMER@XXXX) und den Namen des Ziels in Form seines Service Principal Name (KRBTGT@XXXX). Zusätzlich werden noch einige Variablen und eine Zufallszahl mitgesendet.

Anfrage nach TGT 1

Im Feld padata (Pre-Authentication Data) teilt der Client dem Server mit, dass das Privilege Attribute Certificate (PAC) in der Antwort enthalten sein soll. Da standardmäßig alle Benutzer in einem Active Directory so konfiguriert sind, dass eine Pre-Authentication für die Anfrage eines TGT notwendig ist, lehnt das KDC die Anfrage zunächst mit der Nachricht KRBKDC_ERR_PREAUTH_REQUIRED ab.

Im Anschluss wird ein zweiter AS-REQ gesendet. Dieses Mal enthält das Feld padata zusätzlich die aktuelle Uhrzeit, die mit dem Passwort des Benutzers “Homer” verschlüsselt ist. Da der Domain Controller das Passwort von Homer kennt, kann er das Feld entschlüsseln und mit der aktuellen Serverzeit vergleichen. Liegt dieser Wert innerhalb der SKEW-Time (5 Minuten) weiß der Domain Controller, dass der Benutzer das Passwort ebenfalls kennt.

Anfrage nach TGT 2

Wenn die Daten validiert werden konnten, sendet der Domain Controller ein Authentication Reply (AS-REP) Paket. Das AS-REP besteht aus zwei Teilen. Dem Feld ticket (dem TGT) und dem enc-part.

Antwort mit TGT

Das Feld enc-part enthält den für die nachfolgenden Anfragen relevanten Session Key (HOMER <=> DC). Dieser wird zusammen mit dem Ticket in der LSASS gespeichert.

Session Key

Mit Mimikatz kann das Ticket zusammen mit dem Session Key wieder ausgegeben werden.

Mimikatz

Das Feld ticket (TGT) wiederum ist für den Benutzer, mit Ausnahme vom Header, nicht lesbar. Es ist mit dem Passwort des Pseudo-Benutzers “KRBTGT@XXXX” verschlüsselt und kann daher auch nur von diesem Benutzer gelesen/geschrieben werden. Das TGT enthält zum einen denselben Session Key wie im enc-part für den Client, als auch das Privileged Attribute Certificate (PAC).

Ticket

Im PAC sind alle Informationen über den Benutzer gespeichert, wie beispielsweise Gruppenmitgliedschaften, Anmeldezeit, Name oder auch der Homefolder.

PAC

Nach Austausch dieser Informationen hat der Benutzer, genauer gesagt der LSASS Prozess auf seinem System, folgende Informationen:

  1. TGT mit PAC (Verschlüsselt mit dem Kennwort vom KRBTGT-Benutzer)
  2. Session Key (HOMER <=> DC) für weitere Anfragen

Damit ist der erste Teil von Kerberos fertig. Im zweiten Teil gehen wir dann auf die Anfrage nach einem Ticket Granting Service Ticket ein.

Wie immer gilt falls ihr Fragen, Anmerkungen oder Verbesserungsvorschläge zu dem Artikel habt, schreibt eine Mail an info@hackmich.net.

Quellen