Kerberos Wireshark

In Verbindung mit der Arbeit an der Seite Kerberos Encryption habe ich einige Pakete mit Wireshark mitgeschnitten.

Anmeldung

Zuerst schaue ich mir aber eine einfache Anmeldung eines Clients (Windows 2016) an einem Domain Controller (Windows 2016) an. Sie sehen zuerst der AS-REQ, der mit einem "PREAUTH_REQUIRED" abgelehnt wird. Der zweite AS-REQ enthält dann genug Informationen, damit der KDC ein Ticket ausstellt.

Der erste Request liefert neben dem Benutzernamen und dem REALM (=Domain) auch die möglichen Encryption-Verfahren:

Der Client komplett gepatched und daher steht AES erst einmal oben. Es ist aber weiterhin auch das unsichere DES-CBC-MD5 möglich. Hoffen wir, dass es niemand nutzt.

Wenn Sie theoretisch mögliches "Downgrade" durch eine Malware verhindern wollen, sollten Sie per Richtlinie die schwachen Crypto-Verfahren unterbinden.

Die Antwort enthält u.a. einen SALT aber auch die möglichen Verfahren, mit dem ich im nächsten Schritt die Anmeldung anpassen

Es überrascht mich hier natürlich schon, das neben AES256-CTS-HMAC-SHA1-96 zusätzlich auch noch ARCFOUR-HMAC-MD5 angeboten wird. Das schwache Verfahren ignoriert mein Client und meldet sie per AES265 an.

Wenn Sie "Sicher"" sein wollen, dann verbieten Sie auf dem Client die Nutzung der schwachen Verfahren

Sie sehen hier aber auch, dass er PAC Signing mit Kerberos anfordert. Die Antwort enthält dann das geforderte "Ticket Granting Ticket" (TGT)

Damit habe wir nun ein TGT, mit dem wir weitere Tickets bei Bedarf anfordern können.

SMB 2 Service Zugriff

Bei einem Zugriff auf einen Domain Controller per LDAP oder SMB brauche ich natürlich ein Service Ticket für den entsprechenden Dienst. Hier habe ich einen Mitschnitt mit einer Anmeldung und Zugriff auf den NETLOGON-Share

Die Pakete im einzelnen mit Auszügen aus dem Paket

Paket Beschreibung

34,35,42,43

Anmeldung des Client per Kerberos und Ausstellung eines TGT

182,183

SMB Aushandlung der Möglichkeiten

188

 Anforderung eines Service Tickets

189

 Antwort mit dem Service Ticket

208,210,211,212

 SMB Zugriff mit Kerberos

Die generelle Funktion von Kerberos bei der Anmeldung und dem Zugriff auf Dienste sollte damit verständlich sein. SMB ist dahingehend dankbar, da die Verbindung nicht verschlüsselt ist.

LDAP Service Zugriff

Auch bei einem Zugriff per LDAP sehen Sie folgendes:

Die Pakete bedeuten

Paket Beschreibung

113

Anonyme Suche auf <ROOT>

114

 Antwort des LDAP-Servers mit der Anzeige zu den Namenkontexten aber insbesondere der verfügbaren Anmeldeverfahren:

117

 Nachdem der Client sich dann ein Kerberos-Ticket besorgt hat, kann er sich damit direkt anmelden

118

Die Anmeldung war erfolgreich und die Antwort wird geliefert

Sollte der LDAP-Client allerdings LDAPS, d.h. LDAP über TLS nutzten, dann können Sie hier nichts mehr mitlesen. Dann bleibt ihnen nur eine Diagnose-Funktion auf dem Client, einen Trace auf dem LDAP-Server oder sie extrahieren das Zertifikat samt privatem Schlüssel, um mit Wireshark die TLS-Verbindung zu decodieren.

Sonderfall UDP oder TCP

