[English]ACROS Security ist auf eine bisher nicht per Update geschlossene Schwachstelle in Windows gestoßen, die per URL die Offenlegung von NTLM Hash-Werten ermöglicht. ACROS Security hat einen opatch Micropatch veröffentlicht, um diese Schwachstelle zu beseitigen. Bis zum Bereitstellen eines Updates durch Microsoft ist der opatch-Micropatch kostenlos verfügbar.
Mitja Kolsek hat mich die Nacht auf X mittels folgendem Tweet auf diesen Sachverhalt und die opatch-Lösung hingewiesen, die im Detail im Beitrag URL File NTLM Hash Disclosure Vulnerability (0day) – and Free Micropatches for it beschrieben ist.
Sicherheitsforscher von ACROS Security sind kürzlich auf eine Sicherheitslücke in allen Windows Workstation- und Server-Versionen von Windows 7 und Server 2008 R2 bis hin zum neuesten Windows 11 v24H2 und Server 2022 gestoßen.
Die Schwachstelle ermöglicht es einem Angreifer, die NTLM-Anmeldeinformationen des Benutzers zu erhalten. Der Angreifer muss den Benutzer einfach dazu bringen, eine bösartige Datei im Windows Explorer anzuzeigen. Das kann z. B. durch Öffnen eines freigegebenen Ordners oder eines USB-Datenträgers mit einer solchen Datei oder durch Anzeigen des Ordners „Downloads“, in dem eine solche Datei zuvor automatisch von der Webseite des Angreifers heruntergeladen wurde, erfolgen.
Details zu dieser Sicherheitslücke werden zurückgehalten, bis Microsoft eine Lösung zur Beseitigung der Schwachstelle bereitstellt. Das soll das Risiko einer böswilligen Ausnutzung zu minimieren. Die Sicherheitsforscher haben haben dieses Problem an Microsoft gemeldet – ein Sicherheitsupdate steht noch nicht von Redmond bereit.
ACROS Security hat jedoch Micropatches zum Entschärfen dieser Schwachstelle entwickelt und stellt diese über den 0patch-Agenten solange kostenlos bereit, bis Microsoft ein offizielles Update zur Verfügung stellt.
Diese Micropatches wurden bereits an alle betroffenen Online-Computer mit 0patch Agent in PRO- oder Enterprise-Konten verteilt und auf diese angewendet (es sei denn, die Enterprise-Gruppeneinstellungen haben dies verhindert).
ACROS Security hat Micropatches für die nachfolgend aufgelisteten Windows-Versionen geschrieben und stellt diese auch in der opatch-Free-Version bereit (bis Microsoft ein offizielles Update veröffentlicht.
Ältere Windows-Versionen:
Windows 11 v21H2 – vollständig aktualisiert
Windows 10 v21H2 – vollständig aktualisiert
Windows 10 v21H1 – vollständig aktualisiert
Windows 10 v20H2 – vollständig aktualisiert
Windows 10 v2004 – vollständig aktualisiert
Windows 10 v1909 – Vollständig aktualisiert
Windows 10 v1809 – Vollständig aktualisiert
Windows 10 v1803 – vollständig aktualisiert
Windows 7 – vollständig aktualisiert, ohne ESU, ESU 1, ESU 2 oder ESU 3
Windows Server 2012 – vollständig aktualisiert, keine ESU oder ESU 1
Windows Server 2012 R2 – vollständig aktualisiert, keine ESU oder ESU 1
Windows Server 2008 R2 – vollständig aktualisiert, keine ESU, ESU 1, ESU 2, ESU 3 oder ESU 4
Windows-Versionen, die noch Windows Updates erhalten:
Windows 11 v24H2 – vollständig aktualisiert
Windows 11 v23H2 – vollständig aktualisiert
Windows 11 v22H2 – vollständig aktualisiert
Windows 10 v22H2 – vollständig aktualisiert
Windows Server 2022 – vollständig aktualisiert
Windows Server 2019 – vollständig aktualisiert
Windows Server 2016 – vollständig aktualisiert
Windows Server 2012 – vollständig aktualisiert mit ESU 2
Windows Server 2012 R2 – vollständig aktualisiert mit ESU 2
Hinweise auf 0patch finden sich in den nachfolgend verlinkten Blog-Beiträgen.
Ähnliche Artikel:
0patch: Fix für Internet Explorer 0-day-Schwachstelle CVE-2020-0674
0patch-Fix für Windows Installer-Schwachstelle CVE-2020-0683
0patch-Fix für Windows GDI+-Schwachstelle CVE-2020-0881
0-Day-Schwachstelle in Windows Adobe Type Library
0patch fixt 0-day Adobe Type Library bug in Windows 7
0patch fixt CVE-2020-0687 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1048 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1015 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1281 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1337 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1530 in Windows 7/Server 2008 R2
0patch fixt Zerologon (CVE-2020-1472) in Windows Server 2008 R2
0patch fixt CVE-2020-1013 in Windows 7/Server 2008 R2
0patch fixt Local Privilege Escalation 0-day in Sysinternals PsExec
0patch fixt Windows Installer 0-day Local Privilege Escalation Schwachstelle
0patch fixt 0-day im Internet Explorer
0patch fixt CVE-2021-26877 im DNS Server von Windows Server 2008 R2
0patch fixt Windows Installer LPE-Bug (CVE-2021-26415)
0Patch bietet Support für Windows 10 Version 1809 nach EOL
Windows 10 V180x: 0Patch fixt IE-Schwachstelle CVE-2021-31959
0Patch Micropatches für PrintNightmare-Schwachstelle (CVE-2021-34527)
0patch-Fix für neue Windows PrintNightmare 0-day-Schwachstelle (5. Aug. 2021)
0patch-Fix für Windows PetitPotam 0-day-Schwachstelle (6. Aug. 2021)
2. 0patch-Fix für Windows PetitPotam 0-day-Schwachstelle (19. Aug. 2021)
Windows 10: 0patch-Fix für MSHTML-Schwachstelle (CVE-2021-40444)
0patch fixt LPE-Schwachstelle (CVE-2021-34484) in Windows User Profile Service
0patch fixt LPE-Schwachstelle (CVE-2021-24084) in Mobile Device Management Service
0patch fixt InstallerTakeOver LPE-Schwachstelle in Windows
0patch fixt ms-officecmd RCE-Schwachstelle in Windows
0patch fixt RemotePotato0-Schwachstelle in Windows
0patch fixt erneut Schwachstelle CVE-2021-34484 in Windows 10/Server 2019
0Patch fixt Schwachstellen (CVE-2022-26809 und CVE-2022-22019) in Windows
Windows MSDT 0-day-Schwachstelle „DogWalk“ erhält 0patch-Fix
0Patch Micro-Patch gegen Follina-Schwachstelle (CVE-2022-30190) in Windows
0patch fixt Memory Corruption-Schwachstelle (CVE-2022-35742) in Microsoft Outlook 2010
Windows 7/Server 2008 R2: Erhalten auch 2023 und 2024 0patch Micropatches
Windows: 0Patch Micropatch für MOTOW-ZIP-File-Bug (0-day, kein CVE)
Windows: 0Patch Micropatch für MotW-Bypassing 0-day (kein CVE)
Windows Server 2012: Inoffizieller 0patch-Fix für MoW 0-day-Schwachstelle
Hallo Zusammen,
ist es nicht CVE-2024-43451, die in diesem Post thematisiert wird?
Die wurde seiner Zeit von ClearSky entdeckt.
Tja, wenn man noch NTLM aktiv hat……………….
Man sollte mal langsam darüber nachdenken, NTLM netzwerkweit zu deaktivieren und auf Kerberos zu wechseln.
Das ist hier schon vor längerer Zeit geschehen.
NTLM wird nirgends mehr verwendet und ist per GPO deaktiviert.
Daher laufen alle Angriffe auf NTLM komplett ins Leere.
Ich empfehle mal den Artikel von Mark Heitbrink zu lesen, derzeit ist es eine aussichtslose Schlacht, NTLM einfach abschalten zu wollen. Und das betrifft nicht nur RDP ohne die Server per FQDN anzusprechen, sondern auch unzählige Appliances und diverse andere Sünden der Vergangenheit wie Server per IP anzusprechen.
https://www.gruppenrichtlinien.de/artikel/rdp-ohne-ntlm-richtlinien-und-verhaltensweisen-zur-reduktion-von-ntlm
Grundsätzlich stimme ich dir zu. Blöd, wenn aber noch Anwendungen im Einsatz sind die es benutzen. Oder (kleine Anekdote am Rande) zum Haareraufen wenn man auf Entwickler trifft, die behaupten daß Kerberos in ihrer Entwicklungsumgebung nicht unterstützt würde, wenn man ihnen vorwirft, veraltete Protokolle zu benutzen. Obwohl es seit mehr als 20 Jahren eine bessere Alternative gibt (so geschehen anno 2021).
NTLM
Langer Rede kurzer Sinn: Es gibt Scenarien, in denen man nicht auf NTLM verzichten kann, weil Kerberos nicht zur Verfügung steht.
– Anmeldung von einem Workgroup Client, z.B. eine Variante einer PAW, die den DomClient dann als Virtuelles System hosted, selber aber ausserhalb bleibt.
– Jegliche Anmeldungen mit Lokalen Konten. Das per LAPS geschützte Adminkonto ist in seinem Impakt, wenn es attackiert wird, die kleinste Angriffsfläche und sollte deswegen zur Administration der Clients verwendet werden. Die lokale LSA kann dir kein Kerbero bereitstellen.
– RDP mit NLA. Die Netzwerk Vor-Authentifizierung macht NTLM, wenn kein RD Gateway vorhanden ist oder auf NLA schlicht verzichtet.
– Manchmal kann man ein System nur per IP erreichen, dann machen RDP/UNC/RPC etc NTLM
– Drittanbieter sind in meiner privaten Statistik das kleinste Problem
„Es gibt Scenarien, in denen man nicht auf NTLM verzichten kann, weil Kerberos nicht zur Verfügung steht.“
Dann aber Port 445 (outgoing) an der Firewall sperren und gut ist. Sollte in 99% der Fälle bzgl. NTLM Exploits helfen.
Am Windows Client/Server, in der Windows Firewall?
Keine gute Idee. Dann beerdigst du deine Fileshares, auf die dann nicht mehr zugegriffen werden kann.
Nein, er meint sicher am Router bzw „Firewall Device“.