Während ich Andrew Schwartz bei seinem Kerberos FAST-Beitrag geholfen habe (der mehr Informationen darüber enthält, was FAST ist und wie es funktioniert, also lesen Sie ihn), ist mir etwas Interessantes aufgefallen. AS-REQs für Rechnerkonten sind nicht gepanzert. Die Kerberos-Panzerung wird von Microsoft beschrieben:
Kerberos Armoring verwendet ein Ticket-gewährendes Ticket (TGT) für das Gerät, um den Austausch von Authentifizierungsdiensten mit dem KDC zu schützen, so dass der Austausch von Authentifizierungsdiensten des Computers nicht geschützt ist. Das TGT des Benutzers wird zum Schutz seines TGS-Austauschs mit dem KDC verwendet.
Deshalb habe ich mich gefragt, ob es möglich ist, Service-Tickets (STs) vom Authentifizierungsdienst (AS) anzufordern. Die Möglichkeit, STs vom AS anzufordern, hat mehrere Konsequenzen, darunter neue Angriffswege, Umgehung der Erkennung und mögliche Schwächung der Sicherheitskontrollen. Alle in diesem Beitrag besprochenen Probleme wurden Microsoft gemeldet und wurden als "absichtlich" eingestuft(Abbildung 1).
Verwandte Lektüre
Kerberos-Zusammenfassung
Zunächst erhalten Sie einen Überblick über den typischen Kerberos-Ablauf(Abbildung 2, Quelle: ADSecurity):
- Ein Konto fordert ein TGT vom Domain Controller (DC) an.
- Der DC antwortet mit einem TGT, das seinen eigenen Sitzungsschlüssel hat.
- Das TGT und sein Sitzungsschlüssel werden verwendet, um ein Service-Ticket (ST) vom DC anzufordern.
- Der DC antwortet mit einem ST, der seinen eigenen Sitzungsschlüssel hat.
- Der ST und sein Sitzungsschlüssel werden zur Authentifizierung gegenüber dem Enddienst verwendet.
- Der Enddienst gewährt oder verbietet den Zugriff.
Die Tatsache, dass für jedes Ticket ein Sitzungsschlüssel ausgegeben wird, ist ein wichtiges Merkmal für die folgenden Untersuchungen. Dieser Sitzungsschlüssel wird in einem verschlüsselten Abschnitt der Antwort an das anfordernde Konto zurückgegeben; der Verschlüsselungsschlüssel ist dem Anfragenden bereits bekannt.
Der TGT-Sitzungsschlüssel wird beispielsweise in einem Bereich gespeichert, der mit dem Schlüssel verschlüsselt ist, der zum Nachweis der Identität des Antragstellers bei der Beantragung eines TGTs verwendet wird. Dieser Schlüssel ist normalerweise der langfristige Schlüssel (Passwort-Hash) des Kontos. Im Falle der Public Key Cryptography for Initial Authentication (PKINIT) im Kerberos-Protokoll wird der Schlüssel jedoch aus dem Zertifikat abgeleitet. Der ST-Sitzungsschlüssel wird in einem Abschnitt gespeichert, der mit dem TGT-Sitzungsschlüssel verschlüsselt ist.
Der Sitzungsschlüssel des Tickets ist erforderlich, um das Ticket im nächsten Schritt des Kerberos-Flusses zu verwenden.
Eine Kerberos-Anfrage besteht aus zwei Hauptabschnitten:
- padata (Vor-Authentifizierungsdaten)
- req-body (Körper der Anfrage)
Der Req-Body wird meist im Klartext gesendet und enthält mehrere Informationen:
- kdc-options: verschiedene Optionen
- cname: Name des anfordernden Kontos (optional)
- Bereich: Domänenname
- sname: Service Principal Name (SPN) für das resultierende Ticket (optional)
- ab: Zeitpunkt, ab dem das Ticket nach Wunsch des Kunden gültig sein soll (optional)
- till: Zeit, bis zu der der Kunde möchte, dass das Ticket gültig ist
- rtime: die gewünschte Verlängerungszeit (optional)
- nonce: Zufallszahl
- etype: Liste der unterstützten Verschlüsselungstypen des Clients
- Adressen: Liste der Adressen des anfragenden Clients (optional)
- enc-authorization-data: verschiedene Abschnitte mit Autorisierungsdaten, verschlüsselt mit dem Sitzungsschlüssel, der normalerweise für lokale Berechtigungen verwendet wird (optional)
- additional-tickets: Liste der für die Anfrage erforderlichen Tickets (optional)
Eine Kerberos-Antwort besteht aus mehreren Abschnitten und enthält einen verschlüsselten Teil:
- pvno: Versionsnummer
- msg-type: Art der Nachricht (11 AS, 13 TGS)
- padata: Vor-Authentifizierungsdaten (optional)
- crealm: Domänenname des Kunden
- cname: Name des anfordernden Kontos
- Ticket: resultierendes Ticket
- enc-part: verschlüsselte Daten zur Verwendung durch den Client
Das Problem mit den von AS angeforderten Service-Tickets
Der Teil des Kerberos-Flusses, auf den sich dieser Beitrag konzentriert, ist AS-REQ/AS-REP, der normalerweise verwendet wird, um einen TGT anzufordern. Im Normalfall hat eine AS-REQ einen von zwei Werten im Feld sname innerhalb des req-body:
- krbtgt/domain.local: wird verwendet, um ein erstes TGT anzufordern
- kadmin/changepw: wird verwendet, um ein kurzlebiges Ticket anzufordern, das zum Zurücksetzen von Passwörtern mithilfe einer KRB-PRIV-Nachricht (definiert in RFC 3244) verwendet werden kann
Mir ist aufgefallen, dass bei aktiviertem Kerberos Flexible Authentication Secure Tunneling (FAST) die Rechnerkonten ihre AS-REQs immer noch ungepanzert senden. Ich fragte mich, ob eine AS-REQ verwendet werden könnte, um direkt einen ST anzufordern, anstatt einen TGT. Dies veranlasste mich, Rubeus zu modifizieren, um festzustellen, ob die Angabe eines anderen SPN im Namen einer AS-REQ dazu führen würde, dass der DC mit einer ST für diesen SPN antwortet. Wie sich herausstellte, war die Antwort "ja"(Abbildung 3).
Wenn ich ein Maschinenkonto verwende, kann ich einen ST anfordern, ohne eine Panzerung zu verwenden, wenn FAST erzwungen wird. Was ist sonst noch möglich?
Neue Wege zum Kerberoast
Das von Tim Medin entdeckte Kerberoasting ist eine Methode zur Wiederherstellung des Klartextpassworts oder NT-Hashs für ein Dienstkonto, im Allgemeinen ein Benutzerkonto mit einem SPN. Kerberoasting ist möglich, weil ein Teil eines ST mit dem Langzeitschlüssel des Servicekontos (Passwort-Hash) verschlüsselt ist. Durch Extrahieren des verschlüsselten Teils des Tickets ist es möglich, einen Hash aus verschiedenen Klartextpasswörtern zu bilden und zu versuchen, den verschlüsselten Teil zu entschlüsseln. Wenn die Entschlüsselung erfolgreich ist, ist der verwendete Hash der langfristige Schlüssel, der zur Verschlüsselung des Tickets verwendet wurde. Dieser Schlüssel kann dann letztendlich für die Authentifizierung als Dienstkonto verwendet werden.
Außerdem kann jedes Konto eine ST für jeden Dienst anfordern. Daher ist die Fähigkeit, sich bei Active Directory (AD) zu authentifizieren, erforderlich, um den Angriff durchzuführen. Zumindest war das früher so.
Kerberoasting ohne Vorauthentifizierung
Zunächst habe ich versucht, ein Konto zu verwenden, das keine Vorauthentifizierung erfordert(DONT_REQ_PREAUTH), um einen ST anzufordern. Wenn ein Konto keine Vorabauthentifizierung zur Authentifizierung erfordert, kann ein TGT angefordert werden, ohne dass Vorabauthentifizierungsdaten erforderlich sind, die mit einer Art von Berechtigungsnachweis (z.B. Passwort-Hash, Zertifikat) verschlüsselt sind. Wenn ein Angreifer keine gültigen Zugangsdaten für ein Konto erhalten hat, kann keine gültige Vorauthentifizierung erzeugt werden. Wenn eine Vorabauthentifizierung nicht erforderlich ist, stellt dies kein Problem dar.
Wenn ein Ticket ohne Vorauthentifizierung angefordert wird, enthält das Ergebnis dennoch einen verschlüsselten Teil. Dieser verschlüsselte Teil ist mit dem für die Authentifizierung verwendeten Anmeldeschlüssel verschlüsselt und enthält den Sitzungsschlüssel für das in der Antwort enthaltene Ticket. Dies sind die verschlüsselten Daten, die bei dem ASREPRoast-Angriff von Will Schroeder verwendet wurden. Das resultierende TGT ist nur mit Zugriff auf den Schlüssel des anfragenden Kontos verwendbar, da der TGT-Sitzungsschlüssel erforderlich ist.
Für Kerberoasting ist der Zugriff auf den Sitzungsschlüssel jedoch nicht erforderlich. Nur die resultierende ST - oder genauer gesagt, der verschlüsselte Teil der ST, der nicht mit dem Schlüssel des anfragenden Kontos gesichert ist - ist erforderlich. Wenn ein Konto so konfiguriert ist, dass keine Vorabauthentifizierung erforderlich ist, ist es daher möglich, Kerberoasting ohne Anmeldeinformationen durchzuführen. Diese Methode des Kerberoasting wurde im Rahmen dieses PR in Rubeus implementiert.
Demonstration
Da der Zugriff auf ein gültiges Konto noch nicht erfolgt ist, kann LDAP nicht abgefragt werden. Stattdessen wird eine Liste potenzieller Dienstkonten benötigt. Frühere Forschungen von Arseniy Sharoglazov haben gezeigt, dass STs nur mit dem Benutzernamen des Dienstkontos abgefragt werden können, anstatt den tatsächlichen SPN zu verlangen - sehr nützlich für diese Forschung.
Eine Liste von Benutzernamen kann auf verschiedene Weise generiert werden, z. B. durch Aufzählung von Benutzern mit Null-Sitzungen auf einem DC, durch Generierung einer Liste von Benutzernamen mit Hilfe von Open-Source-Intelligence (OSINT) oder durch Erraten potenzieller Benutzernamen. Jede Liste potenzieller Benutzernamen kann leicht überprüft werden, indem eine AS-REQ ohne Vorauthentifizierung gesendet wird. Ein gültiger Benutzername, der eine Vorauthentifizierung erfordert, erhält einen KDC_ERR_PREAUTH_REQUIRED-Fehler(Abbildung 4).
Ein gültiger Benutzername, der keine Vorauthentifizierung erfordert, erhält ein TGT(Abbildung 5).
Bei einem ungültigen Benutzernamen wird der Fehler KDC_ERR_C_PRINCIPAL_UNKNOWN angezeigt(Abbildung 6).
Zu Demonstrationszwecken wird eine Liste mit einer Null-Sitzung auf dem DC unter Verwendung der RID-Zyklusmethode(-R) von enum4linux-ngerstellt, wie Abbildung 7 zeigt.
Anhand dieser Liste von Benutzernamen ist es in AD einfach, Konten zu bestimmen, die keine Vorabauthentifizierung erfordern(Abbildung 8).
Beachten Sie, dass AS-REQs ohne Vorauthentifizierung nicht als Windows-Ereignis protokolliert werden, es sei denn, das Konto erfordert keine Vorauthentifizierung.
Mit der Liste der Benutzernamen und dem Benutzernamen eines Kontos, das keine Vorauthentifizierung erfordert, kann der Angriff gestartet werden(Abbildung 9).
Die resultierende Ausgabe kann dann verwendet werden, um zu versuchen, das Passwort offline zu knacken.
Der Beweis für das Konzept: RoastInTheMiddle
Eine weitere interessante Folge ist die Möglichkeit, Kerberoast von einer Man-in-the-Middle (MitM) Position aus durchzuführen. Diese Art von Angriff ist bei TGS-REQs in der Regel nicht möglich, da das optionale cksum-Feld innerhalb des Authenticators in der AP-REQ den req-body der Anfrage schützt und häufig von echten Windows Kerberos-Clients enthalten ist. Wenn Sie also den Sname einer TGS-REQ ändern, ohne die Prüfsumme im Authenticator zu aktualisieren, wird die Prüfsumme des Authenticators ungültig und Sie erhalten einen KRB_AP_ERR_MODIFIED-Fehler. Für AS-REQs ist dies jedoch kein Problem, da der Req-Body und damit auch das Feld sname nicht geschützt sind.
Beim Testen dieses Ansatzes habe ich festgestellt, dass AS-REQs viele Male wiedergegeben werden können. Ein Angreifer braucht nur eine AS-REQ zu erfassen, um viele AS-REQs mit unterschiedlichen Sname-Werten zu senden.
Demonstration
Um diesen Ansatz zu demonstrieren, habe ich einen groben Proof of Concept (POC) geschrieben. Dieser POC, RoastInTheMiddle, implementiert einen ARP-Spoof zwischen DCs und Opfersystemen, um einen MitM-Angriff durchzuführen. Der POC leitet dann den Datenverkehr durch, während er auf AS-REQs wartet. Wenn eine AS-REQ gefunden wird, führt der POC einen Kerberoast durch. Der POC ist nicht angriffsbereit, demonstriert aber, dass ein Angriff möglich ist.
Zunächst startet der POC vier Threads, einen Sniffer, einen ARP-Spoofer, einen Re-Assembler (für Anfragen, die auf mehrere Pakete verteilt sind) und den Roaster(Abbildung 10).
Wenn er eine AS-REQ sieht, versucht der POC, die gelieferte Liste, die Benutzernamen oder SPNs enthalten kann, zu kerberoasten(Abbildung 11).
Wie Abbildung 11 zeigt, führt dieser Versuch dazu, dass alle empfangenen STs im Hashcat-Format ausgegeben werden, bereit zum Offline-Kennwortknacken.
Die Möglichkeit, AS-REQs mitzuverfolgen, sie zu modifizieren und wieder abzuspielen, könnte auch bei der Entwicklung anderer Angriffe nützlich sein. Ich habe versucht, die kdc-Optionen zu ändern, um die proxiable Flag aufzunehmen, was zu einem Ticket mit gesetztem Proxiable Flag führt. Ich konnte jedoch keinen Angriffsweg mit diesem Ticket und diesem Flag finden. Dieses Verhalten könnte auch die Verwendung anderer Konten zur Durchführung eines Kerberoast ermöglichen, so dass Angreifer das Brennen eines kompromittierten Kontos vermeiden können.
Verbesserungen
Bei diesem Verfahren sind einige Verbesserungen möglich. Erstens ist es möglich, eine AS-REQ aus einer TGS-REQ zu erzwingen, indem man sie abfängt und mit einem KRB_AP_ERR_BAD_INTEGRITY-Fehler antwortet. Dadurch wird der Client gezwungen, sich durch Senden einer AS-REQ neu zu authentifizieren.
Es sollte auch möglich sein, diesen Angriff mit Hilfe von DHCPv6 Nameserver Injection (wie mitm6 von Dirk-jan Mollema oder Inveigh von Kevin Robertson) durchzuführen, indem Sie auf SRV DNS-Anfragen für den LDAP-Dienst antworten und dann die folgende LDAP-Verbindung bearbeiten.
Die Unterstützung für die Änderung der Etypes innerhalb der Anfrage ermöglicht Downgrade-Angriffe auf den Verschlüsselungstyp, wenn die Umgebung dies zulässt, wie hier von Will Schroeder beschrieben.
Schließlich erfordert das POC die Installation von Npcap auf dem System, auf dem das POC läuft (das sharppcap verwendet), hauptsächlich für ARP-Spoofing. Wenn Sie die IPv6-Route wählen oder die ARP-Antworten durch die Verwendung von Raw Sockets implementieren, können Sie diese Abhängigkeit entfernen.
Umgehung von Erkennungen
Viele Kerberos-Erkennungen basieren auf 4769-Ereignissen(Ein Kerberos-Service-Ticket wurde angefordert). Die Anforderung eines Service-Tickets über eine AS-REQ erzeugt jedoch nicht 4769 Ereignisse, sondern 4768 Ereignisse(Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert).
Abbildung 12 zeigt ein 4768-Ereignis, wenn ein ST mit einer AS-REQ angefordert wird.
Daher können Angreifer mit dieser Methode viele Erkennungen, die sich auf 4769 Ereignisse stützen, leicht umgehen.
Andere Folgen der von AS angeforderten Service-Tickets
Obwohl ich nicht in der Lage war, S4U2self-Tickets von der AS anzufordern, fehlt den von der AS abgerufenen STs die Ticket-Prüfsumme (die eingeführt wurde, um S4U2self-Tickets gegen den Bronze-Bit-Angriff von Jake Karnes zu schützen).
Schließlich wird ein vom TGS angeforderter ST in der Regel mit einem PAC zurückgegeben(Abbildung 13).
Es ist möglich, einen ST ohne PAC vom TGS anzufordern, aber dazu muss das NO_AUTH_DATA_REQUIRED-Bit im Attribut useraccountcontrol geändert werden(Abbildung 14).
Bei dieser Konfiguration fehlt dem zurückgegebenen ST ein PAC, wie der Größenunterschied des zurückgegebenen Tickets zeigt(Abbildung 15).
Ein ST ohne PAC kann von der AS angefordert werden, indem der PA-Datenabschnitt PA-PAC-OPTIONS durch Hinzufügen des Schalters /nopac zu Rubeus auf false gesetzt wird(Abbildung 16).
Dieser Ansatz könnte als Alternative zur Erstellung von Silver Tickets verwendet werden, indem ein ST ohne PAC angefordert wird und dann ein anderer PAC in den Abschnitt enc-authorization-data der Anfrage eingefügt wird. Es könnte auch andere potenzielle Angriffswege bieten.
Erkennung von AS angeforderten Service-Tickets
Da Microsoft diese Probleme offenbar nicht für behebenswert hält, ist die Erkennung innerhalb Ihres Unternehmens die einzige Möglichkeit. Wie bereits gezeigt, wird das Ereignis 4768 protokolliert, wenn eine ST von der AS angefordert wird(Abbildung 17).
In diesem Fall sehen Sie, dass der Dienstname und die Dienst-ID nicht krbtgt sind. Alle echten Tickets, die vom AS angefordert werden, einschließlich kadmin/changepw-Tickets, haben den Dienstnamen und die Dienst-ID krbtgt(Abbildung 18).
Die Überprüfung des Netzwerkverkehrs auf AS-REQs, die nicht für krbtgt/domain oder kadmin/changepw bestimmt sind, sollte auch diese Anfragen aufdecken(Abbildung 19).
Diese Untersuchung und die Reaktion von Microsoft zeigen, dass eine kontinuierliche Überwachung und angemessene Abhärtungsmaßnahmen erforderlich sind. Die Fähigkeit, aktuelle Erkennungen zu umgehen und effektive Angriffe wie Kerberoasting von einer nicht authentifizierten Position aus durchzuführen, ist ein ernstes Problem, das nicht ignoriert werden sollte. Die hier beschriebene Forschung könnte zu weiteren neuartigen Angriffen führen, die Unternehmen möglicherweise einem höheren Risiko aussetzen.
Stellen Sie sicher, dass bei dieser Art von Ticketanfragen eine Erkennung stattfindet.
Danksagung
Ich möchte mich bei den folgenden Personen für ihre Beiträge zu dieser Studie bedanken:
- Andrew Schwartz, der mich mit seinem Kerberos FAST-Beitrag (den Sie ebenfalls lesen sollten) auf diesen Weg gebracht hat
- Elad Shamir dafür, dass ich diese Ideen bei ihm abprallen lassen konnte
- Will Schroeder für das Schreiben von Rubeus
- Tomer Nahum, Sapir Federovsky und Andrea Pierini für das Korrekturlesen dieses Beitrags und ihre Kritik
Zeitleiste
- 25. Mai 2022: Bericht an den MSRC
- 27. Mai 2022: MSRC hat den Status auf Review/Repro geändert.
- 13. Juli 2022: MSRC antwortet, dass das Verhalten "absichtlich" war.
- 27. September 2022: Öffentliche Bekanntgabe
Erfahren Sie mehr von Semperis Research
