Haftungsausschluss: Dieser Beitrag dient ausschließlich Bildungs- und Informationszwecken. Die hier gezeigten Informationen und Angriffe dürfen niemals für illegale Zwecke oder auf Systemen, für die keine explizite Erlaubnis eingeräumt wurde, verwendet werden. Solche Handlungen können gegen geltende Gesetze verstoßen und schwerwiegende rechtliche Konsequenzen nach sich ziehen.

Zusammenfassung

Dieser Eintrag behandelt Angriffsvektoren und Besonderheiten des NTLM-Nachfolgeprotokolls Kerberos. Dieses SecCore Essential ist implementiert, wenn die folgenden Punkte erfüllt werden:

  • Es existieren keine hochprivilegierten Accounts, welche ein Service Principal Name (SPN) gesetzt haben
  • Alle Service-Accounts besitzen starke und zufällige Passwörter
  • Pre-Authentication wird für alle Accounts verlangt
  • Keine Systeme sind mit Unconstrained Delegation konfiguriert (ausgenommen Domain Controllers)

Einleitung

Kerberos ist der Nachfolger von NTLM in Microsoft Active Directory-Umgebungen. Bei Kerberos handelt es sich um ein modernes und robustes Protokoll, das Sicherheitsprobleme wie NTLM-Relaying (wie in unserem SMB Security und LDAP Security Blog beschrieben) behebt.

Anstelle des Challenge-Response-Verfahrens von NTLM verwendet Kerberos ein Ticketing-System. Dadurch ist es widerstandsfähiger gegen Angriffe.

  • Ein Account fordert zunächst ein Ticket Granting Ticket (TGT) vom Key Distribution Center (KDC) an. Der Domain Controller fungiert hierbei als Authentifizierungsserver (AS) und überprüft die Anmeldedaten aus der Anfrage.
  • Der Account erhält das TGT vom Authentifizierungsserver. Dieses Ticket berechtigt den Account, Service Tickets (ST) für Ziel-Services anzufordern.
  • Der Account sendet das TGT zu einem Ticket Granting Server (TGS) und erhält ein Service Ticket für den Ziel-Service.
  • Nun kann das Service Ticket zur Authentifizierung am Ziel-Service verwendet werden. Es enthält dabei weder das Passwort noch den Passworthash des Benutzers.

Kerberos

Häufige Angriffsvektoren

In diesem Abschnitt werden einige Sicherheitsprobleme beschrieben, die bei der Verwendung der Kerberos-Authentifizierung auftreten können.

Kerberoasting

Jeder beliebige Domain User Account kann ein TGT vom KDC anfordern. Das TGT bestätigt die Identität des Accounts und wird verwendet, um Service Tickets für Konten anzufordern, für die ein Service Principal Name registriert ist. Das können zum Beispiel SQL, Exchange oder andere Applikationen sein. Das KDC verschlüsselt das Service Ticket mit einem Schlüssel, der vom Passwort des Ziel-Accounts abgeleitet ist.

In einem Angriff kann diese Vorgehensweise missbraucht werden, um Service Tickets für alle Accounts mit hinterlegtem SPN anzufordern. Diese Tickets können zwar nicht zur Authentifizierung verwendet werden, da sie jedoch mit dem Passwort des Accounts verschlüsselt sind können diese offline mithilfe eines Brute-Force-Angriffs geknackt werden.

AS-REP Roasting

AS-REP Roasting funktioniert technisch gleich wie Kerberoasting. Es gibt eine spezielle Flag (do not require pre-authentication) die für Service-Accounts gesetzt werden kann. Dadurch kann ein Service Ticket ohne vorheriges TGT angefordert werden.

Um dieses Service Ticket anzufordern, muss lediglich der Benutzername des Ziel-Accounts angegeben werden. Mögliche Benutzernamen können auch automatisch enumeriert werden. Das macht diesen Angriff besonders gefährlich, da überhaupt keine Zugangsdaten erforderlich sind.

Kerberos Delegations

