Neue Angriffswege? AS hat Servicetickets angefordert

Jul 18, 2023

Startseite » Cybersicherheit » SBN-Nachrichten » Neue Angriffswege? AS hat Servicetickets angefordert

Als ich Andrew Schwartz bei seinem Kerberos-FAST-Beitrag half (der weitere Informationen darüber enthält, was FAST ist und wie es funktioniert, lesen Sie ihn also), ist mir etwas Interessantes aufgefallen. AS-REQs für Maschinenkonten sind ungepanzert. Dies wird von Microsoft hier beschrieben:

Die Kerberos-Armierung verwendet ein Ticket-Granting-Ticket (TGT) für das Gerät, um den Austausch von Authentifizierungsdiensten mit dem KDC zu schützen, sodass der Austausch von Authentifizierungsdiensten des Computers nicht geschützt ist. Das TGT des Benutzers wird zum Schutz seines TGS-Austauschs mit dem KDC verwendet.

Daher fragte ich mich, ob es möglich sei, Servicetickets (STs) beim Authentifizierungsdienst (AS) anzufordern. Die Möglichkeit, STs vom AS anzufordern, hat mehrere Konsequenzen, darunter neue Angriffspfade, Erkennungsumgehungen und eine mögliche Schwächung der Sicherheitskontrollen. Alle in diesem Beitrag besprochenen Probleme wurden Microsoft gemeldet und „als beabsichtigt angesehen“ (Abbildung 1).

Hier ist zunächst ein allgemeiner Überblick über den typischen Kerberos-Ablauf (Abbildung 2, Quelle: ADSecurity):

Die Tatsache, dass für jedes Ticket ein Sitzungsschlüssel ausgegeben wird, ist ein wichtiges Merkmal für die folgende Recherche. Dieser Sitzungsschlüssel wird in einem verschlüsselten Abschnitt der Antwort an das anfordernde Konto zurückgegeben. Der Verschlüsselungsschlüssel ist dem Anforderer bereits bekannt.

Beispielsweise wird der TGT-Sitzungsschlüssel in einem Abschnitt gespeichert, der mit dem Schlüssel verschlüsselt ist, der zum Nachweis der Identität des Anforderers bei der Anforderung eines TGT verwendet wird. Dieser Schlüssel ist normalerweise der Langzeitschlüssel (Passwort-Hash) des Kontos. Bei 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 Ticketsitzungsschlüssel ist erforderlich, um das Ticket im nächsten Schritt des Kerberos-Ablaufs zu verwenden.

Eine Kerberos-Anfrage besteht aus zwei Hauptabschnitten:

Der Req-Body wird größtenteils im Klartext gesendet und enthält mehrere Informationen:

Eine Kerberos-Antwort besteht aus mehreren Abschnitten und enthält einen verschlüsselten Teil:

Der Teil des Kerberos-Flusses, auf den sich dieser Beitrag konzentriert, ist AS-REQ/AS-REP, der normalerweise zum Anfordern eines TGT verwendet wird. Im Normalbetrieb enthält eine AS-REQ einen von zwei WertenstartetFeld im Req-Body:

Mir ist aufgefallen, dass Maschinenkonten trotz der Durchsetzung von Kerberos Flexible Authentication Secure Tunneling (FAST) ihre AS-REQs immer noch ungepanzert gesendet haben. Ich habe mich gefragt, ob ein AS-REQ anstelle eines TGT verwendet werden könnte, um einen ST direkt anzufordern. Dies veranlasste mich, Rubeus zu modifizieren, um festzustellen, ob innerhalb des. ein anderer SPN angegeben werden sollstartet einer AS-REQ würde dazu führen, dass der DC mit einem ST für diesen SPN antwortet. Wie sich herausstellte, war die Antwort „Ja“ (Abbildung 3).

Durch die Verwendung eines Maschinenkontos kann ich einen ST anfordern, ohne Panzerung zu verwenden, wenn FAST erzwungen wird. Was ist noch möglich?

