CVE-2023-23397 - Microsoft Outlook Elevation of Privilege Vulnerability

Vor einigen Tagen gab es noch die DOC/RTF-Lücke, dass Office Dokumente den Client kapern können und dann kommt im März 2023 schon die nächste Lücke die Outlook betrifft und mit einem CVE-Score 9.8/9.1 kritisch ist.

Diese Lücke ist der Startpunkt für die Ausnutzung als CVE-2024-21410 Betrachtung

Diese und andere Lücken werden durch das März 2023 Security Update gefixt.

Angeblich gibt es am 23. März noch eine Variante, die nicht durch das Security Update gefixt wurde.
https://twitter.com/domchell/status/1636742613121236992

Die Lücke

Der Angriffsvektor besteht darin, eine privilegierte Person über eine besondere Mail dazu zu bringen, einen vom Angreifer bereitgestellten Server per WebDAV/SMB anzusprechen und sich per NTLM anzumelden. Der Angreifer kann dann mit dem NTLM-Hash als "Pass the Hash" sich mit den Rechten des Anwender bei einem anderen Server, z.B. einem Domain Controller anmelden. Die Lücke in Outlook besteht u.a. darin, dass der Empfänger der Mail diese nicht einmal lesen muss, sondern Outlook einen an der Mail als Pfad hinterlegten "Warnton" abspielen will, wenn eine Frist abläuft.

Das entsprechende Feld ist in Exchange als "PidLidReminderFileParameter" bezeichnet.

Auch wenn dieser Angriff möglich ist, so ist er nicht ganz einfach umzusetzen, denn der Client muss die Datei per SMB von einem Server lesen, der schon unter Kontrolle des Angreifers steht und der Angreifer muss von dem Server aus dann die Zielserver erreichen können. Es ist eher unwahrscheinlich, dass der Angreifer im Internet einen Server so bereitstellen kann, wenn die Firmenfirewall den Zugriff auf Port 445/TCP nach extern blockiert und eingehende Verbindungen abgesichert hat. Aber sicher gibt es auch Firmen, wo dies nicht so ist und z.B. ein VPN-Server eine Authentifizierung per NTLM erlaubt.

Interessanter wird der Vektor für einen Innenangreifer, der noch mit wenigen Rechten einen Administrator so dazu verführen kann, seinen ebenfalls internen Server anzusprechen und zum dann einfach erreichbaren Domain-Controller zu gehen.MFA hilft aus meiner Sicht leider nicht, denn MFA greift bei der Vorauthentifizierung am Desktop oder DC aber nachdem der Client einmal angemeldet ist, wird kein MFA mehr gemacht.

Ich schätze das Risiko dieser Lücke mittlerweile als gering ein, denn es müssen zu viele Voraussetzungen passen und wenn eine Firma all diese erfüllt dann ist diese Lücke wohl mein kleinstes Problem. Mit dem Outlook Update ist das Problem auch nicht mehr existent.

Bislang konnte ich die Lücke bislang nur "intern" von Outlook über Exchange zu Outlook nachstellen konnte. Sobald Outlook die Mails per SMTP sendet oder per IMAP empfängt oder auch der Exchange Server die Mails per SMTP überträgt, wird aus der Termineinladung eine EML-Datei mit VCARD-Anlage ohne den Pfad zu einer Erinnerung. Der Angreifer muss wohl die Mail intern an interne Empfänger senden und einen erreichbaren SMB/WebDAV-Server mit MITM-Software betreiben, mit der dann ein unvorsichtiger privilegierter Nutzer seine Anmeldung durchführt und dann von diesem Server aus wieder ein internes System oder z.B. einen externen RDP/VPN/etc-Zugang mit NTLM-Anmeldung erreichen.

Es ist aber nicht unmöglich, wenn ein Angreifer bereits intern agieren kann, und sich damit mehr Rechte beschafft.

PoC Generatoren

Mittlerweile gib es öffentlich entsprechende Beispiele um den Exploit bei einem nicht gepatchten Outlook auszulösen.

Es gilt nun also keine Zeit zu verlieren, und die März 2023 Security Updates einzuspielen.

Patch

