Kerberos RC4 Abschaltung

Mit der Veröffentlichung von Vista und Windows 2008 hat Microsoft das DES-Verfahren bei Kerberos abgeschaltet. Mittlerweile ist AES128/AES256 der Stand der Zeit aber noch immer nutzen viele Dienste das unsicherere RC4. Noch hat Microsoft das Ende von RC4 nicht angekündigt aber das Windows Sicherheitsupdates im Nov 2022 hat den Default schon auf AES umgestellt.

Sie sollten dennoch schauen, dass Sie RC4 loswerden, ehe die Abschaltung irgendwann per Update erzwungen wird.

Nov 2022 Update deaktiviert RC4

Wenn ihre Windows XP oder Windows 2003 Server nicht mehr mitspielen oder SingleSignOn per Kerberos bei diversen Systeme nicht mehr geht, dann könnte das Windows Security Update November 2022 die Ursache sein. Das Updates ändern den "Default" bei ausgestellten Kerberbos Tickets von RC4 auf AES265 und wenn ihre Systeme AES nicht nutzen können (alte Version, falsche Konfiguration), dann funktioniert keine automatische Anmeldung per Kerberos, denn die Änderung deaktiviert in einigen Umgebungen faktisch das Ausstellen von RC4-Tickets.

Es gibt daher für den Nov 2022 Update ein "Out of band" Hotfix, um Probleme bei betroffenen Umgebungen zu lösen.

Allerdings löst das nicht auf allen Umgebungen die Probleme, speziell wenn Systeme nur RC4 können und ihre Clients AES anfordern und bekommen. Sie könnten nun z.B. per Gruppenrichtlinie alle Clients anweisen, RC4-Tickets anzufordern. Ratsam finde ich das nicht. Die Schlüssel sind eher interessant, um nur sichere Verfahren zuzulassen.

Besser finde ich aber für die fraglichen Server das Kerberos-Ticket mit RC4 ausstellen zu lassen, bis Sie den Server oder Service entsprechend aktualisiert haben. Die Lösung ist einfach: Sie setzen auf dem Computerkonto oder Dienstkonto das AD-Feld "msDS-SupportedEncryptionTypes" auf den Wert 7.

 Diese Feld ist normaler weise leer und wird damit auf "DES_CBC_CRC, DES_CBC_MD5, RC4" umgestellt.

Das ist natürlich keine keine Dauerlösung, wenn sie irgendwann R4 komplett deaktivieren wollen. Aber temporär kann es helfen.

Kurzfassung Kerberos

Ich möchte nur ganz kurz auf die Funktionsweise von Kerberos noch einmal eingehen, damit Sie besser einschätzen können, wie und wo RC4 zum Einsatz kommt: Kerberos ist ein Anmeldeverfahren mit signierten und verschlüsselten Tickets, bei denen folgende Komponenten zusammen kommen.

  • Ein Service oder Server
    Dort liegen Daten und Anwender dürfen nur authentifiziert darauf zugreifen. Früher hatte jeder Server seine eigene Benutzerdatenbank mit Kennworten. Das ist schon lange nicht mehr so und Server vertrauen in der Regel einem Authentifizierungsdienst. Das kann ein Active Directory oder anderer Identity Provider (IdP) sein.
  • Ein Client
    Hier ist der Anwender angemeldet und greift z.B. mit einem Browser auf den Server zu. Die Anmeldung erfolgte auch gegen das Active Directory oder ein andere IdP sein
  • Identity Provider
    Und dann gibt es die zentrale Stelle, die Identitäten verwaltet und authentifiziert.

Nach der Anmeldung des Clients am Server greift er (2) auf einen Service anonym zu und bekommt die Information (3) über die möglichen Anmeldeverfahren z.B. "Negotiate". Der Client geht dann zum KDC und fordert (4) ein Serviceticket an. Der KDC findet anhand des SPN ein Benutzer- oder Computer-Konto und stellt ein Ticket aus, welches mit dem PublicKey des Service verschlüsselt und dem private Key des KDC signiert ist. Das können Sie mit KLIST auf dem Client prüfen:

Der Client geht nun wieder mit dem Ticket zum Service (6) und der Server prüft das Ticket, ob der Signierer vertrauenswürdig ist und wenn er es entschlüsseln kann, findet er darin die Identität. Damit das funktioniert, muss der Client einen Algorithmus nutzen, der vom KDC zum Ausstellen von Tickets unterstützt und vom Service verstanden wird und an allen Stellen können Sie Verfahren aktvieren oder deaktivieren.

