[English]Microsoft hat zum 8. August 2024 (mit Update vom 10. August 2024) eine Warnung von einer ungepatchten Spoofing-Schwachstelle CVE-2024-38200 veröffentlicht. Die Schwachstelle ist in allen Office-Versionen (Office 2016 – 2021, Office 365) enthalten.
Spoofing-Schwachstelle CVE-2024-38200
Im Beitrag zur Schwachstelle CVE-2024-38200 warnt Microsoft vor einer Microsoft Office Spoofing Vulnerability, der ein CVSS 3.1 Index von 7.5 zugewiesen wurde. Angreifer haben die Möglichkeit, über eine spezielle oder kompromittierte Webseite eine Datei bereitzustellen, um die Schwachstelle auszunutzen. Über die Sicherheitslücke könnten NTLM-Hashes gegenüber Remote-Angreifern offengelegt werden.
Der Angreifer müsste aber den Benutzer dazu bringen, auf einen Link zu klicken, (z.B. in einer E-Mail oder Instant Messenger-Nachricht), und ihn dann dazu bringen, die speziell gestaltete Datei zu öffnen. In diesem Fall könnte der Angreifer Informationen vom Zielsystem abrufen. Betroffen sind die folgenden 32- und 64-Bit-Versionen von Office:
- Microsoft Office 2016
- Microsoft Office 2019
- Microsoft Office LTSC 2021
- Microsoft 365 Apps
Microsoft stuft die Ausnutzung als „Exploitation Less Likely“ ein – bei den Kollegen von Bleeping Computer lese ich, dass die MITRE hat die Wahrscheinlichkeit einer Ausnutzung dieser Art von Schwachstelle als sehr wahrscheinlich eingestuft habe.
Office durch Feature Flighting geschützt
Am 13. August 2024 wird vermutlich ein Update zum finalen Schließen der Schwachstelle ausgerollt. Microsoft schreibt aber, dass man eine alternative Lösung für dieses Problem gefunden, und am 30.7.2024 per Feature Flighting aktiviert habe. Kunden seien bereits mit allen unterstützten Versionen von Microsoft Office und Microsoft 365 geschützt. Kunden sollten dennoch auf die Updates vom 13. August 2024 aktualisieren, um die endgültige Version des Fixes zu erhalten.
Microsoft gibt Administratoren im Beitrag zur Schwachstelle CVE-2024-38200 noch Hinweise zu drei Methoden, um ausgehenden NTLM-Datenverkehr zu blockieren.
Feature Flighting? Eine neue Lage an Pseudo-Security-Abstraktionsschicht im Windows?
> Laut Microsoft gibt Administratoren im Beitrag zur Schwachstelle CVE-2024-38200 noch Hinweise zu drei Methoden, um ausgehenden NTLM-Datenverkehr zu blockieren.
Das was Du schreibst, ist leider die Wiedergabe des Microsoft Bullshits. Der Beitrag zum CVE 2024-38200 verweist weiter auf dieses Allgemein-Erklär-Plätzchen:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers#policy-management
Fazit: Der sicherste Windows Rechner/Netzwerk/AD ist das, was offline betrieben wird und ein Admin den Datenverkehr an einem oder mehreren Proxies/Gateways kontrolliert.
Einfach den Port 445 ausgehend in der Firewall sperren, dann geht kein NTLM-Traffic nach außen.
Da gab es schon in der Vergangenheit viele Sicherheitslücken, die man dadurch wirkungslos machen kann, da die auch immer ausgehenden NTLM-Traffic erzeugen.
Hier ist übrigens NTLM schon lange abgeschaltet, das ganze Netzwerk ist Kerberos only.
Das sollte man prüfen, ob das im eigenen Netzwerk möglich ist und wenn ja, dann NTLM abschalten.
Denn immer wieder tauchen neue Sicherheitslücken auf, die ausgehenden NTLM-Traffic nutzen, um Hashes abzugreifen.
Und natürlich sollten in einer Firewall nur die Ports, sowohl eingehend als auch ausgehend, offen sein, die man zwingend benötigt.
Ich komm mir gerade blöd vor zu fragen: aber ist der zu blockende Port 445 Remote oder local.
also
lokalenetze:1bis65535 > Internet:445
oder
lokalenetze:445 > internet:1-65535
oder beides?
Richtung Internet.
Am besten in der Hardwarefirewall des Routers blockieren.
Unsere FW-Systeme haben explizit „DENY“ als Abschlussregel und man muss alles andere, was man haben möchte freigeben.
Mit welchen System arbeitet Ihr, wenn ihr das als „DENY“ Regel erstellen müsst? Ich kenne jetzt keinen Hersteller der vom Hause aus die Regel „ALLOW ALL“ als „Default“ Regel aktiv hat.
Danke schön. Ich dachte auch gerade warum jemand in einer Firewall Blacklisting statt Whitelisting machen sollte.
Meine Liste ist da bei ca. 100 MA sehr übersichtlich:
HTTP(S) an alle, DNS an DSL-Provider und Quad9, IMAP/SMTP an E-Mail-Provider, SIP/RTP an VoIP-Provider und NTP an [0-3].de.pool.ntp.org.
Und ja, natürlich habe ich dann noch ein paar Whitelisting-Einträge für eine Handvoll Benutzer und mich für FTP(S) und SSH.
Das sollte doch Best Practice sein, oder übersehe ich etwas?
EDIT: Ups, den Synology Hyper Backup Port zur jeweils anderen Synology (zwei Standorte) habe ich vergessen.