Microsoft hat die Lücke direkt im März 2023 Security Updates korrigiert. Wenn Sie ihre Systeme aktuell halten, dann sollten sie über diese Lücken nicht mehr angreifbar sein. Es gibt dazu zwei Updates:

  • Outlook März Security Update
    Diese Update soll die Lücke, die eigentlich nur in Outlook besteht, korrigieren. Allerdings gibt es Berichte, dass nicht alle Fälle damit abgedeckt sind und es eventuell noch ein weiteres Updates nachfolgt. Dennoch ist es wichtig, das Update zu installieren
  • Exchange Märt Security Update
    Microsoft hat aber auch für die Exchange Server im März CU einen entsprechenden Code eingebaut, damit Mails mit dem schädlichen Code nicht mehr über das Internet entsprechend konvertiert werden. Sobald Sie das Update installiert haben, sind sie damit gegen externe Angriffe geschützt.

Exchange Server (with March 2023 SU) and Exchange Online drop the PidLidReminderFileParameter message property at TNEF conversion when new message is received from outside of the organization.
Quelle: https://msrc.microsoft.com/blog/2023/03/microsoft-mitigates-outlook-elevation-of-privilege-vulnerability/#releases-for-microsoft-products

Weitere Gegenmaßnahmen

Microsoft hat sehr schnell Updates bereitgestellt, Dennoch können Sie generell mehrere Dinge tun, damit solche zukünftig schwerer ausnutzbar sind.

  • TCP 445/SMB blockieren
    Ich finde es erstaunlich, dass dieser "Fix" nicht sowieso der "Default" ist. Es gibt sicher ganz wenige Umgebungen, in denen ein Client aus dem internen LAN über diese Ports eine Verbindung zu einem nicht vertrauenswürdigen System im Internet aufbauen muss. SMB ist immer noch das primäre Protokoll im LAN aber sollte dies sicher nicht im Internet sein.
  • NTLM deaktivieren
    In einem LAN wird statt NTLM fast immer Kerberos genutzt. Sicher gibt es Alt-Systeme, die kein Kerberos unterstützen und wenn Sie über eine IP-Adresse statt einem DNS-Namen zugreifen, kommt normalerweise auch kein Kerberos zum Einsatz. Aber speziell sensible oder privilegierte Konten sollten sie schon immer die NTLM-Nutzung unterbinden. Dazu gibt es schon seit Windows 2012 R2 extra die Gruppe "Protected Users"

    Die Mitgliedschaft in der Gruppe unterbindet aber noch andere Dinge, z.B. Kerberos - Constraint Delegation, die vielleicht stören.
    Sie können aber über Windows Gruppenrichtlinien die Nutzung von NTLM unterbinden und eine Allow-Liste der Server pflegen, zu denen NTLM weiterhin erforderlich sein muss.
  • WebDav auf dem Client deaktivieren
    Auf Servern werden normalerweise nur Dienste installiert, die auch benötigt werden. Windows Server hat dies auch erst lernen müssen aber mittlerweile sind viele Komponenten einzelne "Features" die individuell installiert werden können. Auf vielen Clients sind aber immer noch viele Funktionen "dabei" um möglichst kompatibel zu sein. Dazu zählt WebDAV aber wenn Sie dies nicht benötigen, dann können sie es deaktivieren

Es gibt also mindestens drei Möglichkeiten, die Lücke bis zur Verfügbarkeit eines Patch zu blockieren. Auch wenn der CVE im Prinzip ein hohes Risiko-Rating hat, so müssen Administratoren schon viele Dinge übersehen haben. Insbesondere die Erreichbarkeit von wildfremden Servern im Internet über SMB-Port 445/TCP würde ich als kritisch ansehen. Zumindest eine Unternehmensfirewall sollte auch ausgehenden Verkehr entsprechend filtern.

Das ist aber noch kein Schutz für die vielen Mitarbeitern im Homeoffice, die dank "Split-VPN" besonders gut auch Cloud-Dienste nutzen können. Hier gibt es dann eher keine Firewall auf dem DSL-Router, die das Verhindern. Hier müssten Sie z.B. das "Public"-Netzwerk von Windows anpassen, dass hier ausgehende Verbindungen auf 445/TCP unterbunden sind. Per Default sind sie das nicht. Eventuell kann auch ihr VPN-Client solche Sperrungen vorgeben.

Postfach-Analyse

