CISA warnt vor Installation der Mai 2022-Updates auf Windows Domain Controllern

Windows[English]Die US-CERT CISA (Cybersecurity & Infrastructure Security Agency) hat die Schwachstelle CVE-2022-26925 vorübergehend aus dem Katalog der bekannten Sicherheitslücken (Known Exploited Vulnerabilities) entfernt und warnt US-Organisationen davor, die Mai 2022-Updates für Windows auf Maschinen zu installieren, die als Domain Controller fungieren. Damit reagiert die Behörde auf die Authentifizierungsprobleme im Zusammenhang mit den Updates und DCs. Ergänzung: Es gibt einen Fix.


Anzeige

Die CISA-Warnung

Die Warnung der Cybersecurity & Infrastructure Security Agency (US-CERT CISA) findet sich in nachfolgendem Tweet vom 14. Mai 2022 (ich hier auf die Thematik aufmerksam geworden) und ist im Detail in diesem Beitrag nachzulesen. Die Aussage:

CISA is temporarily removing CVE-2022-26925 from its KEV Catalog

Die CISA entfernt CVE-2022-26925 vorübergehend aus ihrem Katalog bekannter Sicherheitsrisiken, da das Risiko von Authentifizierungsfehlern besteht, wenn das Microsoft (Rollup-)Update vom 10. Mai 2022 auf Domänencontrollern angewendet wird. Nach der Installation des Rollup-Updates vom 10. Mai 2022 auf Domänencontrollern kann es in Unternehmen zu Authentifizierungsfehlern auf dem Server oder Client für Dienste wie Network Policy Server (NPS), Routing and Remote Access Service (RRAS), Radius, Extensible Authentication Protocol (EAP) und Protected Extensible Authentication Protocol (PEAP) kommen.

Die CISA gibt kein einzelnes Update an, betroffen sind aber alle im Support befindlichen Windows Server, die als Domain Controller fungieren. Microsoft hat die CISA über dieses Problem mit der Zuordnung von Zertifikaten zu Computerkonten auf Domänencontroller informiert. Die Installation der gleichen Windows-Updates vom 10. Mai 2022 wird jedoch für Clients und Windows-Server, die keine Domänencontroller sind, dringend empfohlen. Dort gibt es das Zertifikatsproblem nicht.

Der Hintergrund

Zum 10. Mai 2022 hat Microsoft Sicherheitsupdates für alle unterstützten Windows-Versionen (Clients und Server) zum Schließen der Windows LSA Spoofing-Schwachstelle CVE-2022-26925 veröffentlicht. Über diese Schwachstelle könnte ein nicht authentifizierter Angreifer eine Methode der LSARPC-Schnittstelle aufrufen und Domänencontroller dazu zwingen, sich mit NTLM beim Angreifer zu authentifizieren. Die Schwachstelle hat einen CVSS-Wert von 9.8 erhalten, ist also recht kritisch. Microsoft empfiehlt im Artikel zu CVE-2022-26925 der Aktualisierung von Domänencontrollern Priorität einzuräumen.

Ich hatte die veröffentlichten Updates u.a. im Blog-Beitrag Microsoft fixt (PetitPotam) NTLM Relay-Schwachstelle (CVE-2022-26925) mit Windows Mai 2022-Update aufgeführt und dort auch einiges zur Schwachstelle geschrieben. Das Problem bei diesem Ansatz ist, dass durch die Updates Authentifizierungsfehler (Zertifikate-Fehler) hervorgerufen werden, wenn sich Clients oder Server am jeweiligen Domain Controller anmelden wollen. Ich hatte dies im Blog-Beitrag Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client) angesprochen.

Microsoft hat den Fehler bestätigt und arbeitet an einem Fix (siehe You might see authentication failures on the server or client for services). Als Notlösung wird die manuelle Zuordnung von Zertifikaten zu einem Maschinenkonto im Active Directory vorgeschlagen. Microsoft hat zudem den Beitrag ADV210003 Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) zum Schützen der Systeme vor solchen Angriffen veröffentlicht. Weiterhin gibt es noch Supportbeitrag KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) zum Thema. Wenn die bevorzugte Abhilfemaßnahme in Ihrer Umgebung nicht funktioniert, finden sich unter KB5014754—Certificate-based authentication changes on Windows domain controllers weitere mögliche Abhilfemaßnahmen im Abschnitt SChannel-Registrierungsschlüssel.