Einstellmöglichkeiten

Ich hatte schon in der Einleitung geschrieben, dass Sie über das Feld "msDS-SupportedEncryptionTypes" beim Dienstkonto bzw. Computerkonto bestimmen können, welche Kerberos-Tickets der KDC für die hinterlegten SPNs ausstellt. Bislang war das Feld immer leer aber kann über die MMC für Benutzer und Computer in Grenzen konfiguriert werden. Sie können hier z.B. AES128/AES256 aktivieren oder auch ein Downgrade aus DES erzwingen. Microsoft hat hier aber keinen eigenen Eintrag für z.B. RC4 in der GUI vorgesehen.

Sie sollten hier nur von den Defaults (leer oder 0) abweichen und Checkboxen setzen, wenn Sie genau wissen, was sie damit erreichen wollen und können. Es könnte durchaus sein, dass bei einem zukünftigen Update wieder etwas bricht, den Microsoft kann nicht alle Konstellation, insbesondere mit 3rd Party Produkten, überprüfen.

Zusätzlich gibt es natürlich noch die Gruppenrichtlinien und Registry, um auf Windows Servern, Domain Controllern (KDC) und Clients bestimmte Verfahren zu deaktivieren oder zu aktivieren. Auch hier sollten Sie nur dann Verfahren abschalten, wenn diese nicht mehr benötigt werden und die "besseren" Verfahren nicht abschalten.

November 2022 Patch

Eigentlich hat Microsoft mit dem Windows Security Update November 2022 einige Lücken schließen wollen. Leider hat dies auch einige Dienste gestört, die mit den Veränderungen nicht zurecht gekommen sind. Dennoch ist es nur eine Frage der Zeit, wann auch das RC4-Verfahren nicht mehr als sicher angesehen wird und daher deaktiviert werden sollte.

Auditing: AD-Objekte

Der erste Schritt ist eine Erfassung der aktuell genutzten Kerberos-Verfahren. Der erste Ort ist das Active Directory selbst. Der KDC im Active Directory kann nur Kerberostickets für Benutzer und Computer-Konten ausstellen, die er kennt und für die es einen SPN gibt. Insofern ist der erste Schritt die Auflistung aller Objekte, bei denen vielleicht das Feld "msDS-SupportedEncryptionTypes" nicht leer oder "0" ist, d.h. an denen manuell eine Einstellung der Verfahren vorgenommen wurde.
Für all diese Objekte sollten Sie nacheinander prüfen, ob Sie auch mit AES128/AES265 zurecht kommen. Kontrollieren sie die Konfiguration auf dem Service ehe die dann das Feld anpassen und eine Anmeldung mit einem aktualisierten Kerberos-Ticket versuchen.

Tipp: Schaue Sie vorher mit "Klist" nach, welches Ticket ihr Client aktuell bekommt hat, ändern Sie dann das Feld und waren die AD-Replikation ab und löschen Sie den lokalen Cache mit "klist purge". Beim nächsten Abruf sollte der Client ein aktuelles Ticket bekommen. Was die Anmeldung am Service erfolgreich und wird das gewünschte Verfahren angezeigt?

Auditing: KDC Eventlog

Der zweite Ort ist das Eventlog, welches Sie auf dem DC, genauer dem KDC, erst noch aktivieren müssen. Ich nutze dazu gerne die "Default Domain Controller"-Policy, damit alle Server auch abgedeckt sind.

Sie finden dann auf den Servern, die als Kerberos Distribution Center (KDC) genutzt werden, d.h. alle DCs, verschiedene Meldungen im Security Eventlog. Dort suchen Sie dann nach Meldungen der EventID 4768 und werten den "Ticket Encryption Type" aus.

Ticket Encryption Type (hex) Ticket Encryption Type (Dez) Status Beschreibung

0x1

01

DES-CBC-CRC

Sollte nicht erscheinen, da es seit Windows 7 / Windows 2008R2 by Default deaktiviert ist

0x3

03

DES-CBC-MD5

Sollte nicht erscheinen, da es seit Windows 7 / Windows 2008R2 by Default deaktiviert ist

0x11

17

AES128-CTS-HMAC-SHA1-96

Seit Windows 2008/Vista möglich und "sicher"

0x12

18

AES256-CTS-HMAC-SHA1-96

Seit Windows 2008/Vista möglich und "sicher"

0x17

23

