CreateRCE: eine weitere Sicherheitslücke in CreateUri
Zusammenfassung
Ben Barnea, Forscher bei Akamai, fand eine kritische Schwachstelle in Microsoft Windows, der die Kennung CVE-2023-35628 zugewiesen wurde.
Ein Angreifer im Internet kann die Sicherheitslücke für Outlook-Clients ohne Nutzereingriff auslösen (Null-Klick).
Die Schwachstelle besteht im Parsen eines Pfads durch die Funktion CreateUri. Wir kennen derzeit zwei Möglichkeiten, diese Schwachstelle auszulösen: (1) indem Sie eine manipulierte E-Mail an einen Outlook-Client senden oder (2) einen Nutzer dazu verleiten, im Windows-Explorer zu einem Ordner zu navigieren, der eine heruntergeladene Schaddatei enthält.
Die Schwachstelle wurde verantwortungsvoll an Microsoft weitergegeben und im Patch Tuesday im Dezember 2023 behoben.
Auf Windows-Computern, bei denen das Softwareupdate vom Dezember 2023 installiert wurde, ist diese Sicherheitslücke 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.
Einführung
Die Omnipräsenz von Microsoft in der Unternehmenswelt und darüber hinaus macht es zu einem großen (und lukrativen) Ziel für Angreifer. Daher haben wir umfassende Untersuchungen zu den Produkten und Protokollen durchgeführt, um sowohl Schwachstellen zu finden als auch Tools zu entwickeln, die bei der Erkennung und Abwehr unterstützen.
Im Rahmen dieser Studie haben wir eine neue RCE-Sicherheitslücke (Remote Code Execution) in der WinAPI-Funktion CreateUri entdeckt, die als Teil des Patches für die ursprüngliche Schwachstelle CVE-2023-23397 aufgerufen wird. Bei der vorherigen RCE-Schwachstellenkette mussten zwei Schwachstellen miteinander verkettet werden, um ein Null-Klick-RCE-Primitiv zu erreichen. Diese Schwachstelle kann dies alleine tun. Zusätzlich zu Outlook zeigen wir Ihnen, wie Sie die Schwachstelle im Datei-Explorer auslösen können.
Die Geschichte der Schwachstelle
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), die von Microsoft selbst entdeckt wurde. Diese wurde von einer Gruppe russischer, staatlich finanzierter Cyberkrimineller mit Namen Forest Blizzard im freien Internet ausgenutzt.
Im Dezember 2023 veröffentlichten Microsoft und die polnische Cyberabwehr, 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 Sicherheitslücke veröffentlicht wurde, fanden wir neben zwei Umgehungen auch eine Schwachstelle beim Audio-Parsen. Die Verkettung der Schwachstellen für Umgehung und Parsen kann zu einem vollständigen Null-Klick-RCE-Primitiv auf dem Outlook-Client führen.
MapUrlToZone
Als Teil des Patches für die Outlook-Sicherheitslücke CVE-2023-23397 fügt der Code, der für die Verarbeitung eines nutzerdefinierten Erinnerungstons verantwortlich ist, einen Aufruf an MapUrlToZone hinzu. Der Aufruf prüft, ob die angegebene URL, die über die erweiterte MAPI-Eigenschaft PidLidReminderFileParameter angegeben wird, nicht auf eine Internet-Ressource verweist.
Obwohl dies das Risiko der anfänglichen Schwachstelle mindert, schafft es eine neue Angriffsfläche – die Funktion MapUrlToZone selbst. Wir kontrollieren den Pfad, der an MapUrlToZone weitergegeben wird.
Als Teil des Parsens durch MapUrlToZone wird CreateUri aufgerufen. CreateUri erstellt ein IUri-Objekt, das einen Uniform Resource Identifier (URI) darstellt. Um das Objekt zu erstellen, kann die Funktion sowohl URLs als auch einige DOS-Windows-Pfade parsen.
Wenn CreateUri mit einem Dateipfad aufgerufen wird (z. B. mit dem Schema file:// oder einem Windows-Pfad, der auf eine Datei bzw. ein Verzeichnis verweist), wird die Funktion CrackUrlFile aufgerufen. Dies ist auch die Funktion, die die Umgehungen enthält, wie im vorherigen Blogbeitrag beschrieben.
Die neue Schwachstelle
Wenn CrackUrlFile anfangs eine URL anstelle eines Windows-Pfads empfängt, erstellt die Funktion eine Kopie der Eingabe und wandelt die URL-Kopie dann mithilfe von PathCreateFromUrlW in einen Windows-Pfad um. Der Arbeitspuffer wird als dynamisch zugewiesen markiert, sodass er später freigeben kann. Wenn die Funktion einen Windows-Pfad empfängt, arbeitet sie direkt auf dem Eingabepfad und muss daher den Zeiger nicht freigeben.
Während der Analyse des Arbeitspuffers kann der Puffer erweitert werden. Wenn es sich z. B. um einen lokalen Gerätepfad handelt (beginnend mit „\\.\“ oder „\\?\“), wird der Zeiger durch die Funktion um vier Zeichen erweitert. Wenn der Gerätename dann „UNC\“ lautet, wird er um vier weitere Zeichen vorangestellt. Wenn mehrere umgekehrte Schrägstriche vorhanden sind, verschiebt die Funktion den Puffer auch über die duplizierten umgekehrten Schrägstriche hinaus.
Beim Rückgängigmachen der Patches für die Umgehungen wurde im Juli 2023 in CrackUrlFile neuer Code hinzugefügt, der scheinbar nicht mit unseren Umgehungen zusammenhängt (Abbildung 1).
Abb. 1: Dekompilierung von neu hinzugefügtem Code
Im Rahmen des Pfad-Parsens prüft die Funktion, ob die Pfadkomponente entweder zu einem Laufwerkpfad oder zu einem Rootpfad gehört. Wenn ja, wird der Pfad als lokal markiert. Der neue Code überschreibt den ursprünglichen Pufferzeiger mit einem Zeiger auf die Pfadkomponente (dem erweiterten Puffer), wenn der Pfad ein Laufwerkpfad ist.
Dies ist der Ursprung des Bugs: Der Zeiger, der erweitert wurde, wird gespeichert. Später wird der ursprüngliche Pufferzeiger (PPWorkingBuffer in Abbildung 1) abgerufen und freigegeben, wenn er dynamisch zugewiesen wurde. Da er mit dem erweiterten Zeiger überschrieben wurde, geschieht ein Aufruf zu free() mit einem Zeiger, der nicht von malloc zurückgegeben wurde. Dies ermöglicht dem Angreifer ein Primitiv, um der Speicherzuordnung die Metadaten eines schädlichen Chunks bereitzustellen.
Damit die Sicherheitslücke ausgelöst wird, müssen wir zunächst eine Dateischema-URL mit einem UNC-Pfad angeben. Dann müssen wir den Pfad als Laufwerkspfad markieren und einen freigegebenen Datenträger (C:) verwenden. Der vollständige Pfad zum Auslösen der Schwachstelle sieht folgendermaßen aus:
file://./UNC/C:/Akamai.com/file.wav
Der feste Code kopiert nun die Bytes der Pfadkomponente mit RtlMoveMemory, anstatt den Zeiger zu speichern.
Auslösen über Explorer
Obwohl es nicht Bestandteil unserer Forschung war, solche Orte zu finden, haben wir einen schnellen Versuch unternommen: das Auslösen über Windows-Explorer.
Dafür haben wir eine Verknüpfung (.lnk-Datei) erstellt, die auf den anfälligen Pfad verweist. Sobald das Opfer das Verzeichnis anzeigt, in dem sich die Verknüpfungsdatei befindet, wird die Sicherheitslücke in Explorer ausgelöst, was zu einem sofortigen Absturz führt (Abbildung 2).
Abb. 2: Explorer stürzt infolge des PoC ab
Um zu testen, ob Ihr Computer anfällig für dieses Problem ist, können Sie gern unseren Proof of Concept (PoC) herunterladen, der Explorer zum Absturz bringen wird. (Bitte lesen Sie sich vor der Verwendung sorgfältig die Details und Risiken des PoC in unserem Repository für die Sicherheitsforschung durch.)
Zusammenfassung
Dies ist unser letzter Forschungsblogbeitrag zu den potenziellen Auswirkungen von CVE-2023-23397.
Als wir im Mai 2023 die erste Umgehung entdeckten, empfahlen wir, die missbrauchte Funktion zu entfernen, da durch die Verwendung von MapUrlToZone eine neue Angriffsfläche geschaffen wird. Wir haben auch erläutert, dass es für Nutzer mehr Gefahren als Vorteile mit sich bringt, wenn eine Null-Klick-Angriffsfläche beim Audio-Parsen ohne Sandbox für Angreifer offengelegt wird.
Bei unserer weiteren Recherche konnten wir dies genau beweisen, indem wir sowohl zwei Umgehungen als auch eine Schwachstelle beim Audio-Parsen und schließlich einen fehlerhaften Speicher beim Parsen eines Windows-Pfads entdeckten.
Wir hoffen, dass Sie in diesen Beiträgen Neues über Windows-Pfade, Audio-Codecs und verschiedene Schwachstellen erfahren haben. Wir rufen auch andere Forscher dazu auf, Patches zu analysieren und sich zu überlegen, wie sie umgangen werden können. Wir können nicht ausschließen, dass weitere MapUrlToZone-Umgehungen existieren.
Sie haben noch nicht genug?
Lesen Sie unsere vorherigen Blogbeiträge zu diesem Thema:
