Blog

Einführung in Kerberos - Teil 2

10.4.2021 | 3 minutes read
Share this:

Tags: kerberos

In Teil 1 wurde bereits verschiedene Aspekte von Kerberos beleuchtet, wie das Thema Grundlagen und wie der Benutzer ein Ticket Granting Ticket anfragen kann.

In diesem Teil wird nun das betrachtet, wie ein Benutzer mithilfe der gewonnenen Informationen aus Teil 1 ein Ticket für einen beliebigen Service innerhalb eines Kerberos Netzwerks abfragen kann.

Aktuell verfügt der Benutzer bzw. der LSASS Prozess auf seinem Client über folgende Informationen:

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

Um eine Ticket Granting Service (TGS) Anfrage stellen zu können, wird zunächst der Service Principal Name des Ziels abgefragt. Der Service Principal Name setzt sich zusammen aus:

<service>/<hostnamen>


In unserem Beispiel fragt der Benutzer Homer ein Ticket für die Benutzung seines Clients an. Damit lautet der SPN HOST/CL1.

Damit wird ein sogenannter TGS-REQ an den Domain Controller gesendet. Diese Anfrage besteht aus dem Feld req-body (Request Body) und dem Feld padata (Pre-Authenticaton Data).

TGS-REQ

Der req-body enthält folgendes:

  • Nonce
  • Service Principal Name (SPN) des Ziels
  • Unterstützte Encryption Types

REQ-BODY

Im Feld padata sind einige Flags so wie ein Feld pA-TGS-REQ bzw. ap-req enthalten. pA-TGS-REQ enthält zum einen das TGT im Feld ticket, dass im AS-REP an den Client gesendet wurde, als auch das Feld authenticator.

REQ-BODY

Das Feld authenticator enthält unter anderem die Domäne (crealm), den Benutzername (cname) und wieder einen aktuellen Zeitstempel (ctime). Im Unterschied zum AS-REQ wird dieses Mal der Session Key (HOMER <=> DC) zum Verschlüsseln des Zeitstempels verwendet und nicht das Benutzerpasswort von Homer.

AUTHENTICATOR

Auf dem Domain Controller passiert jetzt ungefähr folgendes:

  1. Entschlüsseln des TGT mit dem Passwort vom KRBTGT Benutzer
  2. Auslesen des Session Keys (Homer <=> DC) aus TGT
  3. Entschlüsseln des authenticator mittels Session Key (Homer <=> DC)
  4. Validieren ob der authenticator korrekt ist
  5. Entschlüsseln des TGT aus dem Feld ticket mit dem Passwort von KRBTGT
  6. Ersetzen des Sessions Keys (HOMER <=> DC) mit einem neuen Session Key (Homer <=> CL1)
  7. Verschlüsseln des Tickets mit dem Passwort von CL1.
  8. Antwort an den Client senden

Das TGS-REP besteht wieder aus zwei Teilen. Einem enc-part und einem ticket (Ticket Granting-Service Ticket).

TGS-REP

Das Feld enc-part ist mit dem Session Key (HOMER <=> DC) verschlüsselt. Das Feld enthält den neuen Session Key (HOMER <=> CL1) im Feld key. Dieser ist diesmal allerdings nicht mit für die Kommunikation mit dem Domain Controller, sondern für die Kommunikation mit dem Zielsystem CL1 gedacht.

ENC-PART

Der Domain Controller übernimmt die Angaben, die im anfragenden Ticket (TGT) sind, blind. Wenn man die Annahme zugrunde legt, dass nur der Domain Controller das TGT erstellen und lesen kann, ist dies auch kein Problem. Was passiert, wenn mehrere Teilnehmer ein TGT erzeugen können, wird Thema eines zukünftigen Blogeintrags.

Das ticket (TGS) besteht aus einem Feld encTicketPart das wiederum das Feld authorization-data und key hat. Das Feld authorization-data enthält das PAC mit allen Gruppen und weitere Daten über den anfragenden Benutzer. Im Feld key ist der selbe Session Key (Homer <=> CL1) wie oben enthalten.

TGS

Dadurch, dass der CL1 dem Domain Controller vertraut, weiß er, wer auch immer den Session Key aus dem Ticket ebenfalls hat, muss auch der Benutzer sein, der im authorization-data Feld dieses Tickets spezifiziert wird.

Im Anschluss an den Austausch dieser vier bzw. sechs Nachrichten (zwei bis vier Nachrichten aus Teil 1) haben wir nun folgende Ausgangssituation.

Der Benutzer (Homer) hat jetzt:

  1. TGT (Verschlüsselt mit KRBTGT Passwort) mit PAC
  2. Session Key (HOMER <=> DC) für weitere Anfragen
  3. TGS (verschlüsselt CL1 Passwort) mit PAC
  4. Session Key (HOMER <=> CL1) für weitere Anfragen

Damit wären alle notwendigen Daten ausgetauscht, damit Homer mit dem CL1 authentifiziert kommunizieren kann und weitere Tickets beim Domain Controller anfragen kann.

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

Quellen