Kerberoasting, entdeckt von Tim Medin, ist eine Methode zur Wiederherstellung des Klartext-Passworts oder NT-Hash für ein Dienstkonto, im Allgemeinen ein Benutzerkonto mit einem SPN. Kerberoasting ist möglich, da ein Teil eines ST mit dem Langzeitschlüssel (Passwort-Hash) des Dienstkontos verschlüsselt wird. Durch Extrahieren des verschlüsselten Teils des Tickets ist es möglich, aus verschiedenen Klartext-Passwörtern einen Hash zu bilden und zu versuchen, den verschlüsselten Teil zu entschlüsseln. Wenn die Entschlüsselung erfolgreich ist, ist der verwendete Hash der Langzeitschlüssel, der zum Verschlüsseln des Tickets verwendet wird. Dieser Schlüssel kann dann letztendlich zur Authentifizierung als Dienstkonto verwendet werden.

Darüber hinaus kann jedes Konto einen ST für jeden Dienst anfordern. Daher ist für die Durchführung des Angriffs die Fähigkeit zur Authentifizierung bei Active Directory (AD) erforderlich. Zumindest stimmte das früher.

Zuerst habe ich versucht, ein Konto zu verwenden, das keine Vorauthentifizierung (DONT_REQ_PREAUTH) erfordert, um eine ST anzufordern. Wenn für die Authentifizierung eines Kontos keine Vorauthentifizierung erforderlich ist, kann ein TGT angefordert werden, ohne dass Vorauthentifizierungsdaten erforderlich sind, die mit einer Form von Anmeldeinformationen (z. B. Passwort-Hash, Zertifikat) verschlüsselt werden. Wenn ein Angreifer keine gültigen Anmeldeinformationen für ein Konto erhalten hat, kann keine gültige Vorauthentifizierung generiert werden. Wenn keine Vorauthentifizierung erforderlich ist, stellt dies kein Problem dar.

Wenn ein Ticket ohne Vorauthentifizierung angefordert wird, enthält das Ergebnis immer noch einen verschlüsselten Teil. Dieser verschlüsselte Teil wird mit dem zur Authentifizierung verwendeten Anmeldeinformationsschlüssel verschlüsselt und enthält den Sitzungsschlüssel für das in der Antwort enthaltene Ticket. Dies sind die verschlüsselten Daten, die beim ASREPRoast-Angriff von Will Schroeder verwendet wurden. Das resultierende TGT kann nur mit Zugriff auf den anfordernden Kontoschlüssel verwendet werden, da der TGT-Sitzungsschlüssel erforderlich ist.

Für Kerberoasting ist jedoch kein Zugriff auf den Sitzungsschlüssel erforderlich. Es ist nur der resultierende ST – oder genauer gesagt der verschlüsselte Teil des ST, der nicht mit dem Schlüssel des anfordernden Kontos gesichert ist – erforderlich. Wenn daher ein Konto so konfiguriert ist, dass keine Vorauthentifizierung erforderlich ist, ist Kerberoast ohne möglichbeliebig Referenzen. Diese Methode des Kerberoastings wurde im Rahmen dieser PR in Rubeus implementiert.

Da der Zugriff auf ein gültiges Konto noch nicht erfolgt ist, kann LDAP nicht abgefragt werden. Stattdessen ist eine Liste potenzieller Dienstkonten erforderlich. Frühere Untersuchungen von Arseniy Sharoglazov zeigen, dass STs nur mit dem Benutzernamen des Dienstkontos angefordert werden können, anstatt den tatsächlichen SPN zu benötigen – sehr nützlich für diese Forschung.

Eine Liste von Benutzernamen kann auf verschiedene Weise generiert werden, einschließlich der Benutzeraufzählung mithilfe von Nullsitzungen auf einem Domänencontroller, der Erstellung einer Liste von Benutzernamen mithilfe von Open-Source-Intelligence (OSINT) oder dem Erraten potenzieller Benutzernamen. Jede Liste potenzieller Benutzernamen kann einfach durch Senden einer AS-REQ ohne Vorauthentifizierung überprüft werden. Ein gültiger Benutzername, der eine Vorauthentifizierung erfordert, erhält einenKDC_ERR_PREAUTH_REQUIREDFehler (Abbildung 4).

Ein gültiger Benutzername, der keine Vorauthentifizierung erfordert, erhält ein TGT (Abbildung 5).

Ein ungültiger Benutzername erhält eineKDC_ERR_C_PRINCIPAL_UNKNOWNFehler (Abbildung 6).

