November-Update bringt 3 Patches für Domain-Controller (CVE-2022-37966, CVE-2022-37967, CVE-2022-38023)


    Tags: , , ,

    KerberosDas kumulative Update KB5019081 beseitigt drei Schwach­stellen im Kerberos- und Netlogon-Protokoll. Die Patches können erheb­liche Aus­wirkungen haben und erfordern daher eine Über­­prüfung oder Anpassung des Systems. Die Änderungen lassen sich teil­weise noch aufschieben, werden aber im nächsten Jahr vollständig durchgesetzt.

    Angreifer können die Schwachstellen CVE-2022-37966 und CVE-2022-37967 im Kerberos-Protokoll ausnutzen, um erhöhte Privilegien zu erlangen. Bei CVE-2022-38023 gilt Entsprechendes für das Netlogon-Protokoll.

    Änderung des Verschlüsselungsalgorithmus

    Der Grund für CVE-2022-37966 ist der schwache RC4_HMAC_MD5-Algorithmus, der bis dato als Standard verwendet wurde, solange man nicht explizit einen anderen zugewiesen hat.

    Richtlinie zur Festlegung des Verschlüsselungsalgorithmus für Kerberos

    Durch das aktuelle Update ändert Microsoft den Default für Session-Keys von User-Objekten, denen noch kein Standardverfahren zugewiesen wurde, auf AES. In Folge dessen können im Eventlog eines DCs unter System Einträge mit der ID 42 erscheinen. Die Meldung dazu lautet:

    The Kerberos Key Distribution Center lacks strong keys for account: accountname. You must update the password of this account to prevent use of insecure cryptography. See https://go.microsoft.com­/ fwlink­/?linkid=2210019 to learn more.

    In diesem Fall empfiehlt der Hersteller, das Passwort für krbtgt zurückzusetzen. Zu diesem Zweck stellt er das Script New-KrbtgtKeys.ps1 zur Verfügung.

    Um herauszufinden, welche Konten RC4 verwenden und somit für CVE-2022-37966 anfällig sind, schlägt Microsoft folgende Abfrage des AD vor:

    ((msDS-SupportedEncryptionTypes & 0x3F) != 0) && ((msDS-SupportedEncryptionTypes & 0x38) == 0)

    Unklar bleibt dabei jedoch, in welchem Kontext man sie verwenden kann und welcher Logik sie folgt.

    Wenn RC4 bei einem Konto aktiviert ist, dann wird im Attribut msDS-Supported­Encryption­Types das dritte Bit im 32-Bit Integer gesetzt, das entspricht dem Wert 0x4. Dies kann man so abfragen:

    Get-ADuser -Property msDS-SupportedEncryptionTypes `
    -Filter 'msDS-SupportedEncryptionTypes -band 0x4' |
    select name, msDS-SupportedEncryptionTypes

    Alternativ ginge das über einen LDAP-Filter:

    Get-ADUser -Property msDS-SupportedEncryptionTypes -LDAPFilter '(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4)'

    Im ADSI-Editor könnte man diese LDAP-Abfrage hinterlegen:

    (&(!(objectclass=computer))(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))

    LDAP-Abfrage von Konten, die durch CVE-2022-37966 gefährdet sind

    Update: Bei bestimmten Konstellationen führt dieses Update dazu, dass sich User oder gMSA nicht anmelden können.

    Änderung des Kerberos-Protokolls

    Als Reaktion auf CVE-2022-37967 signiert Microsoft künftig den Kerberos PAC Buffer, damit Angreifer diesen nicht mehr manipulieren können, um höhere Rechte zu erlangen. Diese Änderung bleibt bei ungültigen Signaturen vorerst noch folgenlos.

    Am 13. Dezember 2022 aktiviert Microsoft den Audit-Modus, der Tickets mit ungültiger Signierung über einen Eintrag im System-Log meldet (ID 43 und ID 44). Ab dem 11. Juli 2023 wechseln DCs dann in den Enforcement-Modus, in dem Signaturen valide sein müssen. Admins können dann noch bis zum 10. Oktober 2023 den Audit-Modus konfigurieren, danach ist dieser nicht mehr verfügbar.

    Für diesen Zweck ist der Registry-Key KrbtgtFullPacSignature vom Typ DWORD unter
    HKLM:\System\currentcontrolset\services\kdc
    vorgesehen. Ein Wert von 2 steht für den Audit Mode, 3 für den Enforcement-Modus, 0 deaktiviert das Feature und 2 signiert die PAC Buffer, verifiziert dies aber nicht. Letzteres ist aktuell die Vorgabe.

    Änderungen des Netlogon-Protokolls

    Microsoft reagiert auf CVE-2022-38023 mit der vollständigen Umstellung von RPC Signing auf RPC Sealing für Netlogon. Das November-Update erzwingt ab sofort RPC Sealing, vorerst aber nur im Kompatibilitäts­modus. Dabei müssen nur Windows-Geräte RPC Sealing verwenden.

    Ab dem 11. April 2023 verlangt Microsoft dieses Verfahren auch von Geräten mit einem anderen Betriebs­system. Allerdings können Admins dann noch bis zum 11. Juli in den Kompatibilitäts­modus zurückwechseln, danach ist das nicht mehr möglich.

    Dies lässt sich ebenfalls über einen Registry-Schlüssel steuern, nämlich RequireSeal unter
    HKLM:\ \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
    Dabei steht der Wert 1 für Kompatibilität und 2 für die Durchsetzung von RPC Sealing.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Wolfgang Sommergut

    Wolfgang Sommergut hat lang­jährige Erfahrung als Fach­autor, Berater und Kon­ferenz­sprecher zu ver­schie­denen Themen der IT. Da­ne­ben war er als System­ad­mi­ni­stra­tor und Con­sultant tätig.
    // Kontakt: E-Mail, XING, LinkedIn //

    Ähnliche Beiträge

    Weitere Links

    4 Kommentare

    Hallo Wolfgang, vielen Dank für den Artikel und die Hinweise. Leider führt die Abfrage auf meinem DC in der PowerShell zu keinem Ergebnis und im ADSI-Editor zu einer Fehlermeldung "Fehler bei Vorgang. Fehlercode: 0x8007203e Der Suchfilter wurde nicht erkannt). Hast du eine Idee, was ich da falsch mache? Beste Grüße, Thomas

    @Thomas: Kein Ergebnis bedeutet doch eigentlich nur das kein Konto RC4 verwendet, was ja gut ist.

    Bild von Wolfgang Sommergut

    Der Supported Encryption Type wird als Bitmaske in einem long Integer gespeichert. Über das bitweise UND mit den zwei Werten versucht die Abfrage offenbar, alle Kombinationen zu entdecken, die RC4 enthalten. Leider gibt das Support-Dokument dazu keine Erklärung. Ich habe die Abfrage nur in LDAP-Syntax übersetzt, die Logik ist die gleiche. Sie scheint aber nicht zu funktionieren.

    Wer auf Nummer sicher gehen will, kann sich an dieser Tabelle orientieren und auf die Schnelle den Verschlüsselungstyp so abfragen:

    get-aduser -Property msDS-SupportedEncryptionTypes -filter 'msDS-SupportedEncryptionTypes -band 0x4'

    Dieses Update bringt eine gehärtete Kerberos-Umgebung (RC4 deaktiviert) mehr oder weniger zum Erliegen. SQL Management Studio (und in meinem Fall auch eine Asp.Net Core Webseite) melden "Cannot generate SSPI context" und verweigern jegliche Verbindung.
    MSTSC /remoteguard meldet "The encryption type is not supported by the KDC" oder "The function requested is not supported", und dann keine Verbindung. Beide Verbindungsarten funktionieren problemlos über NTLM (IP statt DNS Name). Na das wird ein spannender Montag.