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 wurden verantwortungsvoll an Microsoft weitergegeben und am 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 umfangreiche Untersuchungen zu den Produkten und Protokollen durchgeführt, um sowohl Schwachstellen zu finden als auch Tools zu erstellen, die bei der Erkennung und Abwehr unterstützen.
Im Rahmen dieser Studie haben wir eine neue RCE-Sicherheitslücke in der WinAPI-Funktion CreateUri entdeckt. Diese wird im Rahmen des Patches für die ursprüngliche Sicherheitsanfälligkeit CVE-2023-23397 aufgerufen. In der vorherigen RCE-Schwachstellenverkettung mussten zwei Schwachstellen miteinander verketten werden, um ein Null Click RCE-Primitiv zu erreichen. Diese Lücke ist allein dazu in der Lage. Zusätzlich zu Outlook zeigen wir Ihnen, wie Sie die Schwachstelle im Datei-Explorer auslösen können.
Die Geschichte der Schwachstelle
Eine der Schwachstellen, die im Rahmen des Patch Tuesday im März 2023 behoben wurde, war eine kritische Outlook-Sicherheitslücke, die von Microsoft selbst entdeckt wurde (Kennung CVE-2023-23397) und im freien Internet von einer Gruppe russischer, staatlich finanzierter Cyberkrimineller mit Namen Forest Blizzard ausgenutzt wurde.
Im Dezember 2023 veröffentlichten Microsoft und die polnische 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 Sicherheitslücke veröffentlicht wurde, fanden wir zwei Möglichkeiten zur Umgehung und eine weitere 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 für die Verarbeitung eines individuellen Erinnerungstons einen Aufruf an MapUrlToZone hinzu. Der Aufruf prüft, ob die URL, die über die erweiterte MAPI-Eigenschaft PidLidReminderFileParameter angegeben wurde, nicht auf eine Internetressource verweist.
Obwohl dadurch die anfängliche Sicherheitslücke geschlossen wird, wird eine neue Angriffsfläche hinzugefügt – die Funktion MapUrlToZone selbst. Also kontrollieren wir den Pfad, der für MapUrlToZone angegeben wurde.
Als Teil des Parsens von MapUrlToZone ruft es CreateUri auf. CreateUri erstellt ein IUri-Objekt, das einen Uniform Resource Identifier (URI) darstellt. Um das Objekt zu erstellen, kann die Funktion beide URLs und einen Teil der 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/ein Verzeichnis verweist), wird die Funktion CrackUrlFile aufgerufen. Dies ist auch die Funktion, die die Umgehungen enthält, wie im vorherigen Blogbeitrag erläutert und demonstriert.
Die neue Schwachstelle
Wenn CrackUrlFileanfangs 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 ist uns aufgefallen, dass im Juli 2023 in CrackUrlFile neuer Code hinzugefügt wurde. Dies schien nicht mit unseren Umgehungen zusammenzuhängen (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) wird 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.
Dazu haben wir eine Verknüpfung erstellt (.lnk-Datei), 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).
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. (Lesen Sie die Einzelheiten und Risiken des PoC in unserem Repository für die Sicherheitsforschung vor der Anwendung sorgfältig durch.)
Abb. 2: Explorer stürzt infolge des PoC ab
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 MapUrlToZone eine neue Angriffsfläche hinzufügt. 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.
In unseren nachfolgenden Untersuchungen konnten wir genau das beweisen. Wir fanden zwei Möglichkeiten zur Umgehung, einen Fehler beim Audio-Parsen und schließlich einen fehlerhaften Speicher beim Parsen eines Windows-Pfads.
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 mehr ausschließen, dass weitere Umgehungen für MapUrlToZone existieren.
Sie haben noch nicht genug?
Lesen Sie unsere vorherigen Blogbeiträge zu diesem Thema: