Von einer Schwachstelle zur nächsten: Outlook-Patch-Analyse enthüllt schwerwiegenden Fehler in Windows-API
Redaktion und weitere Beiträge von Tricia Howard
Zusammenfassung
Der Akamai-Forscher Ben Barnea fand eine neue große Sicherheitslücke in einer Internet-Explorer-Komponente: CVE-2023-29324 mit einem CVSS-Basiswert von 6,5.
Die Sicherheitslücke bewirkt, dass eine Windows-API-Funktion – MapUrlToZone – fälschlicherweise davon ausgeht, dass es sich bei einem Remote-Pfad und einen lokalen Pfad handelt.
MapUrlToZone wird häufig als Sicherheitsmaßnahme eingesetzt. Sie wurde insbesondere bei der kritischen Outlook-Sicherheitslücke CVE-2023-23397, die während des Patch Tuesday im März behoben wurde, zur Abwehr eingesetzt.
Ein nicht authentifizierter Angreifer im Internet könnte die Sicherheitslücke nutzen, um einen Outlook-Client zu zwingen, eine Verbindung zu einem vom Angreifer kontrollierten Server herzustellen. Dies führt zum Diebstahl von NTLM-Anmeldedaten. Es handelt sich um eine Null-Klick-Schwachstelle, d. h. sie kann ohne Interaktion mit dem Nutzer ausgelöst werden.
Alle Windowsversionen sind von der Schwachstelle betroffen. Daher können alle Outlook-Clientversionen in Windows angegriffen werden. Laut Microsoft verzichten Exchange-Server mit dem März-Update jedoch auf die anfällige Funktion. So wird verhindert, dass anfällige Clients angegriffen werden.
Das Problem wurde verantwortungsvoll an Microsoft weitergegeben und im Patch Tuesday für Mai 2023 behoben.
Einführung
Zu den Sicherheitslücken, die im Rahmen des Patch Tuesday im März 2023 behoben wurden, gehört eine kritische Schwachstelle in Outlook mit der Kennung CVE-2023-23397.
Über diese Schwachstelle können Angreifer einen Outlook-Client zwingen, eine Verbindung zum Server des Angreifers herzustellen. Dadurch sendet der Client NTLM-Anmeldedaten an den Computer, wodurch der Angreifer das Passwort offline knacken oder bei einem Relay-Angriff verwenden kann. Ein Angriff auf diese Schwachstellen kann per Remotezugriff über das Internet erfolgen, ohne dass eine Interaktion mit dem Nutzer erforderlich ist (Null-Klick).
Laut einer Bewertung von Microsoft Threat Intelligence nutzt ein russischer Cyberkrimineller die Schwachstelle seit etwa einem Jahr für gezielte Angriffe auf mehrere Organisationen in der europäischen Regierung, im Verkehrs-, Energie- und Militärsektor aus.
Im Rahmen unserer Analyse des Patches haben wir einen Weg gefunden, die Problembehebung für diese kritische Schwachstelle zu umgehen. In diesem Blogbeitrag werden wir die ursprüngliche Schwachstelle, den Patch und die Umgehung dieses Patches beleuchten.
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.
Zur Behebung des Problems ruft der Code jetzt MapUrlToZone auf, um zu überprüfen, ob der Pfad sich auf eine Internet-URL bezieht. Wenn dies der Fall ist, wird der standardmäßige Erinnerungston anstelle des individuellen Tons verwendet.
Umgehen der Abwehrmaßnahmen
Sehen wir uns zunächst den relevanten Codeablauf in Outlook an. Beim Laden der individuellen Audiodatei werden zwei wichtige Funktionen aufgerufen:
MapUrlToZone – sendet die Zone der URL zurück; wird verwendet, um zu bestimmen, ob der Pfad lokal, ein Intranet-Pfad oder vertrauenswürdig (und kein Internet-Pfad) ist
CreateFile – öffnet einen Handle für die Audiodatei
Hinweis: SearchPath wird vor CreateFile ebenfalls aufgerufen, geht mit dem Pfad jedoch ähnlich um. Aus Gründen der Übersichtlichkeit wird hier nur auf CreateFile verwiesen.
Um eine Umgehungsmöglichkeit zu finden, müssen wir einen Pfad finden, den MapUrlToZone als lokale, Intranet- oder vertrauenswürdige Zone betrachtet und den CreateFile darüber hinaus als Internetdomain behandelt.
Um MapUrlToZone aufzurufen, können wir das folgende PowerShell-Skript verwenden, das die Funktion über Component Object Model (COM) aufruft.
Um zu überprüfen, ob MapUrlToZone eine geeignete Abwehrmaßnahme ist, können wir die Funktion testen, indem wir sie auf demselben Pfad aufrufen, der die Sicherheitslücke ausgelöst hat. Dabei handelt es sich um einen absoluten UNC-Pfad mit einer Internetdomain. MapUrlToZone sendet „3“ zurück. Dies deutet darauf, dass sich der Pfad wie erwartet in der Internetzone befindet.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
Wir können kreativ werden und unseren UNC-Pfad anpassen, indem wir einen lokalen Gerätepfad verwenden:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
Wie oben dargestellt, identifiziert MapUrlToZone den Pfad immer noch als Internetzone, sodass er weiterhin blockiert bleibt, wie mit der Fehlerbehebung beabsichtigt.
Bei Hinzufügen eines weiteren „\“ nach dem „UNC\“ sendet MapUrlToZone nun jedoch „0“ zurück, was einem lokalen Pfad entspricht:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
MapUrlToZone kommt also zu dem Schluss, dass diese URL lokal ist. Die wichtige Frage lautet nun: Wie beurteilt CreateFile diese URL? Greift sie auf eine lokale Datei zu oder lädt sie sie über SMB herunter?
Trommelwirbel, bitte …
Abb. 1: Simulation eines CreateFile-Aufrufs mit dem UNC-Pfad, der zu einer DNS-Anfrage führt
Sehr schön! Es wurde eine DNS-Anfrage gesendet, um die IP von Akamai.com abzurufen (Abbildung 1). Es scheint, als hätten wir einen Pfad gefunden, den MapUrlToZone als lokal einstuft, der CreateFile jedoch veranlasst, einer Anfrage an das Internet zu senden!
Lassen Sie uns nun die ursprüngliche Outlook-Schwachstelle auslösen, diesmal unter Umgehung der zusätzlichen Abwehrmaßnahmen.
Abb. 2: Auslösen des Kalenderereignisses, das zur NTLM-Authentifizierung bei einem Remoteserver führt
Wie Sie in Abbildung 2 sehen, stellt Outlook nach dem Einblenden der Erinnerung eine Verbindung zum Remoteserver her, was zu einer NTLM-Authentifizierung führt.
Laut Microsoft verwenden Exchange-Server, auf denen das Softwareupdate im März installiert wurde, die Eigenschaft PidLidReminderFileParameter nicht, was die Funktion für individuelle Audiodateien eliminiert. Daher sind nur die Computer für dieses Problem anfällig, auf denen Outlook-Clients mit einem Exchange-Server ausgeführt werden, auf dem das Problem nicht behoben worden ist.
Die Grundursache
Dieses Problem scheint auf die komplexe Handhabung von Pfaden in Windows zurückzuführen zu sein.
MapUrlToZone ruft die Funktion CreateUri auf, die den Pfad „\\.\UNC\\Akamai.com\file.wav“ fälschlicherweise in „/.//UNC//Akamai.com/file.wav“ umwandelt.
Um zu sehen, welcher Zugriff durch den letztgenannten Pfad ausgelöst wird, verwenden wir das Skript ConvertDosPathToNtPath aus James Forshaws Blogbeitrag.
PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
Converting: '/.//UNC//Akamai.com/file.wav'
To: '\??\C:\UNC\Akamai.com\file.wav'
Type: RtlPathTypeRooted
FileName: file.wav
FullPathName: 'C:\UNC\Akamai.com\file.wav'
Dieser Pfad verweist nun auf ein Verzeichnis mit dem Namen „UNC“ auf dem lokalen Laufwerk C:. Dies ist offensichtlich ein lokales Verzeichnis und daher sendet MapUrlToZone „0“ zurück.
Auf der anderen Seite wandelt CreateFile zuerst den ursprünglichen Pfad von einem DOS-Pfad in einen NT-Pfad um, indem RtlpDosPathNameToRelativeNtPathName aufgerufen wird. Auch hier können wir mithilfe des Skripts die Ausgabe dieser Konversion beobachten.
PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
Converting: '\\.\UNC\\Akamai.com\file.wav'
To: '\??\UNC\Akamai.com\file.wav'
Type: RtlPathTypeLocalDevice
FileName: file.wav
FullPathName: '\\.\UNC\Akamai.com\file.wav'
Beachten Sie, dass das Ergebnis diesmal nicht auf ein lokales Laufwerk verweist. Warum wird also eine SMB-Anfrage ausgelöst? Wie im obigen Snippet zu sehen ist, lautet der resultierende Pfad „\?\UNC\Akamai.com\file.wav“. Der Zugriff auf diesen NT-Pfad führt dazu, dass der Object Manager die IO-Anfrage an den MUP-Treiber (Multiple UNC Provider) weiterleitet. (Das passiert, weil der Eintrag zum globalen Objektverzeichnis für „UNC“ eine symbolische Verknüpfung zu „\Device\Mup“ darstellt.) Da RtlpDosPathNameToRelativeNtPathName den zusätzlichen „\“ entfernt oder ausgeblendet hat, enthält der Pfad jetzt nur noch den Internetdomainnamen.
Wir glauben, dass diese Art von Unklarheit potenziell Schwachstellen in anderen Programmen verursachen kann, die MapUrlToZone auf einem vom Nutzer kontrollierten Pfad verwenden und dann eine Dateioperation (wie CreateFile oder eine ähnliche API) auf demselben Pfad verwenden. Außerdem können wir andere Probleme bei Programmen, die CreateUri aufrufen, nicht ausschließen.
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.
Zusammenfassung
Diese Schwachstelle ist ein weiteres Beispiel dafür, wie die genaue Überprüfung von Patches zu neuen Schwachstellen und Umgehungsmöglichkeiten führen kann. Im Fall dieser Sicherheitslücke ermöglicht das Hinzufügen eines Zeichens eine kritische Möglichkeit, den Patch zu umgehen.
Wir hoffen, dass die Funktion für den individuellen Erinnerungstons vollständig entfernt wird, da sie mehr Sicherheitsrisiken birgt als Wert für die Nutzer bietet. Dabei handelt es sich um eine Angriffsfläche, über die ohne einen Mausklick eine Medienanalyse durchgeführt wird, und die potenziell kritische Sicherheitslücken im Bezug auf fehlerhafte Speicher enthalten kann. Wenn man bedenkt, wie allgegenwärtig Windows ist, könnte die Beseitigung einer so anfälligen Angriffsfläche viele positive Auswirkungen haben.
Im Rahmen unserer kontinuierlichen Bemühungen, unsere Kunden und die Community zu schützen, werden wir weiterhin Patches und andere Systeme auf Schwachstellen analysieren. Um über die neuesten Sicherheitsstudien von Akamai auf dem Laufenden zu bleiben, folgen Sie uns auf Twitter.
Wir möchten uns bei Microsoft für die Zusammenarbeit und die schnelle Reaktion bei der Lösung dieses Problems bedanken.
