Ton stummschalten: Verkettung von Schwachstellen für RCE in Outlook – Teil 1
Zusammenfassung
Ben Barnea, Forscher bei Akamai, fand zwei Schwachstellen in Microsoft Windows, die die Kennungen CVE-2023-35384 und CVE-2023-36710erhalten haben.
Ein Angreifer im Internet kann die Schwachstellen miteinander verknüpfen und so einen vollständigen Exploit zur Remote-Code-Ausführung (RCE) für Outlook-Clients schaffen, bei dem keinerlei Interaktion mit dem Nutzer nötig ist (Null-Klick).
Die erste Schwachstelle stellt das Parsen eines Pfads durch die Funktion MapUrlToZone dar. Um diese Sicherheitslücke auszunutzen, muss eine E-Mail an einen Outlook-Client gesendet werden. Diese wird dann eine spezielle Audiodatei von einem angreifergesteuerten Server herunterladen.
Die zweite Schwachstelle findet sich im Audio Compression Manager (ACM). Diese Sicherheitslücke wird ausgenutzt, wenn die heruntergeladene Audiodatei automatisch wiedergegeben wird, Sie kann zur Ausführung von Code auf dem anvisierten Computer führen. Diese Schwachstelle wird ausführlich in Teil 2 dieses Blogbeitrags beschrieben.
Die Schwachstellen wurden verantwortungsvoll an Microsoft weitergegeben und an den Patch Tuesdays im August 2023 und Oktober 2023 behoben.
Auf Windows-Computern, bei denen das Softwareupdate vom Oktober 2023 installiert wurde, sind diese Sicherheitslücken geschlossen. Darüber hinaus sind Outlook-Clients, die Microsoft-Exchange-Server verwenden, die mit dem Softwareupdate vom März 2023 gepatcht wurden, gegen diesen Exploit geschützt.
Übersicht
Zu den Sicherheitslücken, die im Rahmen des Patch Tuesday im März 2023 behoben wurden, gehört eine kritische Outlook-Sicherheitslücke mit der Kennung CVE-2023-23397, die im freien Internet von Forest Blizzard ausgenutzt wurde. Diese Gruppe wurde von Microsoft als russische Bedrohungsakteure mit staatlicher Unterstützung identifiziert. Im Dezember 2023 veröffentlichte Microsoft zusammen mit der polnischen Cyberabwehr (DKWOC) eine Mitteilung, dass sie kürzlich Exploit-Versuche der Schwachstelle durch denselben Bedrohungsakteur registriert haben. Über diese Schwachstelle können Angreifer einen Outlook-Client zwingen, eine Verbindung zum Server des Angreifers herzustellen. Im Rahmen dieser Verbindung sendet der Client seine NTLM-Anmeldedaten an den Angreifer, der sie dann offline knacken oder für einen Relay-Angriff verwenden kann. Ein Angriff auf diese Schwachstellen könnte per Remotezugriff über das Internet erfolgen, ohne dass eine Interaktion mit dem Nutzer erforderlich ist (Null-Klick).
Nachdem der Patch für diese Schwachstelle veröffentlicht wurde, haben wir eine Umgehung gefunden –wie in einem vorherigen Blogbeitragerläutert und demonstriert. Diese Umgehung wurde am Patch Tuesday im Mai 2023 behoben. In dieser Veröffentlichung haben wir empfohlen, dass Microsoft das ausgenutzte Feature entfernt, da es eine riesige und komplexe Angriffsfläche bietet. Da die Funktion in Outlook weiterhin verfügbar ist, haben wir beschlossen, sie weiter zu untersuchen.
Schließlich konnten wir in Outlook eine Schwachstellenverkettung erreichen, die zu einer vollständigen RCE führte. Wir haben eine weitere Umgehung der ursprünglichen Outlook-Schwachstelle gefunden. Diese Umgehung ermöglichte es uns wieder, den Client zu zwingen, eine Verbindung zu einem angreifergesteuerten Server herzustellen und eine schädliche Audiodatei herunterzuladen. Dann konnten wir eine Schwachstelle in der Parsing-Bibliothek von Windows Media finden, die zur Verarbeitung und Wiedergabe von Audiodateien im Allgemeinen und insbesondere von Outlook-Benachrichtigungen verwendet wird. Ein Angreifer, der diese Schwachstellen zusammenführt, kann auf anfälligen Outlook-Clients RCE erreichen, ohne dass dazu eine Interaktion mit dem Nutzer nötig ist.
In dieser zweiteiligen Blogbeitragsreihe werden die Forschungsergebnisse vorgestellt, die wir zur Ermittlung der beiden Schwachstellen durchgeführt haben. Dieser erste Teil konzentriert sich auf die vorherige Umgehung und eine neue. In Teil 2 beschreiben wir die Schwachstelle beim Medien-Parser, die wir gefunden haben.
Die ursprüngliche Schwachstelle
Die im März behobene Sicherheitslücke in Outlook wird ausgelöst, wenn ein Angreifer eine E-Mail mit einer Erinnerung und einem individuellen Benachrichtigungston sendet. Dieser individuelle Ton wird vom Angreifer als Pfad festgelegt. Dazu nutzt er die MAPI-Eigenschaft PidLidReminderFileParameter. Ein Angreifer kann einen UNC-Pfad festlegen, der dazu führt, dass der Client die Audiodatei von einem beliebigen SMB-Server abruft. Als Teil der Verbindung zu diesem Remote-SMB-Server wird der Net-NTLMv2-Hash in einer Aushandlungsnachricht gesendet (Abbildung 1).
Abb. 1: Erzwingen der NTLM-Zugangsdaten
Zur Behebung des Problems ruft der Code jetzt MapUrlToZone auf, um den Pfad als Intranet, lokal oder Internet zu klassifizieren. Wenn die URL auf eine Ressource im Internet verweist, wird der standardmäßige Erinnerungston anstelle des nutzerdefinierten Tons verwendet.
Suche nach einer Umgehung
Nachdem die Abwehrmaßnahmen eingeführt wurden, fragten wir uns, ob es möglich war, diese zu umgehen.
In diesem Zusammenhang bedeutet eine Umgehung einen Pfad, der den Lokalitätstest bestanden hat und von Outlook zum Herunterladen der Audiodatei von einem entfernten Standort verwendet wird. Mit anderen Worten: Wir müssen einen Pfad finden, der MapUrlToZone nicht als Internet-Domain behandelt, aber CreateFile schon.
Um eine solche Umgehung zu finden, mussten wir die inneren Funktionen und die Vorgänge, die beim Parsen des Pfades durchgeführt wurden, vollständig verstehen.
Windows-Pfade und URLs
Es gibt viele verschiedene Varianten von DOS-Pfaden in Windows, zu denen und zu deren Umwandlung in NT-Pfade viel geforscht wurde. Wir werden die verschiedenen Windows-Pfadtypen an dieser Stelle nicht abhandeln. James Forshaws Blogbeitrag widmet sich diesem Thema in aller Ausführlichkeit.
Kehren wir zurück zu den Funktionen, die für uns von Interesse sind. CreateFile empfängt einen Windows-Pfad; MapUrlToZone (wie im Namen angedeutet) kann entweder eine URL oder ein Pfad weitergeleitet werden. Um eine Umgehung zu finden, müssen wir zunächst wissen, welche Pfadtypen von jeder Funktion (oder beiden) unterstützt werden.
Hinweis: CreateFile und MapUrlToZone verarbeiten die Pfade nicht selbst, sondern verwenden zu diesem Zweck andere WinAPI-Funktionen. Um der Kürze willen, verwenden wir CreateFile und MapUrlToZone, um auf die zugrunde liegenden Pfad-Parsing-Funktionen zu verweisen.
CreateFile |
MapUrlToZone |
|
|---|---|---|
RtlPathTypeUncAbsolute |
✔ |
✔ |
RtlPathTypeDriveAbsolute |
✔ |
✔ |
RtlPathTypeDriveRelative |
✔ |
✔ |
RtlPathTypeRooted |
✔ |
✘ |
RtlPathTypeRelative |
✔ |
✘ |
RtlPathTypeLocalDevice |
✔ |
✔ |
RtlPathTypeRootLocalDevice |
✔ |
✘ |
Schemas (file://, http://) |
✘ |
✔ |
Tabelle 1: Vergleichstabelle von CreateFile- und MapUrlToZone- Pfadfunktionen
Wie aus Tabelle 1 ersichtlich, werden nur vier Pfadtypen von beiden Funktionen unterstützt: RtlPathTypeUncAbsolute, RtlPathTypeDriveAbsolute, RtlPathTypeDriveRelative und RtlPathTypeLocalDevice.
Erster Versuch
Der erste Versuch, eine Umgehung zu finden, geschah mit einem absoluten UNC-Pfad (RtlPathTypeUncAbsolute). Abbildung 2 zeigt die Struktur des Pfads.
Abb. 2: Ein absoluter UNC-Pfad und seine Komponenten
Woher weiß Windows, wo die Pfadkomponente beginnt? Tabelle 2 zeigt den entsprechenden Code (RtlGetFullPathName_Ustr).
case RtlPathTypeUncAbsolute:
SeperatorsFound = 0;
for ( CurrentIndex = 2; CurrentIndex < InputPathLength; ++CurrentIndex )
{
CurrentChar = InputPathString->Buffer[CurrentIndex];
if ( CurrentChar == '\\' || CurrentChar == '/' )
{
SeperatorsFound++;
if ( SeperatorsFound == 2 )
break;
}
}
Tabelle 2: RtlGetFullPathName_Ustr- Code-Snippet, das den UNC-Pfad verarbeitet
Der Code überspringt das absolute UNC-Präfix („\\“) und geht dann davon aus, dass die Pfadkomponente ein Zeichen nach dem zweiten Pfadtrennzeichen („\“ oder „/“) beginnt.
Was passiert jedoch, wenn wir einen Pfad wie „\\\\localhost\..\Akamai.com\dir\file.txt” angeben?
Der Pfad wird wie folgt verarbeitet:
„\\\\“ wird als UNC-Präfix und als Root-Pfadkomponente interpretiert.
Die Pfadkomponente ist „localhost\..\Akamai.com\dir\file.txt”
Normalerweise würde keine Anzahl von „..“ über den Root-Pfad hinausgehen. Beispiel: „\\localhost\directory\..\file.txt“ würde zu „\\localhost\directory\file.txt“ führen. Da in unserem Beispiel jedoch „..“ nicht Teil des Root-Pfads ist, wird der Pfad in „\\\Akamai.com\dir\file.txt” konvertiert.
Wir haben also eine Möglichkeit gefunden, den Pfad zu manipulieren, indem wir Teile davon ausgelassen haben.
So verarbeitet CreateFile diesen Pfad; doch wie geht MapUrlToZone damit um (Tabelle 3)? Zunächst werden die zusätzlichen umgekehrten Schrägstriche entfernt. Der Pfad wird daher anders interpretiert:
\\localhost ist der Servername
\..\ wird ignoriert (da wir nicht über den Servernamen hinausgehen können)
Akamai.com\dir\file.txt umfasst die Pfadkomponente
Eingabepfad: \\\\localhost\..\Akamai.com\dir\file.txt |
|
|---|---|
CreateFile |
MapUrlToZone |
\\\Akamai.com\dir\file.txt |
\\localhost\Akamai.com\dir\file.txt |
Tabelle 3: Eingabepfade für CreateFile und MapUrlToZone und das Ergebnis beim Parsen von
MapUrlToZone gibt 0 (lokal) für den oben genannten Ausgabepfad zurück.
Obwohl wir scheinbar eine Umgehung gefunden haben, kann der Pfad leider nicht verwendet werden, um einen UNC-Anfrage auszulösen. Beachten Sie den zusätzlichen Schrägstrich am Anfang des Pfads, der von CreateFile verarbeitet wird: Dadurch wird der Servername als leer markiert. Wenn der Multiple UNC Provider (MUP) die verschiedenen Netzwerkanbieter anfragt, ob sie diesen (leeren) Servernamen verarbeiten können, geben alle eine Fehlermeldung zurück – daher wird keine Anfrage gestellt.
Für das Ausnutzen des Unterschieds, wie MapUrlToZone und CreateFile diesen Pfad handhaben, ist möglicherweise eine kompliziertere Lösung erforderlich – z. B. die Suche nach einer Möglichkeit, den zusätzlichen umgekehrten Schrägstrich auszulassen, oder die Suche nach einer Parsing-Diskrepanz im MAP-Code. Dies könnte man in Zukunft genauer untersuchen.
Zweiter Versuch: Umgehung Nr. 1 (CVE-2023-29324)
Da das Herumspielen mit absoluten UNC-Pfaden nicht wirklich funktioniert hat, haben wir mit dem nächsten Pfadtyp weitergearbeitet, der UNC unterstützt: RtlPathTypeLocalDevice. „\\.\UNC\Akamai.com\test.wav” ist ein Beispiel für einen lokalen Gerätepfad. Insbesondere verweist er auf den UNC-Gerätenamen, der an den MUP-Treiber umgeleitet wird.
Um eine Umgehung zu finden, müssen wir uns die verschiedenen Vorgänge ansehen, die im Rahmen der Analyse der Pfade durchgeführt werden. Tabelle 4 verdeutlicht diesen Unterschied.
CreateFile |
MapUrlToZone |
|---|---|
Wenn RtlPathTypeLocalDevice → 4 Zeichen weiterrücken |
Wenn RtlPathTypeLocalDevice → 4 Zeichen weiterrücken |
Nachgestellte Leerzeichen überspringen |
|
„/“ in „\“ konvertieren |
|
Wiederholte „\“ ausblenden |
|
Komponenten wie „.“ und „..“ entfernen |
Komponenten wie „.“ und „..“ entfernen |
Tabelle 4: Verschiedene Vorgänge, die im Rahmen des Pfadparsings abgeschlossen wurden
Wir sehen, dass CreateFile zusätzliche Vorgänge durchführt, wie das Konvertieren von Schrägstrichen in umgekehrte Schrägstriche und das Ausblenden wiederholter Schrägstriche.
Sehen wir uns nun einen Pfad an, der einen dieser Unterschiede nutzt, indem wir ein zusätzliches Pfadtrennzeichen verwenden. Tabelle 5 zeigt die Pfade, nachdem der Code das Präfix „UNC\“ überspringt.
Eingabepfad: \\.\UNC\\Akamai.com\test.wav |
|
|---|---|
CreateFile |
MapUrlToZone |
Akamai.com\test.wav |
\Akamai.com\test.wav |
Tabelle 5: Pfade nach Überspringen des Präfix „UNC/“
Beachten Sie den Pfad in der rechten Spalte. Einen Pfad, der mit einem Pfadtrennzeichen beginnt, gefolgt von einem Zeichen, das kein Pfadtrennzeichen ist, wird als Root-Pfad bezeichnet. MapUrlToZone verwendet die Funktionen IsRootedPath oder IsDrivePath, um zu bestimmen, ob die Root-Pfadkomponente lokal ist. In unserem Fall ist der Pfad gerootet und damit ist die Ausgabe von MapUrlToZone lokal.
CreateFile verfügt nicht über das zusätzliche Pfadtrennzeichen nach dem UNC-Präfix, sodass der Domainname korrekt extrahiert werden muss. Der Befehl greift jetzt auf den SMB-Server Akamai.com zu, um die Datei test.wav abzurufen. Wir haben einen Pfad gefunden, der MapUrlToZone als lokal ansieht, aber CreateFile tut das nicht. Diese Umgehung hat die Ausnutzung der Outlook-Schwachstelle CVE-2023-23397wieder ermöglicht.
Um dieses Problem zu beheben, versuchte Microsoft, die beiden Flüsse ähnlicher zu gestalten. Die Vorgänge zum Konvertieren von Schrägstrichen in umgekehrte Schrägstriche und zum Ausblenden wiederholter Pfadtrennzeichen wurden nun dem Pfad-Parsingfluss von MapUrlToZone hinzugefügt.
Was wäre, wenn ...
Im vorherigen Abschnitt haben wir festgestellt, dass MapUrlToZone prüft, ob die Pfadkomponente nach „\\.\UNC\“ ein Laufwerk oder ein Root-Pfad ist. Diese Pfadkomponente kann nach der Korrektur nicht zu einem Root-Pfad werden, da wiederholte Pfadtrennzeichen ausgeblendet werden. Es kann jedoch immer noch ein Laufwerkpfad angegeben werden, z. B. „\\.\UNC\C:Akamai.com/test.wav”.
Das führt tatsächlich dazu, dass MapUrlToZone 0 ausgibt. Leider ist kein Netzbetreiber in der Lage einen Pfad mit Doppelpunkt zu handhaben, daher hilft uns diese Verwirrung nicht weiter. Wie bei unserem ersten (gescheiterten) Versuch kann das Auffinden einer Verwirrung mit MUP-Parsing-Code zu einer neuen Schwachstelle führen.
Dritter Versuch: Umgehung Nr. 2 (CVE-2023-35384)
Nach der Fehlerbehebung sind die von den beiden Funktionen ausgeführten Vorgänge nahezu identisch (Tabelle 6).
CreateFile |
MapUrlToZone |
|---|---|
Wenn RtlPathTypeLocalDevice → 4 Zeichen weiterrücken |
Wenn RtlPathTypeLocalDevice → 4 Zeichen weiterrücken |
Nachgestellte Leerzeichen überspringen |
|
„/“ in „\“ konvertieren |
„/“ in „\“ konvertieren |
Wiederholte „\“ ausblenden |
Wiederholte „\“ ausblenden |
Komponenten wie „.“ und „..“ entfernen |
Komponenten wie „.“ und „..“ entfernen |
Tabelle 6: Durchgeführte Vorgänge vom Postfix von CreateFile und MapUrlToZone .
Wenn wir uns das jedoch genauer ansehen, müssen wir uns fragen: Wie entscheidet jede Funktion, dass der Pfad ein lokaler Gerätepfad ist? Tabelle 7 zeigt Code-Snippets von jeder Funktion, die bei der Bestimmung des Pfadtyps helfen.
CreateFile
if (IS_PATH_SEPARATOR(Path[0]) &&
IS_PATH_SEPARATOR(Path[1]) &&
(Path[2] == '.' || Path[2] == '?') &&
IS_PATH_SEPERATOR(Path[3])
return RtlPathTypeLocalDevice;
MapUrlToZone
!strncmp(path, "\\.\", 4) || !strncmp(path, "\\?\", 4)
Tabelle 7: Code-Snippets, die den Pfadtyp bestimmen
Mit CreateFile kann ein Pfadtrennzeichen entweder ein Schrägstrich oder ein umgekehrter Schrägstrich sein. Beispiel: „\\./“ wird als lokaler Gerätepfad betrachtet. Mit MapUrlToZone gelten nur die genauen „\\.\“- oder „\\?\“-Pfade gelten als lokale Gerätepfade. Dies ist eine Verwirrung beim Pfadtyp – so erreichen wir, dass CreateFile die Komponente „\\./“ als lokalen Gerätepfad erkennt und MapUrlToZone nicht. Diese Verwirrung führt zu einer unterschiedlichen Handhabung des Pfades durch die beiden Funktionen.
Vor diesem Hintergrund wollen wir einen Pfad verwenden, der die „verwirrende“ Komponente enthält: \\./UNC/Akamai.com/file.wav.
In Bezug auf die Entscheidungsfindung für den Pfadtyp sieht der Fluss für MapUrlToZonefolgendermaßen aus:
Ist der Pfad ein lokales Laufwerk oder ein Root-Pfad? Nein
IsLocalDeviceUNC? Nein
PathIsUNCW? Ja
PathIsUNCW gibt TRUE aus. Die Funktion markiert ihn als absoluten UNC-Pfad und rückt zwei Zeichen weiter, um das UNC-Präfix „\\“ zu überspringen. Die Ausgabe für jede Funktion ist in Tabelle 8 dargestellt.
Eingabepfad: \\./UNC/Akamai.com/file.wav |
|
|---|---|
CreateFile |
MapUrlToZone |
UNC\Akamai.com\file.wav |
./UNC/Akamai.com/file.wav |
Tabelle 8: Pfad-Ausgaben für CreateFile- und MapUrlToZone- Funktionen
An dieser Stelle stellt CreateFile fest, dass die Ausgabe ein UNC-Pfad und Akamai.com der Hostname ist.
Umgekehrt kommt MapUrlToZone zu folgenden Schlüssen:
Schema: file://
Host: handelt. (Punkt)
Pfad: /UNC/Akamai.com/file.wav
Absoluter URI: file://./UNC/Akamai.com/file.wav
Wenn der absolute URI mit „file://./“ beginnt (und der Host „.“ ist), interpretiert der Code den Freigabenamen als Teil des DOS-Geräte-Namespace (Abbildung 3). Daher bezieht sich „file://./UNC/“ auf den UNC-Namespace.
Abb. 3: URL mit einem Punkt-Hostnamen (https://en.wikipedia.org/wiki/File_URI_scheme)
Zur Verdeutlichung: Beide Funktionen betrachten unseren Eingabepfad als UNC-Pfad, jedoch von einem anderen Typ: CreateFile behandelt ihn als lokalen Windows-Gerätepfad, während MapUrlToZone ihn als URL ansieht.
An diesem Punkt können wir Verwirrung zwischen den beiden Funktionen auslösen. Wenn wir also nicht tricksen, würde MapUrlToZone Akamai.com immer noch als Hostname interpretieren. Und da dieser Hostname eine Internetdomain ist, gibt die Funktion 3 zurück. Es ist also keine Umgehung. Wir müssen eine andere Möglichkeit finden, den Parsingprozess auszunutzen.
Später nutzt MapUrlToZone eine innere Funktion namens SetPath, um die Pfadkomponente zu verarbeiten (Tabelle 9).
CreateFile |
SetPath |
|---|---|
Wenn RtlPathTypeLocalDevice → 4 Zeichen weiterrücken |
|
Nachgestellte Leerzeichen überspringen |
|
„/“ in „\“ konvertieren |
|
Wiederholte „\“ ausblenden |
|
Komponenten wie „.“ und „..“ entfernen |
Komponenten wie „.“ und „..“ entfernen |
Tabelle 9: Vergleich der abgeschlossenen Vorgänge zwischen CreateFile und SetPath
Wieder einmal können wir den Unterschied zwischen den Operationen der beiden Funktionen ausnutzen. Wir wissen aus unserer vorherigen Schwachstelle, dass das Hinzufügen eines zusätzlichen Schrägstrichs zu einer Umgehung führen kann. Also ist es sinnvoll, es erneut zu versuchen. CreateFile entfernt einfach den zusätzlichen Schrägstrich.
Mit MapUrlToZone gibt CreateUri den absoluten URI „file://./UNC//Akamai.com/file.wav” zurück. Diese URI wird an GetZoneFromUriInternal übergeben, was intern zu einem anderen CreateUri-Aufruf führt.
Und warum ist das ein Problem? Da CreateUri eine URL empfangen hat, konvertiert sie sie mit der folgenden Funktion zurück in einen Windows-Pfad: PathCreateFromUrlW. Der zurückgegebene Windows-Pfad lautet „\\.\UNC\\Akamai.com\test.wav”. Die korrigierte Version weiß jetzt, dass der zusätzliche Schrägstrich entfernt werden muss. Sie versteht somit korrekt, dass Akamai.com der Hostname ist.
Das bedeutet, dass wir einen komplizierteren Exploit des Unterschieds zwischen CreateFile und SetPath benötigen. Dieses Mal werden wir zwei Unterschiede ausnutzen:
CreateFile blendet wiederholte Pfadtrennzeichen aus.
CreateFile entfernt die Komponenten „.“ und „..“ nach dem Ausblenden der wiederholten Pfadtrennzeichen.
Dies ist ein Pfad, der beide Unterschiede ausnutzt: \\./UNC/C://../Akamai.com/file.wav. Die Verarbeitung ist im Flussdiagramm in Abbildung 4 detailliert dargestellt.
Abb. 4: Flussdiagramm des Pfads, der von den beiden Funktionen geparst wird
Wir wissen bereits, dass der endgültige Pfad von CreateFile als UNC-Pfad behandelt wird. Was die Ausgabe von SetPathangeht: MapUrlToZone ruft GetZoneFromUriInternal mit der absoluten URI „file://./UNC/C:/Akamai.com/file.wav“ an. Dieses Mal konvertiert PathCreateFromUrlW diese URL in den Windows-Pfad „\\.\UNC\C:\Akamai.com\file.wav”. Dies ist ein lokaler Pfad, also gibt MapUrlToZone 0 aus (lokal). Wir haben wieder eine schöne Umgehung entdeckt!
Zur Behebung des Problems ruft der Code jetzt NormalizeDosDevicePrefix zum Konvertieren von Schrägstrichen in umgekehrte Schrägstriche an. Dadurch sollen Verwirrungen bei der Erkennung eines lokalen Gerätepfads vermieden werden.
Erkennung und Beseitigung
Microsoft hat eine umfassende Anleitung zur Erkennung der ursprünglichen Sicherheitslücke in Outlook und Abwehrmaßnahmen veröffentlicht. Aus unserer Beobachtung geht hervor, dass alle genannten Methoden auf die neue Sicherheitslücke angewendet werden können, da sie nicht von der URL in der PidLidReminderFileParameter-Eigenschaft abhängen.
Wir empfehlen Unternehmen auf Mikrosegmentierung zu setzen, damit ausgehende SMB-Verbindungen zu öffentlichen Remote-IP-Adressen blockiert werden können. Darüber hinaus empfehlen wir, NTLM in Ihrer Umgebung zu deaktivieren oder Nutzer zur Gruppe „Geschützte Nutzer“ hinzuzufügen. Dies verhindert die Verwendung von NTLM als Authentifizierungsmechanismus.
Das Blockieren ausgehender SMB-Verbindungen und das Deaktivieren von NTLM können dazu beitragen, den Diebstahl von Anmeldedaten zu verhindern. Wenn SMB-Anfragen jedoch fehlschlagen, geht Windows auf WebDAV über, sofern es aktiviert ist. Der Diebstahl von Anmeldedaten kann nicht über WebDAV ausgenutzt werden. Dennoch ist das Herunterladen der Audiodatei weiterhin möglich, was der zweite Schritt in unserer RCE-Kette ist.
Warum hören wir hier auf?
In diesem Beitrag haben wir den Forschungsprozess einschließlich der Ursachenanalyse detailliert beschrieben, der zur Entdeckung der beiden Umgehungen geführt hat. Wie wir gezeigt haben, ist der Parsingcode für den Windows-Pfad komplex und anfällig für Schwachstellen. Sicherheitsforscher, die mit Code für die Handhabung von Pfaden konfrontiert sind, sollten über die damit einhergehende Angriffsfläche nachdenken.
Abgesehen vom Umgehen von MapUrlToZone im Outlook-Kontext lässt sich nicht ausschließen, dass diese Schwachstellen auch zu MOTW-Umgehungen (Mark-of-the-Web) führen können.
Abgesehen von der Möglichkeit, NTLM-Anmeldedaten zu verbreiten, haben wir auch die Möglichkeit, eine willkürliche Audiodatei herunterzuladen und wiederzugeben. Sie können jetzt Teil 2 dieser Blogreihe lesen, der die Schwachstelle beim Audio-Parsen detailliert aufzeigt.