Delegierungen sind ein mächtiges Feature des Kerberos-Protokolls. Sie erlauben es Diensten, im Namen eines anderen Kontos oder Computers zu agieren. Ein Webserver muss beispielsweise Dokumente aus einer privaten Dateifreigabe eines Kontos abholen. Dieser kann hierfür Delegierungen verwenden, um sich als angemeldetes Konto mit der Dateifreigabe zu verbinden und dessen Dokumente abzurufen. Es gibt mehrere Möglichkeiten, Delegierungen einzurichten, die jeweils unterschiedliche Sicherheitsaspekte beinhalten:

Unconstrained Delegation

Systeme oder Dienste, bei denen Unconstrained Delegation aktiviert ist, speichern Kerberos Tickets im Arbeitsspeicher zwischen. Wenn diese in einem Angriff kompromittiert werden, können alle zwischengespeicherten Tickets für die Anmeldung mit den jeweiligen Accounts verwendet werden. Tools wie Coercer1 können dazu verwendet werden, ein Zielsystem dazu zu bringen, sich auf einem Unconstrained Delegation System anzumelden und damit dessen Ticket zu erhalten.

Unconstrained Delegation

Constrained Delegation

Constrained Delegation wurde mit Windows Server 2003 eingeführt und soll die Sicherheit für Kerberos Delegierungen maßgeblich verbessern. Bei Constrained Delegation darf sich ein Service-Account nur dann als ein anderes Konto ausgeben, wenn dieser sich mit einem bestimmten Dienst (SPN) verbindet, der in dessen Active Directory Attribut msDS-AllowedToDelegateTo gelistet ist.

Wenn der für Constrained Delegation konfigurierte Service-Account kompromittiert wird, können Service Tickets für alle Accounts auf den konfigurierten Zielsystemen verwendet werden. Es müssen keine Tickets aus dem Speicher ausgelesen werden.

Werden Administratorrechte auf einem solchen System erlangt oder ein solches Konto kompromittiert, können automatisch alle anderen Systeme kompromittiert werden, die diesem System für die Delegierung vertrauen.

Constrained Delegation

Resource Based Constrained Delegation (RBCD)

RBCD ist eine andere Form von Constrained Delegation. Es wurde mit Windows Server 2012 eingeführt und wird in die andere Richtung angewendet. Anstatt dass der Service-Account ein Attribut besitzt, in welchem festgelegt wird, wohin er sich delegieren darf, speichern Zielaccounts (Computer oder Dienste) diese Information in ihrem msDS-AllowedToActOnBehalfOfOtherIdentity Attribut.

Dieses Attribut enthält eine Access Control List (ACL), die angibt, welche Konten auf die Ressource als beliebiger Account zugreifen dürfen.

Wird ein in diesem Attribut angeführtes Konto kompromittiert, kann sich gegenüber der spezifischen Ressource als beliebiges Konto ausgegeben werden. Dieser Zugriff kann jedoch nicht auf andere Systeme ausgeweitet werden, sofern diese nicht ebenfalls explizit für RBCD konfiguriert sind.

Angriffsszenario

Dieser Abschnitt beschreibt ein Angriffsszenario, bei welchem verschiedene Kerberos Konfigurationen ausgenutzt werden können, um die Active Directory Domäne zu kompromittieren. Das Szenario ist wie folgt aufgebaut:

  • Netzwerksegmentierung ist nicht korrekt umgesetzt
  • Zugang zum internen Netzwerk, jedoch ohne gültige Zugangsdaten, wurde erlangt
  • Es wurde keine Rücksicht auf OPSEC genommen, der direkteste Ansatz wurde gewählt

Darüber hinaus umfasst dieses Angriffsszenario drei verschiedene Systeme und einen ausnutzbaren Account: alt text

Nachdem bereits Zugang zum internen Netzwerk erlangt wurde, kann ein AS-REP Roasting Angriff durchgeführt werden, bei dem verschiedene Benutzernamen durchprobiert werden. Hierfür kann das Tool NetExec2 mit den folgenden Parametern verwendet werden:

nxc ldap <DC> -u users.txt -p '' --asreproast output.txt

Für wahrscheinliche Accountnamen wird eine Wordlist mit gängigen Namen verwendet. Der Passwort-Parameter wird für diesen Angriff nicht benötigt und daher freigelassen. Die Ausgabe des Tools beinhaltet alle AS-REP Roastable Konten mit den dazugehörigen Hashes.

Dieser Angriff gibt den Hash des serviceUser@lab.local Accounts preis: alt text