Wenn Sie einen Exchange Server zur Speicherung der Mails nutzen, dann können Sie als Administrator mit entsprechenden Berechtigungen auch alle Postfächer auf solche Mails durchsuchen. Dazu hat Microsoft mit den Exchange Sicherheitsupdates im März 2023 ein entsprechendes PowerShell-Skript veröffentlicht.

Die erste Version des Skripts verbindet sich per EWS mit den angegebenen Postfächern und prüft jede einzelne Mail. Da das entsprechende zu prüfende Feld nicht von Exchange indexiert wird, ist eine direkte Suche nicht möglich und entsprechend langsam läuft die Suche.

Mittlerweile gibt es eine aktualisiert Version die mit "Such Ordnern" arbeitet. Im ersten Durchlauf wird ein Suchordner mit dem Namen "ReminderFileParameterItems" angelegt, deren Inhalt der Exchange Server ermittelt. Im zweiten Durchlauf muss das Skript dann nur noch den Inhalt dieses Ordners untersuchen. Beide Vorgänge dauern 1-2 Sekunden pro Postfach und sind damit deutlich schneller. Nach der Analyse können Sie betroffene Elemente löschen oder heilen lassen und zum Abschluss den Suchordner wieder entfernen lassen. Microsoft beschreibt in der Anleitung alle erforderlichen Schritt, damit Sie sich die erforderlichen Berechtigungen zur Ausführung beschaffen.

# Suchordner On-Premises wieder entfernen
Get-Mailbox -resultsize unlimited `
| .\CVE-2023-23397.ps1 `
      -Environment "OnPrem" `
      -EWSServerUrl https://outlook.msxfaq.de/EWS/Exchange.asmx `
      -SearchFolderCleanup `
      -UseSearchFolders

Damit könnte da Skript schon beschrieben sein, aber wenn Sie sich etwas Zeit nehmen, dann sollten sie schon einmal hinschauen, wie man mit PowerShell Code schreiben kann. Microsoft hat in dem Skript einige Dinge umgesetzt, die sehr pfiffig sind. Zwei Dinge möchte ich hier erwähnen:

  • Überschreiben von Write-Host
    Wir kennen alle die Funktion mit "Write-Host" den Ablauf eines Skripts auf dem Bildschirm auszugeben. Kaum jemand nutzt aber Write-Verbose oder implementiert eigene Funktionen zur Protokollierung. Microsoft zeit in dem Skript, wie Sie eine eigene "Write-Host"-Funktion anlegen, die die Standardfunktion ersetzt, so dass Sie im Code weiter mit Write-Host arbeiten können aber ihre Funktion z.B.: alle Ausgaben auch noch in eine Protokolldatei schreibt
  • Application Permissions
    Das Script ha schon sehr viel Rechte und es ist kritisch zu sehen, wenn Sie ihrem Konto so viele Rechte einräumen. Für den Einsatz mit Exchange Online wird daher im AzureAD eine eigene Applikation mit den Berechtigungen angelegt.

    Damit sie nun aber die App-Credentials nicht im Code oder sonst wo hinterlegen, vergibt Microsoft ihrem Benutzer das "Owner"-Recht auf die Applikation. Wenn Sie nun das Skript starten, dann nutzt das Skript ihre Rechte, um bei der "App Registration" ein temporäres Kennwort anzulegen, welches maximal 7 Tage gilt.

    Das Kennwort hat dann nur das Skript im Hauptspeicher solange es läuft. Nachdem das Skript beendet wurde, ist das Kennwort nicht mehr erreichbar. Das Skript muss also immer von jemandem ausgeführt werden, der auch die Owner-Rechte auf die Application hat und im Skript sind keine Zugangsdaten enthalten. Es eignet sich so natürlich nicht für eine Ausführung als automatisiertes Skript.

Das Skript ist eine Fundgrube von Beispielcodes. Neben dem Umschreiben von "Write-Host" gibt Funktionen zum Prüfen des OAUTH-Token für EWS in der Cloud etc. Zudem merkt es sich den Zeitpunkt, wann z.B.: die Suchordner oder das App-Kennwort angelegt wurden und pausiert notfalls das Skript, um Exchange und AzureAD die erforderliche Zeit (ca. 60 Sek) zur Indexerstellen und Replikation zu geben. Viele mögliche Fehler wurden also schon vorab behandelt. Natürlich ist das Skript auch digital signiert und am Ende über 2000 Zeilen lang.

Weitere Links