Zu Demonstrationszwecken wird eine Liste mithilfe einer Nullsitzung auf dem DC generiert, wobei die RID-Cycling-Methode (-R) von enum4linux-ng verwendet wird, wie Abbildung 7 zeigt.

Mithilfe dieser Liste von Benutzernamen ist es in AD einfach, Konten zu ermitteln, für die keine Vorauthentifizierung erforderlich ist (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 das Offline-Knacken von Passwörtern zu versuchen.

Eine weitere interessante Konsequenz ist die Möglichkeit, Kerberoast aus einer Man-in-the-Middle-Position (MitM) auszuführen. Diese Art von Angriff ist mit TGS-REQs im Allgemeinen nicht möglich, da die Option optional istcksum Das Feld im Authentifikator in der AP-REQ schützt den Anforderungstext der Anfrage und wird häufig von echten Windows Kerberos-Clients eingefügt. Daher ist eine Änderung derstarteteiner TGS-REQ ohne Aktualisierung der Prüfsumme innerhalb des Authentifikators macht die Prüfsumme des Authentifikators ungültig und gibt a zurückKRB_AP_ERR_MODIFIED Fehler. Dies ist jedoch kein Problem für AS-REQs, da dieReq-Körper, und folglich diestartetFeld, sind nicht geschützt.

Beim Testen dieses Ansatzes habe ich festgestellt, dass AS-REQs viele Male wiedergegeben werden können. Ein Angreifer muss nur eine AS-REQ erfassen, um viele AS-REQs mit unterschiedlichen Werten zu sendenstartetWerte.

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 weiter, 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, zeigt aber, dass ein Angriff möglich ist.

Zunächst startet der POC vier Threads, einen Sniffer, einen ARP-Spoofer, einen Reassembler (für Anfragen, die auf mehrere Pakete aufgeteilt sind) und den Röster (Abbildung 10).

Wenn eine AS-REQ erkannt wird, beginnt der POC mit dem Kerberoasting der bereitgestellten Liste, die Benutzernamen oder SPNs enthalten kann (Abbildung 11).

Wie Abbildung 11 zeigt, führt dieser Versuch dazu, dass alle empfangenen STs im Hashcat-Format ausgegeben werden, bereit für das Offline-Knacken von Passwörtern.

Die Möglichkeit, AS-REQs mitM zu erstellen, sie dann zu ändern und wiederzugeben, könnte auch bei der Entwicklung anderer Angriffe nützlich sein. Ich habe versucht, die kdc-Optionen so zu ändern, dass sie Folgendes enthaltenvertretbarFlagge, was zu einem Ticket mit dem führtvertretbar Flagge gesetzt. Mit diesem Ticket und dieser Flagge konnte ich jedoch keinen Angriffspfad finden. Dieses Verhalten ermöglicht möglicherweise auch die Verwendung anderer Konten zur Durchführung eines Kerberoasts, sodass Angreifer vermeiden können, ein kompromittiertes Konto zu zerstören.

Für diesen Prozess sind möglicherweise einige Verbesserungen möglich. Erstens ist es möglich, eine AS-REQ von einer TGS-REQ zu erzwingen, indem man sie abfängt und mit a antwortetKRB_AP_ERR_BAD_INTEGRITY Fehler. Dadurch wird der Client gezwungen, sich erneut zu authentifizieren, indem er eine AS-REQ sendet.

Es sollte auch möglich sein, diesen Angriff mithilfe der DHCPv6-Nameserver-Injektion (wie mitm6 von Dirk-jan Mollema oder Inveigh von Kevin Robertson) durchzuführen, indem auf SRV-DNS-Anfragen für den LDAP-Dienst geantwortet und dann die folgende LDAP-Verbindung bearbeitet wird.

Unterstützung für die Änderung derEtypeninnerhalb der Anfrage ermöglicht Downgrade-Angriffe vom Typ Verschlüsselung, wenn die Umgebung dies zulässt, wie von Will Schroeder hier beschrieben.

Schließlich erfordert der POC die Installation von Npcap auf dem System, auf dem der POC läuft (das Sharppcap verwendet), hauptsächlich für ARP-Spoofing. Wenn Sie die IPv6-Route wählen oder die ARP-Antworten mithilfe von Raw-Sockets implementieren, können Sie diese Abhängigkeit entfernen.

Viele Kerberos-Erkennungen basieren auf 4769-Ereignissen (ein Kerberos-Serviceticket wurde angefordert). Das Anfordern eines Servicetickets mithilfe einer AS-REQ führt jedoch nicht zu 4769 Ereignissen, sondern zu 4768 Ereignissen (es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert).

Abbildung 12 zeigt ein 4768-Ereignis, wenn ein ST mithilfe einer AS-REQ angefordert wird.

Daher können Angreifer, die diese Methode verwenden, viele Erkennungen, die auf 4769-Ereignissen basieren, leicht umgehen.

Obwohl ich keine S4U2self-Tickets vom AS anfordern konnte, fehlt den vom AS abgerufenen STs die Ticketprüfsumme (eingeführt, um S4U2self-Tickets vor dem Bronze-Bit-Angriff von Jake Karnes zu schützen).

Schließlich wird ein vom TGS angeforderter ST im Allgemeinen mit einem PAC zurückgegeben (Abbildung 13).

Es ist möglich, einen ST ohne PAC beim TGS anzufordern, hierfür ist jedoch eine Änderung der Dienstkonten erforderlichNO_AUTH_DATA_REQUIREDBit im Attribut useraccountcontrol (Abbildung 14).

Wenn diese Konfiguration vorhanden ist, fehlt dem zurückgegebenen ST ein PAC, wie der Unterschied in der Größe des zurückgegebenen Tickets zeigt (Abbildung 15).

Ein ST ohne PAC kann vom AS angefordert werden, indem einfach der PA-Datenabschnitt PA-PAC-OPTIONS durch Hinzufügen von auf „false“ gesetzt wird/nopacWechseln Sie zu Rubeus (Abbildung 16).

Dieser Ansatz könnte als Alternative zum Erstellen von Silbertickets verwendet werden, indem ein ST ohne PAC angefordert und dann ein weiteres PAC eingefügt wird, indem es in das eingefügt wirdEnc-Autorisierungsdaten Abschnitt der Anfrage. Es könnte auch andere potenzielle Angriffspfade bieten.

Da Microsoft diese Probleme offenbar nicht als lösbar erachtet, ist die Erkennung innerhalb Ihrer Organisation die einzige Möglichkeit. Wie zuvor gezeigt, wird Ereignis 4768 protokolliert, wenn ein ST vom AS angefordert wird (Abbildung 17).

In diesem Fall können Sie sehen, dass der Dienstname und die Dienst-ID nicht übereinstimmenkrbtgt.Alle beim AS angeforderten echten Tickets, einschließlichkadmin/changepwTickets haben einen Servicenamen und eine Service-ID vonkrbtgt(Abbildung 18).

Überprüfen des Netzwerkverkehrs auf AS-REQs, die nicht für die sindkrbtgt/domainoderkadmin/changepwsollte diese Anfragen ebenfalls erkennen (Abbildung 19).

Diese Untersuchung zeigt zusammen mit der Reaktion von Microsoft die Notwendigkeit einer kontinuierlichen Überwachung und angemessener Härtungsmaßnahmen. Die Möglichkeit, aktuelle Erkennungen zu umgehen und von einer nicht authentifizierten Position aus effektive Angriffe wie Kerberoasting durchzuführen, ist ein ernstes Problem, das nicht ignoriert werden sollte. Die hier beschriebene Forschung könnte zu weiteren neuartigen Angriffen führen und Unternehmen möglicherweise einem höheren Risiko aussetzen.

Stellen Sie sicher, dass Erkennungen vorhanden sind, wenn diese Art von Ticketanfragen gestellt werden.

Ich möchte den folgenden Personen für ihre Beiträge zu dieser Forschung danken:

Der Beitrag Neue Angriffswege? AS Requested Service Tickets erschienen zuerst auf Semperis.

*** Dies ist ein syndizierter Blog des Security Bloggers Network von Semperis, verfasst von Charlie Clark. Lesen Sie den Originalbeitrag unter: https://www.semperis.com/blog/new-attack-paths-as-requested-sts/