[English]In Microsoft Outlook gibt es eine kritische Schwachstelle CVE-2023-23397, die eine Rechteauswertung durch Dritte ermöglicht. Diese Schwachstelle wird seit Mitte April 2022 durch russische Angreifer aktiv ausgenutzt. Benutzer und Administratoren sollten unverzüglich die Sicherheitsupdates für Outlook, die Microsoft bereitstellt, installieren. Im Rahmen einer Patchday-Nachlese fasse ich in diesem Beitrag einige Informationen zusammen.
Anzeige
Outlook-Schwachstelle CVE-2023-23397
Ich hatte bereits im Beitrag Microsoft Security Update Summary (14. März 2023) auf die als kritisch eingestufte Schwachstelle CVE-2023-23397 in Microsoft Outlook hingewiesen. Es handelt sich um eine Elevation of Privilege-Schwachstelle (EvP), die den CVEv3-Score von 9.8 erhalten hat, also extrem kritisch eingestuft wird.
Angreifer können eine bösartige E-Mail an eine anfällige Version von Outlook senden. Wenn die E-Mail vom Server geladen und im Client verarbeitet wird, kann eine Verbindung zu einem vom Angreifer kontrollierten Gerät hergestellt werden, um den Net-NTLMv2-Hash des E-Mail-Empfängers auszuspähen. Der Angreifer kann diesen Hash verwenden, um sich in einem NTLM-Relay-Angriff als Empfänger des Opfers zu authentifizieren, heißt es bei Microsoft.
Microsoft weist in seinen Dokumenten darauf hin, dass diese Schwachstelle ausgenutzt werden kann, bevor die E-Mail im Vorschaufenster angezeigt wird. Ein erfolgreicher Angriff erfordert also keine Interaktion des Empfängers.
Ich hatte bereits zum 9. März 2023 im Beitrag Kritische RTF-Schwachstelle CVE-2023-21716: Proof of Concept für Word; Outlook auch betroffen auf eine ähnliche RCE-Schwachstelle CVE-2023-21716 in Word hingewiesen, die auch Outlook betrifft. Hintergrund ist in diesem Fall die Unterstützung von RTF-Dateien in den genannten Anwendungen. Die aktuelle Schwachstelle ist zwar anders gelagert, zeigt aber, wie Anfällig Mail-Anwendungen wie Microsoft Outlook unter Windows sind.
Updates und Exchange Prüfscript vorhanden
Microsoft hat zum 14. März 2023 Sicherheitsupdates für Outlook 2016 (KB5002254) und für Outlook 2013 (KB5002265) dazu veröffentlicht (siehe Patchday: Microsoft Office Updates (14. März 2023)). Ältere, nicht mehr im Support befindliche Outlook-Versionen (z.B. Outlook 2010) sind damit nicht mehr patchbar und lassen sich angreifen.
Anzeige
Eine Liste aller Outlook-Updates vom 14. März 2023 findet sich unter CVE-2023-23397. Dort sind auch die Updates der Click-2-Run-Versionen für Outlook 2016, Outlook 2019 und Outlook 2021 sowie Microsoft 365 (Office 365) zu finden. Diese werden aber über Office/Outlook und nicht per Windows Update verteilt.
Das Exchange-Prüfscript von Microsoft
Microsoft hatte Exchange-Administratoren zum März 2023 Patchday auf die Schwachstelle hingewiesen und ein Prüfscript veröffentlicht (siehe den Blog-Beitrag Exchange Server Sicherheitsupdates (14. März 2023)). Das Prüftscript CVE-2023-23397.ps1 überprüft alle Exchange Messaging-Elemente (E-Mail, Kalender und Aufgaben), ob eine Eigenschaft mit einem UNC-Pfad gefüllt ist.
Falls erforderlich, können Administratoren dieses Skript verwenden, um die Eigenschaft für Elemente zu bereinigen, die bösartig sind, oder die Elemente sogar dauerhaft zu löschen. Es gibt zwei Modi für das Skript:
- Überprüfungsmodus: Das Skript liefert eine CSV-Datei mit Details zu den Objekten, bei denen die Eigenschaft ausgefüllt ist.
- Bereinigungsmodus: Das Skript bereinigt die erkannten Einträge, indem es entweder die Eigenschaft löscht oder den Eintrag löscht.
Details finden sich in diesem bereits verlinkten Beitrag. Beachtet aber die nachfolgenden Hinweise auf a) die 30 Tage max. Verweildauer gelöschter Nachrichten in Exchange und b) auf false positive Meldungen des Scripts.
Weitere Details und Schutz vor der Ausnutzung
Microsoft hat im Beitrag zu CVE-2023-23397 einige Details zur Ausnutzung dieser Schwachstelle erläutert. Laut diesem separaten Blog-Beitrag kann ein Angreifer eine Nachricht mit einer erweiterten MAPI-Eigenschaft mit einem UNC-Pfad zu einer SMB-Freigabe (TCP 445) auf einem von einem Bedrohungsakteur kontrollierten Server senden. Es ist keine Benutzerinteraktion erforderlich, um dann eine Rechteerweiterung (EoP) zu erlangen.
Die Verbindung zum entfernten SMB-Server sendet die NTLM-Aushandlungsnachricht des Benutzers. Diese kann der Angreifer dann zur Authentifizierung an andere Systeme weiterleiten. Auf Naked-Security werden in diesem Beitrag einige Details zu den LTLM2-Daten aufgedeckt.
Erforderlich ist, dass diese System die NTLM-Authentifizierung unterstützen.
Online-Dienste wie Microsoft 365 unterstützen die NTLM-Authentifizierung nicht und sind nicht anfällig für Angriffe durch diese Nachrichten. Das Gleiche gilt, sofern OWA (Outlook Web App) verwendet wird. Andere Versionen von Microsoft Outlook für Android, iOS und Mac sowie und andere Microsoft365-Dienste sind ebenfalls nicht betroffen.
In diesem MD-Blog-Beitrag finden sich noch einige weitere Details zur Schwachstelle. So wird die Eigenschaft PidLidReminderOverride missbraucht, um Outlook zu veranlassen, die bösartige UNC im idLidReminderFile-Parameter zu analysieren. Der Sicherheitsforscher hat die gewonnenen Erkenntnisse verwendet, um einen einfachen Exploit zu erstellen. Der Autor des Beitrag demonstriert in einem Video, wie der Exploit eine eingehende Anfrage an LDAP weiterleitet, um ein Shadow Credential zu erhalten.
Kunden können den WebClient-Dienst auf ihren Rechnern deaktivieren, oder den TCP/445-Datenverkehr blockieren, um die Ausnutzung der Schwachstelle zu verhindern. Das ist aber nur machbar, sofern keine WebDAV-Verbindungen verwendet werden müssen. Microsoft hat im Beitrag CVE-2023-23397 konkrete Vorschläge dazu gemacht.
Ergänzung: Gemäß obigem Tweet gibt es eine Yara-Regel, die den PidLidReminderFile-Parameter in einer msg Appointment-Datei identifiziert. Details finden sich auf GitHub.
Schwachstelle wird ausgenutzt
Die Entdeckung der Schwachstelle sowie deren Ausnutzung erfolgte durch das Computer Emergency Response Team der Ukraine (CERT-UA) und Microsoft. Microsoft hat am 14. März 2023 einen Blog-Beitrag über die Entdeckung dieser Sicherheitslücke veröffentlicht – ein russischer Bedrohungsakteur nutzt die Schwachstelle aus.
Obiger Tweet weist auf diesen Artikel der Kollegen von Bleeping Computer hin. Diese konnten Informationen aus einer Bedrohungsanalyse einsehen, die Kunden mit einem Abonnement von Microsoft 365 Defender, Microsoft Defender for Business oder Microsoft Defender for Endpoint Plan 2 bereitgestellt wurde.
Aus der Analyse geht hervor, das russische Hackergruppe Fancy Bear (auch als APT28, STRONTIUM, Sednit und Sofacy bekannt) präparierte Outlook-Nachrichten (und Aufgaben) verschickt hat, um die erwähnten NTLM-Hashes über die NTLM-Aushandlung zu stehlen. Die Angriffe mit Ausnutzung der Sicherheitslücke fanden um zwischen Mitte April und Dezember 2022 statt. Den Angreifern gelang es, in die Netzwerke von weniger als 15 Regierungs-, Militär-, Energie- und Transportunternehmen einzudringen. Anschließend wurden die gestohlenen Anmeldeinformationen wurden für laterale Bewegungen innerhalb der Netzwerke der Opfer und zum Ändern der Berechtigungen für Outlook-Postfachordner verwendet.
Ähnliche Artikel:
Microsoft Security Update Summary (14. März 2023)
Patchday: Windows 10-Updates (14. März 2023)
Patchday: Windows 11/Server 2022-Updates (14. März 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (14. März 2023)
Patchday: Microsoft Office Updates (14. März 2023)
Exchange Server Sicherheitsupdates (14. März 2023)
Anzeige
Hallo,
ein Update-Newbie hier.
für Office 2013 und 2016 gibt es ja die KBs. Wie funktioniert das Verteilen der Updates auf die anderen Office-Versionen an Clients die am WSUS hängen?
Danke
Die Office Clients holen sich die Updates standardmäßig direkt vom Microsoft Repository (CDN). Per GPOs oder Registry kannst du es aber auch anders einstellen.
Kleine Anmerkung.
Ich will das Problem nicht klein reden.
Wahrlich nicht, das ist xxx.
Aber "Privat" Anwender bzw alle die keine AD / LDAP anwenden sind, so wie Ich es gelesen habe, nicht bedingt davon betroffen.
Der Angriff ist in dem Sinne das man die Anmelde Daten "Shadowt".
Mit diesen Daten kann er sich natürlich immer am Mail System als dein Account ausgeben.
Aber nur wenn man eine AD/LDAP hat, und, was fast immer gemacht wird, der Account identisch ist, entfaltet es die volle Wirkung.
==> Der angreifer hat den Account.
Der ein AD Account ist.
Mit dem AD Account kann er dann dasselbe machen wie Du.
Und auch einen Pfad nach draußen öffnen.
In DEINEM Namen. / Im Namen deines Account.
Oder habe Ich das falsch verstanden?
Wie gesagt, das ist ein GAU.
Im Firmenumfeld.
Privatleute haben Probleme das Ihre Mails so bearbeitet/verwaltet werden können als wären es die eigenen.
Viel schlimmer – oder auch nicht?
Sie hat den Account – ok – Sie muss ihn aber auch nutzen können. Also entweder muss ein weiteres System von außen erreichbar sein, dass Hashes akzeptiert oder aber es muss bereits ein anderer Weg nach "drinnen" vorhanden sein, den man nun ausnutzen kann.
Also dieser Angriffsweg ist schon speziell.
Lächeln kann man über das "Prüfscript" ob etwas schädliches vorhanden ist. Also die Angriffe laufen seit gut einem Jahr. Die Default Haltezeit von Exchange für gelöschte Objekte ist 30 Tage. Also lässt sich gerade mal für die letzten 30 Tage nach schädlichem Inhalt suchen, wenn der z.B. als SPAM verpackt direkt gelöscht worden ist. Alles Schädliche was schon z.B. vor einem Jahr empfangen worden war und längst gelöscht ist, lässt sich gar nicht mehr feststellen. Damit ist das Script eigentlich nutzlos, weil es nur einen minimalen Zeitabschnitt überhaupt prüfen kann. Und es ist wohl zu vermuten, dass das Wissen über diese Lücke sogar noch älter als dieses eine Jahr ist. Vielleicht ist der Weg schon seit 10 Jahren bekannt. Die Russen haben diesen Angriffsweg wegen des Kriegs nun benutzt und damit "verbrannt". Wo sie damit aber vorher schon alles zu Besuch waren ist völlig unbekannt.
Danke Microsoft für die ganze Automatismen ohne die die Welt schon längst untergegangen wäre – oh wait….
Mal übrigens: Das Problem ist Outlook und nicht Exchange. Es wird aber immer in Kombination benutzt, was in 95% aller Fälle auch zutreffend sein dürfte. Das Script für Exchange nutzt nur für Exchange-Umgebungen zum Test.
Wer aber z.B. Outlook in Kombination mit einem anderen Mailserver verwendet, dürfte trotzdem betroffen sein. Denn die NTLM Hashes werden ja vom Outlook Client abgegriffen – wenn der Client diese liefert ist der Sack trotzdem zu. Hat also mit Exchange nichts zu tun. Wie Admins anderer Mail-Systeme zentral nach potentiell schädlichen Inhalten suchen ist also deren eigenes Problem…
Dachte eigentlich, dass dieser Kontext für Admins in Firmenumgebungen klar sein sollte – oder liege ich da falsch?
Na ja – gibt noch mehr Diskussionsseiten im Internet und da scheint das nicht immer und überall so klar zu sein. Auch dass das Exchange-Script nur eine trügerische Sicherheit bietet wenn es nichts findet, scheint auch nicht so klar zu sein. Dieses Outlook Ding ist ein verdammt dickes Brett. Letztlich müsste man jegliche Outlook-Installation als bereits kompromittiert betrachten.
Sind natürlich Argumente – aber hier im Blog ist es ja jetzt durch deinen Kommentar klar – und im englischsprachigen Blog habe ich nochmals explizit auf den Sachverhalt zum Script hingewiesen.
Im Artikel wird nur ein Sicherheitsupdate für Outlook 2016 (KB5002254) verlinkt.
Für Outlook 2019 und 2021 scheint es noch keinen Patch zu geben?
Auch hier
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397
sind die beiden Versionen (Microsoft Office 2019 for 64-bit editions und
Microsoft Office LTSC 2021 for 64-bit editions) "grau" – also kein Download hinterlegt.
Ich hab für die neueren Outlooks also weder was passendes im WSUS noch einen manuellen Patchdownload gefunden.
Suche ich schlecht oder kommen die Patches erst noch raus?
Outlook 2019 und 2021 werden als C2R-Anwendungen separat gepatcht – ich habe nur die per WU ausgerollten Patches adressiert. Beachte aber meinen Nachtrag, im verlinkten CVE-2023-23397-Artikel von Microsoft finden sich auch die C2R-Updates. Die müssten in der Office C2R-Umgebung eigentlich gefunden und installiert werden.
> Beachte aber meinen Nachtrag, im verlinkten CVE-2023-23397-Artikel von Microsoft finden sich auch die C2R-Updates.
Den Artikel habe ich in meinem Comment ja auch noch mal verlinkt :-) daher bekannt.
Ich möchte die Updates jedoch gern selbst im WSUS anbieten, also entweder von MS (idealerweise automatisch) bekommen oder manuell integrieren. Damit ich zumindest direkt sehen kann, welche Büchsen das Update denn überhaupt noch brauchen.
Was ich nicht bedacht habe, ist, daß bei den neueren Office-Versionen (vulgo auch Outlook), dies (WSUS) ja durch das C2R-Prinzip ja grundsätzlich gar nicht mehr geht.
Office ist halt nicht mein Steckenpferd und läuft so nebenher mit.
Wie geht man nun vor, wenn man wissen möchte ob die Kollegen die schon eine neuere Office-Version haben, nun gepatcht sind oder nicht? Manche finden den UpdateButton ja selbstständig, manche nicht …
(da es ein eher kleines Netzwerk ist, gibts außer WSUS keine zusätzliche Updateverwaltungs-Software, aber zu viele Rechner um alle manuell abzulaufen :-/ )
Ist sicher nur ein Behelf, aber wenn es kein Patch-Mangement oder MEMC gibt, dann würde ich es mit einem Skript versuchen. Geplante Aufgabe per GPO anlegen und alle Rechner die aktuell installierte Version von Office in eine Datei schreiben lassen, welche das Skript in einem freigegeben Netzwerk-Ordner ablegt.
Den Dateinamen über den hostname steuern, so ist das Ergebnis dann dem PC zugeordnet.
Die Dateien kann man dann schnell durchsehen, wenn es nicht so viele Rechner sind.
Hast du kein Login- oder Startup-Skript, in dem du die Outlook-Version auslesen kannst?
Nach der Ausführung des Audit-Scripts finde ich in der Results-Datei über 1000 Einträge -meist vom Typ "Task"- bis zurück nach 2014. Wie gehe ich nun damit um?
Ganz Einfach: Wenn ihr ein High Value Target seit – ernst nehmen und ein Emergency Response Team anfordern.
Wenn ihr eine fünf Mann Bude seit, die Konfetti herstellt – ignorieren und weitermachen…
Falls jemand nicht weiß wo man ein IT Notfall Team findet, beim BSI hat es Infos:
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/Vorfallunterstuetzung/MIRT/mirt_node.html
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/CERT-Bund/Links/links_node.html
https://www.trusted-introducer.org/
OK, die Frage war doof formuliert.
Was ich meinte war eigentlich:
Wie ist die Ausgabe des Audit-Scripts zu interpretieren?
Ich habe eine ganze Reihe an Einträgen in der Results Datei, das "PidLidReminderFileParameter" Feld ist aber überall leer.
Ich gehe davon aus, dass das ein gutes Zeichen ist?
Siehe dazu das Issue "False positives":
https://github.com/microsoft/CSS-Exchange/issues/1585
Wir haben auch ne Menge davon gefunden und waren erstmal irritiert, scheinen aber alles false positives zu sein, meist Aufgabenelemente (TASK), die z.B. aus OneNote heraus generiert wurden oder ohne verlinktes Mail-Element
EDIT: Orth war schneller mit dem Hinweis auf die Issues
https://github.com/microsoft/CSS-Exchange/issues/1585
hier gibt die w die passende antwort
ehm sorry ich patche outlook und gut. wozu aber soll ich auf dem exchange server dann noch ein script laufen lassen, dass ggf. mails oder schädliche parameter aus mails rauslöscht.
oder sollt man meinen, der outlook fix funktioniert vielleicht doch nicht so wie er soll?
Nicht dein Ernst, oder?
Man prüft, ob man betroffen ist und wenn ja – dann installiert man "mal eben schnell" die Systeme neu. ;-)
doch mein ernst. oder dürfen bei euch wirklich clients per unc überall hin kommunizieren? nach dem outgoing unc bei uns gesperrt ist, der patch überall verteilt ist, sehe ich keine notwendigkeit für dieses script. wir haben es laufen lassen und erwartungsgemäß exakt nichts gefunden.
Sehr geehrte Mitlesende,
haben Sie das Skript schon ausgeführt und teilen die Befürchtung das hier viele False Positive Ergebnisse geliefert werden?
Auf Github gibt es auch schon eine solche Anfrage: https://github.com/microsoft/CSS-Exchange/issues/1585
Bis auf 8 Einzelmails verteilen sich die 108 Ergebnisse auf 2 Mitarbeiter.
Die 78 E-Mails der einen Mitarbeiterin sind höchst wahrscheinlich nur hausintern und die 22 anderen E-Mails sind garantiert hausintern mit selbst eingescannten Dokumenten.
Ohne weitere Prüfung des Skripts etc. sieht das für mich bisher nicht sehr vertrauenswürdig aus.
Die ältesten E-Mails sind von 2007.
Mit freundlichen Grüßen
Orth
Sehr geehrte Mitlesende,
beim ersten überfliegen der "CVE-2023-23397 script" Seite von Microsoft dachte ich das Anhänge entfernt werden. Die Option ClearProperty entfernt nur das PidLidReminderFileParameter property. Das dürfte keine merklichen Änderungen beim Anwender verursachen oder übersehe ich etwas?
Mit freundlichen Grüßen
Orth
Ist das Problem durch das reguläre Office-Update welches via Windows-Update oder über "Datei > Konto" bezogen wird auf Clientseite gelöst?
Es wäre interessant zu wissen, ab welcher Versionsnummer bzw. ab welchem Build Outlook den erforderlichen Patch beinhaltet.
Kurze Frage, welche Voraussetzungen müssen auf dem Exchange gegeben sein, um mit den besagten, gestohlenen NTLM Hash auf eine "klassische" Exchange / EWS / OWA Schnittstelle zuzugreifen, sind diese überhaupt gefährdet?
Die Sicherheitslücke hat nichts mit Exchange zu tun. Outlook ist das Problem, es versucht durch eine entsprechend präparierten Email sich per NTLM an einem anderen Server, der in der Email kodiert ist, anzumelden. Der Zielserver kann irgendwas sein, was SMB/CIFS anbietet, oder etwas was sich so verhält. Es geht ja nur darum, auf dem Zielserver den NTLM-Hash des Outlook-Benutzers abzugreifen. Dazu muss der Angreifer den Zielserver unter Kontrolle haben, um z.B. per Mimikatz den Hash abzugreifen. Wer sein Netzwerk so abgesichert hat, dass SMB/CIFS am Internetgateway nach Draußen gesperrt ist, ist schonmal ziemlich fein raus. Aber der Angriff wurde ja bisher vor allem von staatlichen Stellen (Russland) für ausgewählte (ukrainische) Ziele benutzt, ich schätze mal, wenn die es drauf anlegen, stecken die auch einen RaspberryPi in den Kabelkanal des Opfernetzwerkes, oder haben sich schon irgendwie anders auf anderem Weg Zugang zu einem internen Server verschafft… Gut, Ok, wenn sie schon im internen Netz sind, haben sie noch ganz andere Möglichkeiten, aber mit so einer Mailbombe kann man sich ganz gezielt bestimmte Benutzer herauspicken und muss nicht warten, bis sie von selbst am gekaperten Server vorbei kommen.
Das Problem ist in Outlook. Was mir aber noch nicht klar ist: braucht es auch Exchange, um das ausnutzen zu können? Es geht hier ja um eine "erweiterte MAPI-Eigenschaft", wohl von Besprechungstermin-Elementen. Kann diese PidLidReminderOverride-Eigenschaft Outlook auch über einen "normalen" Mailserver (SMTP/IMAP) erreichen?
Was wohl möglich ist: eine MSG-Datei erzeugen, die das beinhaltet. Die könnte man als Attachment versenden, müsste dann aber wohl vom Opfer von Hand geöffnet werden.
Hier gibt's Erkenntnisse dazu:
https://twitter.com/wdormann/status/1636497737528102912?t=uz9Oti0S7WDnCp94jKFFYA&s=19
Es sieht wohl so aus, dass die Lücke nur ausgenutzt werden kann, wenn Outlook an einem Exchange hängt, nicht aber bei IMAP.
Die Schadmail kann aber wohl mit einem TNEF-Attachment durchaus per SMTP an den Exchange-Server geschickt werden.
Antwort auf 1ST1:
Das ist klar, die Frage ist, was kann ein Angreifer mit einem erbeutetem Hash tun? was sind die Ziele?
Wenn der Angreifer sich bereits innerhalb des Netzwerkes/VPN befindet, kann er mit dem Hash sich gegenüber Windows Server Authentifizieren um an Daten zu gelangen. Welche weiteren Dienste arbeiten mit dieser Authentifizierung? Und vor allem sind (leider noch bei manchen Kunden) öffentlich zugängliche Exchangeserver Outlook Anywhere, etc. mögliche Ziele, d.h. der Angreifer kann die Konten ausspähen?
ich habe eine dumme Frage, sorry! Wenn die Outlooks, ich verwende Office 2016, gepatch sind, sind sie doch geschützt ? dann muss ich Port 445 nicht mehr nach außen schließen oder? grundsätzlich sollte man dieses überlegen ja, aber ich meine damit, dass das patchen theoretisch reichen sollte ?
Für diese spezielle Lücke dichtet der Patch das Problem ab, trotzdem sollte eine Unternehmensfirewall im Default nach außen erstmal gar nichts zulassen. Direkte Freigaben sollten explizit und soweit eingegrenzt wie möglich eingerichtet werden. Braucht der Client Internet für den Webbrowser, dann über einen Proxy, welche erweitere Möglichkeiten bietet Zielports und Zieladressen zu prüfen und ggf. zu blocken.
Auch mit Patch bleibt das Problem: Woher will man wissen, dass die Lücke in der Vergangenheit nicht schon ausgenutzt wurde? Die Prüfung per Skript bleibt für mich 'Schlangenöl', da es 1.000 Gründe gibt, warum eine Nachricht mit dem Exploit nicht mehr gefunden werden kann. Konsequenterweise müsste man also bei ALLEN Anwendern mit Outlook die Passwörter zurücksetzen, da die Konten kompromittiert sein könnten.
Das war dann doch nix… https://twitter.com/domchell/status/1636742613121236992
also doch lieber Port 445 zusätzlich von innen nach blocken!
habe nun Port 445 von innen nach außen geblockt!