Während Microsoft die Deinstallation des Updates nicht empfiehlt, hat die CISA jetzt aber die zu schließende Schwachstelle von der Liste bekannter Sicherheitsrisiken temporär entfernt. Das bedeutet, dass Administratoren wegen der Fehler dieses Updates vorerst nicht auf Windows Domänencontrollern installieren müssen.

Ergänzung: Im Artikel Microsoft fixt (PetitPotam) NTLM Relay-Schwachstelle (CVE-2022-26925) mit Windows Mai 2022-Updatehabe ich die Mai 2022-Updates aufgelistet.


Anzeige

Ergänzung 2: Es gibt ein Sonderupdate vom 19. Mai 2022, was das Problem patchen soll – siehe Windows Out-of-Band-Updates (19.5.2022) fixen AD-Authentifizierungsfehler und Store-Installationsfehler.

Ähnliche Artikel:
Microsoft Security Update Summary (10. Mai 2022)
Patchday: Windows 10-Updates (10. Mai 2022)
Patchday: Windows 11/Server 2022-Updates (10. Mai 2022)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (10. Mai 2022)
Exchange Server Sicherheitsupdates (10. Mai 2022)
Microsoft fixt (PetitPotam) NTLM Relay-Schwachstelle (CVE-2022-26925) mit Windows Mai 2022-Update

Patchday-Nachlese: Probleme mit April 2022-Updates
Windows, Office: Mai 2022 Patchday-Probleme und Besonderheiten
Windows 11: Update KB5013943 erzeugt Fehler 0xc0000135
Windows 11 Update KB5013943 verursacht Probleme mit DATEV (0xc0000135)
Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client)
Windows 11 Update KB5013943 erzeugt BlueScreens mit Sophos-Treiber
Windows Server 2022: März 2022-Update KB5011497 verursacht Probleme mit Remote-Desktop-Rollen/-Verbindungen
Windows Server 2022: Lösung für Remote Desktop-Probleme mit Update KB5011497
Windows Server 2022: Wie ist der Status beim RDS-Bug (RDCB-Rolle), verursacht durch KB5011497?
Windows Update KB5012599: Fix für Installationsfehler 0x8024200B und 0x800F0831 kommt
Microsoft fixt (PetitPotam) NTLM Relay-Schwachstelle (CVE-2022-26925) mit Windows Mai 2022-Update


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Update, Windows Server abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