Um diesen Hash zu knacken, kann nun ein offline Brute-Force-Angriff durchgeführt werden: alt text

Wenn, wie in diesem Fall, der Brute-Force-Angriff erfolgreich ist, wird das Klartext-Passwort des betroffenen Accounts erhalten: alt text

Im Anschluss kann eine Anmeldung durchgeführt und die Berechtigungen dieses Kontos ausgelesen werden. Dadurch stellt sich heraus, dass das Konto auf dem System srv1.lab.local administrative Berechtigungen besitzt: alt text

Zusätzlich wird ADSearch3 verwendet, um nach Systemen zu suchen, die Unconstrained Delegation konfiguriert haben:

ADSearch.exe --search "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" --attributes samaccountname,dnshostname

Praktischerweise stellt sich heraus, dass das kompromittierte System srv1.lab.local eines dieser Systeme ist: alt text

Da das System mit Unconstrained Delegation konfiguriert wurde, speichert dieses Kerberos-Tickets zwischen. Diese Tatsache kann ausgenutzt werden, um einen Account oder ein anderes System zu coercen1, damit sich dieses auf dem srv1.lab.local System anmeldet, welches dann das Ticket speichert. Alle zwischengespeicherten Tickets können mithilfe des triage Befehls von Rubeus4 angezeigt werden:

Rubeus.exe triage

Dieser Befehl zeigt, dass sich das Ticket eines Domain Controllers bereits im Arbeitsspeicher befindet, nachdem dieser coerced wurde. alt text Mit administrativen Berechtigungen kann dieses Ticket mithilfe von Rubeus ausgelesen werden, indem die aktuelle Session-ID (LUID) und der betroffene Service angegeben wird:

Rubeus.exe dump /luid:0x651230 /service:krbtgt

Nach dem Auslesen des Tickets kann dieses direkt mithilfe des /ptt Befehls von Rubeus in die aktuelle Session geladen werden: alt text

Mithilfe dieses Tickets für einen Domain-Controller (ein Computer-Account) wird nun versucht auf diesen zuzugreifen um einen DCSync-Angriff auszuführen. Ein DCSync bedeutet, dass sämtliche Daten in der Domäne, also Accounts, Gruppen, Passworthashes etc. zu einem anderen Domain-Controller repliziert werden. Wird Zugang zu diesen Daten erhalten, sind sämtliche Accounts innerhalb der Domäne kompromittiert. Dies schließt beispielsweise auch den krbtgt Account mit ein.

Um dies zu bewerkstelligen, kann die S4U2Self5 Methode verwendet werden:

Rubeus.exe s4u /impersonateuser:administrator /self /altservice:ldap/WIN-4SAHM65HN1H.lab.local /user:WIN-4SAHM65HN1H$ /ticket:[TICKET FROM DUMP] /ptt

Dieser Befehl weist Rubeus an, sich als administrator Account auszugeben, eine Verbindung zum LDAP Interface des Domain-Controllers herzustellen und das vorher ausgelesene Service Ticket des Computers WIN-4SAHM65HN1H$ (der Domain-Controller) zu verwenden, um einen DCSync zu starten: alt text

Da Computer jedoch keinen lokalen Administratorzugriff auf sich selbst über das Netzwerk zulassen, kann das Service Ticket nicht direkt verwendet werden, um Zugriff zu erhalten. Rubeus kann jedoch mithilfe des /self Parameters S4U2Self verwenden, um ein gültiges Service Ticket zu erhalten. Mit diesem Ticket in der eigenen Session kann nun mittels mimikatz6 ein DCSync durchgeführt werden: alt text

Gegenmaßnahmen

Um gegen AS-Rep Roasting geschützt zu sein, müssen alle Accounts die Kerberos Pre-Authentication verlangen: alt text

Wenn diese Einstellung gesetzt ist, ist es nicht mehr möglich, den Passwort-Hash eines Accounts durch AS-REP Roasting herauszufinden: alt text

Zusätzlich sollte die Unconstrained Delegation Berechtigung des srv1.lab.local Systems entzogen werden. Die Einstellung Do not trust this computer for delegation sollte wenn möglich gesetzt werden: alt text

Es sollten andere Methoden für Delegierungen verwendet werden.