Bei einem Kunden ist mit in Verbindung mit Linux eine Konversation aufgefallen, die sie nicht verwirren sollte. Kerberos nutzt nicht immer den TCP-Port 88, sondern kann auch über UDP kommunizieren. In dem fall war es ein Linux-System welches sich zuerst per UDP mit dem Windows DC verbunden hat. Sie sehen Am Anfang auch ein paar PREAUTH_FAILED, auf die ich nicht weiter eingehe bis dann ein "KRB5KRB_ERR_RESPONSE_TOO_BIG" kommt. Die Authentifizierung hat in dem Fall also geklappt, aber der KDC kann die Antwort nicht in einem einzigen UDP-Paket zurücksenden. Das kann schon mal passieren, wenn in dem Ticket z.B. die Gruppenmitgliedschaften enthalten sind.

Es obliegt dann dem Client auf diese Fehlermeldung zu reagieren und auf "Kerberos over TCP" umzuschalten, was hier auch passiert. Windows selbst solle auch erst einmal UDP verwenden.

By default, the maximum size of datagram packets for which Windows Server 2003 uses UDP is 1,465 bytes. For Windows XP and for Windows 2000, this maximum is 2,000 bytes. Transmission Control Protocol (TCP) is used for any datagrampacket that is larger than this maximum. 
Quelle: How to force Kerberos to use TCP instead of UDP in Windows  https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/force-kerberos-use-tcp-instead-udp

Allerdings hat UDP auch seine Probleme, wenn Pakete fragmentiert werden, sie Microsoft im gleichen Artikel schreibt:

By default, Kerberos uses connectionless UDP datagram packets. Depending on a variety of factors including security identifier (SID) history and group membership, some accounts will have larger Kerberos authentication packet sizes. Depending on the virtual private network (VPN) hardware configuration, these larger packets have to be fragmented when going through a VPN. The problem is caused by fragmentation of these large UDP Kerberos packets. Because UDP is a connectionless protocol, fragmented UDP packets will be dropped if they arrive at the destination out of order.
Quelle: How to force Kerberos to use TCP instead of UDP in Windows  https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/force-kerberos-use-tcp-instead-udp

Die UDP-Probleme kenne ich auch schon bei VoIP mit IP und Loadbalancer. Siehe dazu auch Azure und Fragmentation.

Interessanterweise habe ich bei der ganzen Analyse mit Wireshark in einer Windows Umgebung keine Kerberos/UDP-Pakete gesehen. Als wenn Windows mittlerweile immer TPC nutzt.

Wireshark Offloading

Bei der Analyse habe ich speziell mit IPv6 auf ein "TGS-REQ" (Paket 285) eine Antwort in Paket 287 nicht analysieren können, da Wireshark das Paket nicht decodiert hat. Er lässt sich wohl von der "IPv6 Payload Length = 0" irritieren und versucht gar nicht erst die Nutzdaten zu decodieren, die aber im Hex-Auszug als Kerberos-Paket zu erkennen sind.

In dem Fall hilft es, die Offload-Funktion der Netzwerkkarte zu deaktivieren.

Blackhat

Man muss kein Hacker sein, aber Vorträge auf der Blackhat liefert oft viele Hintergrundinformationen. Sie zeigen aber auch, dass gefährlich ist, schwache Verschlüsselungsverfahren oder unsichere Clients zuzulassen. Programme wie Mimikatz u.a. versuchen z.B. das TGT abzugreifen, um damit weitere Tickets ohne Beisein des Benutzers zu erstellen. Angreifer können aber auch PAC umgehen, wenn der DC PAC nicht erzwingt.

WATCHING THE WATCHDOG: PROTECTING KERBEROS AUTHENTICATION WITH NETWORK MONITORING
https://www.blackhat.com/docs/eu-15/materials/eu-15-Beery-Watching-The-Watchdog-Protecting-Kerberos-Authentication-With-Network-Monitoring-wp.pdf

Watching The Watchdog: Protecting Kerberos Authentication With Network Monitoring
https://www.youtube.com/watch?v=7qbSFYVQJ7A&ab_channel=BlackHat

Weitere Links