RC4-HMAC

Standardverfahren vor Windows 2008/Vista und immer noch möglich

0x18

24

RC4-HMAC-EXP

Standardverfahren vor Windows 2008/Vista und immer noch möglich

0xFFFFFFFF

 

-

Fehlermeldung

Sie sehen aber auch, dass seit Windows 2008/Vista schon AES128/AES256 der Standard ist und mittlerweile alle System es können. Wer heute noch RC4 nutzt, sollte prüfen warum dem so ist.

# Suche nach TGT Ausstellung
Get-WinEvent `
    -LogName Security `
    -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4768)]]" `
| where {$_.properties[7].value -notin (17,18)}
# Suche nach Ticket Ausstellung
Get-WinEvent `
    -LogName Security `
    -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4769)]]" `
| where {$_.properties[5].value -notin (17,18)}

Denken Sie daran, dass Sie vielleicht die Größe des Security-Eventlog vergrößern müssen, um länger in die Vergangenheit zu blicken.

Bei der Menge der Events ist es sicher nicht sinnvoll, jedes mal per Event Action ein PowerShell-Skript zur Meldung zu starten. Da gibt es andere Weg wie Event Subscriptions, Syslog-Forwarding, SIEM etc.

Cleanup

Nun heißt es etwas "warten" und kontrollieren und anpassen. Sie müssen quasi jedem Event aus dem Eventlog nachgehen, warum ein Client vom KDC ein RC4/DES-Ticket für einen Service angefordert hat und die Ursache finden und beheben. Das ist eine mühsame Arbeit, insbesondere wenn 3rd Party-Produkte involviert sind, die per KEYTAB und anderen Einstellungen mit dem Active Directory verbunden wurde.

Knifflig wird es mit Client und Services, die kein AES128/AES256 können und nur RC4/DES verstehen. Dazu gehören z.B.: Windows XP und ältere Versionen, die maximal RC4 verstehen.

Ich weiß auch, dass es immer wieder Spezialfälle gibt, bei denen so alte Systeme noch genutzt werden und nicht einfach ersetzt werden können. Da hilft auch die Drohung mit "kein Support, Keine Security Updates" nicht weiter und die Firmen werden schon selbst solche Geräte in ein eigenes Subnetz mit strenger Abschottung verbannt haben.

Aber wenn sie ihr aktive primäres Active Directory auf AES umstellen und vielleicht auch noch TLS 1.2 erzwingen, SMB 1 abschalten, NTLMv1 und BasicAuth verbieten und andere Mindestvorgaben umsetzen, dann werden diese alten Schätzchen nicht mehr mitspielen. Einen allgemeinen Plan B gibt es hier leider nicht. Natürlich können Sie auf Kerberos verzichten und hoffen, dass eine Anmeldung per NTLMv2 noch möglich ist. Vielleicht läuft es am Ende auf ein wirklich komplett abgeschottetes eigenes Netzwerk hinaus, zu dem es nur ganz wenig klar definierte Übergabepunkte gibt die keine der beiden Seiten in Gefahr bringt.

RC4 deaktivieren

Wenn Sie sichergestellt haben, dass kein Computer/Benutzer-Objekte mehr RC4 oder DES anfordert und auch das Eventlog über einige Zeit hinweg keine RC4/DES-Tickets mehr ausgestellt hat, dann können Sie im nächsten Schritt auf allen Domain Controllern die Nutzung von RC4 deaktivieren. Dazu ist mindestens Windows 2008 und Windows Vista erforderlich. Frühere Versionen von Windows können noch kein AES. Aber heute sollten alle Versionen mit AES zurecht kommen.

Prüfen Sie bitte das Kennwort ihres KDC-Service Account und führen Sie ggfls. einen KRBTGT Key Rollover durch. Speziell wenn das Kennwort vor 2005 gesetzt wurde kann dies die Nutzung von AES blockieren.

Für Windows 2012/2012R2 Domain Controller benötigen Sie ggfls. einen Hotfix:

Sie können auch diese Härtung aber schrittweise umsetzen, indem Sie nicht gleich auf dem DC die Nutzung von RC4 abschalten, sondern per Gruppenrichtlinie auf den Clients die Nutzung von Kerberos auf AES128/AES256 und neuer beschränken:

GPO: Computer Configuration\Windows settings\Security Settings\Local Policies \Security Options

Damit verhindern Sie auf den so konfigurierten Clients und Servern die Nutzung von RC und DES.

Weitere Links