33 Antworten zu CISA warnt vor Installation der Mai 2022-Updates auf Windows Domain Controllern

  1. Martin Wildi sagt:

    Danke, Günter.

    Du weisst nicht, wie wertvoll dein Blog für uns Admins ist! Nirgends sonst krieg ich derart aktuell und gebündelt genau die Infos, die ich als Admin von diversen KMU's benötige!

    Danke!

  2. Stefan sagt:

    The gift that keeps on giving. Wo bleibt denn endlich die Haftung bei solchen Updatefehlern? Auch wenns abgedroschen klingt: Wo soll das alles noch hinführen?

    • Olli sagt:

      Das ist der Punkt! Aber das Problem löst sich erst, wenn es in den USA verstanden wird. Werden Microsoft und Co. in den USA mit Multi-Milliarden-US$ Strafen belegt für miese Software Qualität und Update-Fehler, dann handeln die ganz schnell. Die USA müssen verstehen, dass diese Probleme der Hauptgrund für den ganzen Sicherheitskritischen IT-Scheiß sind.

      Oder anders gesagt: Erst wenn die USA an einer wirklich üblen Stelle getroffen werden und als Ursache das Zurückziehen des Patches wegen Pachtfehlern ausgemacht wird wird sich etwas bewegen.

      So schlimm das klingt, aber erst wenn es in den USA richtig knallt, besteht die Chance auf Besserung – anders lernen Amerikaner nicht.

      • Michael sagt:

        … "anders lernen Amerikaner nicht" …

        Nicht nur Amerikaner, 98% der Menschheit.

      • Stefan sagt:

        Darauf wirds wohl hinauslaufen. Es muss wohl noch mehr Szenen wie bei Atlassian geben wo allen mal das ganze auf die Füße fällt. Ich finds nur heftig das da gerade in den US die "regierungsnahen" Firmen gezwungen werden durch Compliance patches auszurollen um ja nicht ihre Verträge zu verlieren und dann eben die CISA warnen muss das dann doch besser zu lassen… und was lernen alle daraus? Nix. Hier müsste wohl die US-Regierung den Softwareunternehmen wohl wirklich Strafzahlungen aufbrummen das es sich gewaschen hat bevor sich da was rührt.

    • Robert sagt:

      Wenn ich dann so etwas lese: https://www.heise.de/news/EU-Cybersicherheit-Firmenchefs-sollen-fuer-Datenpannen-haften-7091905.html

      Dies ist ein riesengroßer Schwachsinn seitens der EU!
      Die sollen die Softwareentwickler in die Verantwortung nehmen, die zu blöd sind, sauberen Code zu schreiben.
      Aus – fertig!
      Da sieht man mal wieder die Lobbyisten und die ahnungslosen Politiker Hand in Hand voranschreiten. Klasse EU – ihr seid die Grössten :(

    • Paul sagt:

      In die Cloud! Dann hat MS selbst das Problem und testet die Qualität besser rein.

  3. BK sagt:

    Puuuuuhhh nochmal Glück gehabt :-)

    Alle Mai Updates installiert und keine Schwierigkeiten. Alle DC's, RDP Server und Clients laufen einwandfrei.

    • Robert sagt:

      Bei uns auch :)
      DCs, RODCs, RDP Server, Exchange und alle Workstations fühlen sich mit den Mai Updates wohl.
      Die Zitterpartie geht dann am 14. Juni wieder los…

    • Robert Glöckner sagt:

      ich habe die DC bisher ausgelassen, aber andererseits habe ich keinen der genannten Dienst in Benutzung und wüßte auch nicht wozu die gut sein sollten. VPN u.ä. geht über eine dezidierte Firewall, ich werde sicher keinen DC direkt aus dem Internet erreichbar machen…

  4. Drfuture sagt:

    Wäre das ein Linux Problem würde dort vermutlich so etwas stehen wir "ist im Standart nicht so konfiguriert, trifft doch eh fast nirgends zu" und ähnliches.
    Keine Frage weniger Fehler sind immer besser und Microsoft könnte die Qualität noch verbessern.
    Sehr häufig meldet die Presse aber weltweit eine Problem in Windows nach einem Update, egal wie viele es betrifft.
    Bei > 1milliarde Installationen und Kombinationen / Konfigurationen ist die Wahrscheinlichkeit sehr hoch das es zu Problemen kommt.
    Egal welche Software, bei Millionen Codezeilen kommt es immer wieder zu fehlen. Auch bei jedem opensource Projekt werden ständig Fehler gemeldet?

    Das Problem hier betrifft auch nicht jeden DC sondern nur wenn eine eigene PKI im Hause betrieben wird und diese Zertifikate zur Authentifizierung konfiguriert sind. In größeren Unternehmen die so etwas machen ist aber oft radius und ca von Drittherstellern, hier tritt das Problem, soweit ich das bisher gelesen habe nicht auf.
    Evtl. Betrifft es eine Hand voll große Firmen oder oft dann irgend eine Behörde die das so betreibt und daher ist es dann auch ein "wichtiges" Problem. Die Maße ist es aber zumindest in diesem Fall, nicht.

    Wenn es eine Haftung in Zukunft geben sollte, dann regen sich die Admins vermutlich auf das Microsoft einen großen Satz Optionen streicht und die sichersten Einstellungen zur Pflicht macht und damit ganz viel Soft und Hardware anderer Hersteller ausschließt. Nur um sich nicht angreifbar zu machen und Anwender/Admin Fehler die gemacht werden auszuschließen.

    • Martin Hess sagt:

      Wifi mit WPA-Enterprise, welches über eine interne CA und einen NPS Server funktionieren, gehören wohl inzwischen zum Standard auch in KMU's. Somit sind dann auch diese von diesem Bug betroffen.

      • 1ST1 sagt:

        Wir hatten das auch mal, aber diese Variante von WPA-Enterprise konzentiriert sich rein auf Windows-Clients, Linux und Mac außen vor. Daher haben wir das wieder abgeschafft, bei uns machen die Notebooks im WLAN einen VPN-Tunnel auf, da ist dann das Betriebssystem egal, und es ist nicht mehr ortsgebunden.

      • Stefan A. sagt:

        @Martin Hess
        Habt ihr das so im Einsatz?
        Mai Updates auf den DCs schon eingespielt?
        Denn wir haben das nämlich genauso im Einsatz.
        Gruß Stefan

        • Martin Hess sagt:

          Hallo Stefan

          Ja, mehrfach genau so bei Kunden im Einsatz. Mit dem Mai Update sehen wir auf dem NPS die genannten Fehler. Spannenderweise funktioniert der Login dann trotzdem, wenn die Verschlüsselung WPA2 Enterprise ist. Benutzt man WPA3 Enterprise, so ist kein Login mehr möglich.

          • Stefan A. sagt:

            Hallo Martin!

            Habt ihr das dann so wie Robert weiter unten beschreibt mit dem Wert auf 0x1F setzen wieder gefixt?
            Oder wie habt ihr das auftretende Problem dann gelöst?

            Viele Grüße
            Stefan

  5. Holger Vogel-Otto sagt:

    Ich kann mich den vielen Admins nur anschließen, herzlichen Dank an Günter Born, dieser Blog ist schon elementar wichtig für UNS!

  6. Stefan A. sagt:

    @BK @Robert
    Habt ihr einen NPS am laufen der z.B. mit Computer Zertifikaten seine WLAN Clients authentifiziert?

    • Robert sagt:

      Auth. mit Zertifikaten -> NEIN!
      Aber selbst wenn wir welche hätten, hätte ich dies eingespielt! (die Mai Updates wg. LSA und Co. sind einfach zu wichtig)
      WICHTIG dabei ist nur im Anschluß mit Registry-Settings gegenzusteuern, bis MS das mal fixt… – und zwar so: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

      Dieser Abschnitt ist entscheidend:

      => Also einfach den 'alten' Wert von 0x1F wieder eintragen in: HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel\
      unter CertificateMappingMethods (ist ein DWORD)

      The SChannel registry key default was 0x1F and is now 0x18. If you experience authentication failures with
      Schannel-based server applications, we suggest that you perform a test. Add or modify the CertificateMappingMethods
      registry key value on the domain controller and set it to 0x1F and see if that addresses the issue.
      Look in the System event logs on the domain controller for any errors listed in this article for more information.
      Keep in mind that changing the SChannel registry key value back to the previous default (0x1F) will revert to using
      weak certificate mapping methods.

      Registry Subkey

      HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel\

      Value

      CertificateMappingMethods

      Data Type

      DWORD

      Data

      0x0001 – Subject/Issuer certificate mapping (weak – Disabled by default)
      0x0002 – Issuer certificate mapping (weak – Disabled by default)
      0x0004 – UPN certificate mapping (weak – Disabled by default)
      0x0008 – S4U2Self certificate mapping (strong)
      0x0010 – S4U2Self explicit certificate mapping (strong)

  7. Günter Born sagt:

    Kurze Info für Admins, die die Mai 2022-Updates noch nicht eingespielt haben. Laut obigem Artikel rät die CISA wegen der Zertifikate-Problematik noch zu warten, bis Microsoft neue Milch gibt.

    Ich habe noch eine (allerdings sehr magere) Information zu einem anderen Bug (vermutlich Absturz) bekommen. Kann nach der Installation des Mai 2022 Updates auf DCs auftreten. Zur Vermeidung sind vor der Update-Installation bestimmte Einstellungen zu beachten. Aktuell läuft meine Anfrage an den betreffenden Escalation Ingineer, ob ich das publizieren darf und ob er noch ein paar an Details verrät. Wenn ich kein definitives Stopp bekomme, plane ich einen Artikel für die kommenden Tage. Also noch mit der Update-Installation warten.

  8. Drfuture sagt:

    Sicher? Hier kommuniziert ja im Normalfall der NPS-Server mit dem dc der dann vermutlich kein WLAN Zertifikat hat mit dem er sich authentifiziert?
    Ist nur eine Überlegung, Belegen kann ich es nicht.

  9. Emeriks sagt:

    Bitte mal den Text anpassen, sonst ist dieser mißverständlich.

    "… warnt … Updates nicht … zu installieren"
    ist für mich eine implizite Empfehlung oder gar Aufforderung zur Installation.

    Ich schätze, gemeint ist aber:
    "… warnt davor, diese Updates zu installieren …"

    Oder?

Schreibe einen Kommentar zu Holger Vogel-Otto Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.