CVE-2020-0753-and-CVE-2020-0754

Writeup und POC für CVE-2020-0753, CVE-2020-0754 und sechs behobene Windows-DOS-Sicherheitslücken

Exploit des FileSystem-Race-Condition-Bugs – Analyse von CVE-2020-0753 und CVE-2020-0754

Der Windows Error Reporting-Dienst hat im letzten Patch Tuesday zwei Privilegienausweitungs-Bugs behoben. Die beiden Bugs sind CVE-2020-0753 und CVE-2020-0754 zugewiesen. Beide Bugs nutzen einen Race-Condition-Bug in den FileSystem-Operationen des Dienstes. Allerdings sind diese beiden Bugs nicht so einfach auszunutzen, da die Race-Fenster klein und die Speicherorte der abgelegten Dateien ungewiss sind. Hier teilen wir unsere Techniken, um sie auszunutzen.

Die Ursache der beiden Race-Bugs ist in unseren Berichten beschrieben; die eigentliche Ursache lässt sich als Vorhersehbar ist verwundbar ausdrücken. Wenn der WER-Dienst temporäre Dateien verarbeitet, manipuliert er den Dateispeicherort C:\ProgramData\Microsoft\Windows\WER\Temp, ein Verzeichnis, das für authentifizierte Benutzer über Lese-/Schreibrechte verfügt. Das bedeutet, dass ein normaler Benutzer mit mittlerer Integritätsstufe (Medium-IL) eine vom WER-Dienst erstellte Datei überschreiben und sie sogar in einen FileSystem-Link verwandeln kann, um andere Dateien zu beschädigen oder zu löschen, die er ansonsten nicht hätte anfassen können.

Um Dateioperationen sicher zu halten, verlässt sich der WER-Dienst auf eine Standard-API namens GetTempFileNameW und hat sie mit wersvc.dll->UtilGetTempFile umschlossen. Diese API hilft WerSvc, einen freien zufälligen Dateinamen in der Form "WER****.tmp" zu erzeugen.

Der zufällige Teil des Dateinamens wird mit einer 4-Byte-Hexadezimalzahl von 0000-FFFF erzeugt. Wenn eine Zahl bereits zur Erstellung einer Datei verwendet wurde, nimmt die API einen anderen zufälligen Dateinamen.

Die Strategie hat eindeutig eine Schwachstelle, wenn man 65.535 Dateien mit Namen von WER0000.tmp bis WERFFFE.tmp erstellt. Die API wählt dann eine Zufallszahl und testet, ob der Dateiname bereits existiert, z. B. WERA560.tmp. Sie stellt fest, dass die Datei bereits existiert, und testet daher weiter von WERA560.tmp bis WERFFFF.tmp. Während dieser Tests entsteht ein Vorbereitungsfenster, weil wir einen Weg gefunden haben, WerSvc für 4–5 Sekunden im GetTempFileNameW-Aufruf festzuhalten – ein ziemlich großes Zeitfenster. In der Zwischenzeit zwingen wir den Dienst, eine temporäre Datei mit festem Dateinamen abzulegen, nämlich WERFFFF.tmp.

Nachdem der Dienst die temporäre Datei namens WERFFFF.tmp erstellt hat, schließt die API automatisch den Handle, den sie auf die Datei hält, und gibt den Dateinamen an den Dienst für weitere Operationen an der Datei zurück. Genau hier liegt die Stelle, die den Bug einführt. Drei Bedingungen sind erfüllt:

1. Die vom Dienst erstellte Datei befindet sich an einer für normale Benutzer kontrollierbaren Position.

2. Der Dienst schließt alle Handles auf die Datei.

3. Der Dienst verwendet die Datei später (Schreiben oder Löschen).

Hier wird der Dienst Inhalte in die Datei schreiben und sie löschen. Sowohl das Schreiben als auch das Löschen führen zu einer Privilegienausweitung durch die Nutzung von FileSystem-Links und bestimmten Exploitation-Techniken.

Um den Bug in ein beliebiges Löschen von Dateien umzuwandeln, nutzen wir kreativ mehrere Directory-Junctions, um die Ausnutzung abzuschließen. Unser Exploit umfasst die folgenden Schritte:

• Wir legen alle WER***.tmp in $pwd\1\ ab und setzen eine Junction $pwd\2\ -> $pwd\1\;
• Wir erstellen einen Prozess, der diese Funktion kontinuierlich mit dem Pfad $pwd\2\ aufruft, und einen weiteren Prozess, der kontinuierlich den Befehl SetOplock $pwd\1\WERFFFF.tmp ausführt;
• Sobald der Oplock ausgelöst wird, setzen wir eine Junction $pwd\2\ -> \RPC CONTROL\ und erstellen dann symbolische Objekte \RPC CONTROL\WERFFFF.tmp -> $target und \RPC CONTROL\WERFFFF.tmp.etl -> $target
• Lässt man den Oplock los, wird die Zieldatei mit Systemrechten gelöscht.

Die detaillierte Exploitation und der POC sind in WERReport-CVE-2020-0753 bereitgestellt.

Durch die Ausnutzung des Fehlers in GetTempFileNameW erhalten wir einen vorhersehbaren Speicherort, an dem der Dienst arbeitet; durch die Nutzung mehrstufiger FileSystem-Junctions machen wir die Race Condition zuverlässig ausnutzbar.

In der Zwischenzeit haben wir festgestellt, dass diese Art von Race-Bug auch ein mögliches Überschreiben von Dateien verursachen kann, was unter bestimmten Umständen wahrscheinlich zu Privilegienausweitungs-Bugs führt.

Von beliebiger Dateibeschädigung mit teilweiser Kontrolle zur Privilegienausweitung

Um zu erklären, warum eine beliebige Dateibeschädigung (wenn man einen sehr kleinen Teil des Dateiinhalts kontrollieren kann: weniger als 63 Bytes) in EoP umgewandelt werden kann, müssen wir uns den Arbeitsmechanismus von Windows Defender ansehen.

Windows Defender verfügt über eine Datenbank mit Malware-Signaturen. Wenn eine Datei eine Malware-Signatur enthält, betrachtet Defender sie als Malware und löscht sie. Diese Funktion führt jedoch zu einer zusätzlichen Angriffsfläche. Zum Beispiel hat WCTF2019 @icchy von tokyowesterns eine Windows-CTF-Challenge namens "Gyotaku The Flag" entworfen, die diese Funktion als Orakel nutzt, um Informationen preiszugeben.

Hier nutzen wir diese Funktion von Windows Defender, um beliebige Dateien zu löschen, wenn wir eine beliebige Dateibeschädigung mit teilweiser Kontrolle über den Dateiinhalt haben. Wir können einfach eine Malware-Signatur in eine Datei schreiben und einen Standardscan durch Windows Defender auslösen. Die Datei wird dann in den Isolationsbereich von Defender verschoben, der von einem normalen Benutzer (d. h. einem Nicht-Admin-Benutzer mit Medium-IL) gelöscht werden kann, indem man den Scanvorgang einfach zweimal auslöst.

So kann ein Bug zur beliebigen Dateibeschädigung in ein beliebiges Löschen von Dateien umgewandelt werden, solange mithilfe des Bugs eine von Windows Defender erkennbare Malware-Signaturzeichenfolge in die Zieldatei geschrieben werden kann.

• Schritt 1:

Beschädigen Sie die Zieldatei mit einem Bug und fügen Sie eine von Windows Defender erkennbare Signaturzeichenfolge ein.

• Schritt 2:

Lösen Sie Windows Defender aus, um die Zieldatei zu scannen, wodurch die Datei isoliert wird.

• Schritt 3:

Lösen Sie den Scan erneut aus; die Zieldatei wird gelöscht.

Durch diese Technik erhalten wir mit Defenders Hilfe das Löschen beliebiger Dateien.

Das Löschen beliebiger Dateien kann viel einfacher ausgenutzt werden, um weitere Privilegien zu erlangen.

Sechs behobene FileSystem-DOS-Sicherheitslücken in Microsoft OneDrive

Microsoft OneDrive ist das Anwendungspaket, das den persönlichen Cloud-Speicherdienst bereitstellt.

Diese Anwendung ist seit Windows 8 als Standardinstallationsoption in Windows integriert. Während unserer Forschung wurden 6 Sicherheitslücken in den geplanten Wartungsaufgaben (Scheduled Tasks) von OneDrive gefunden und an MSRC gemeldet.

---

Hier ist eine Tabelle der Sicherheitslücken, die wir in den relevanten geplanten Aufgaben von Microsoft OneDrive offenlegen:

Alle 6 Bugs werden dadurch verursacht, dass der Dienst Hardlinks und Symlinks nicht ordnungsgemäß behandelt, während er an Orten arbeitet, die für normale Benutzer kontrollierbar sind. Bei der Ausnutzung dieser Bugs ergibt sich eine Schwierigkeit daraus, dass der Dateiname normalerweise eine PID des aktuellen Prozesses oder einen Zeitstempel enthält, der markiert, wann die Datei verarbeitet wird. Beides kann gelöst werden, indem man einen Oplock auf eine eindeutige DLL-Datei setzt, die der Dienst zu laden versucht, wenn er zur Ausführung angestoßen wird. Dadurch erhalten wir alles, was wir benötigen, um den Dateinamen vorherzusagen, den der Dienst später verwenden wird. Ein Beispiel-POC ist im Verzeichnis FileSyncConfigTemp_hardlink bereitgestellt.

Auswirkungen der Sicherheitslücken

Alle 6 oben genannten Sicherheitslücken sind mit vollständigem Bericht und POC-Programm versehen. Obwohl die meisten Bugs in erster Linie eine beliebige Dateibeschädigung verursachen, kann diese Art von Bug dennoch einen Systemabsturz verursachen (durch Überschreiben kritischer Systemkonfigurationsdateien), und alle würden eine Neuinstallation von Windows erfordern. Damit erfüllen sie den Standard des Windows-System-Denial-of-Service-Bugtyps.

Darüber hinaus kann diese Art von Bug unter bestimmten Umständen tatsächlich eine Privilegienausweitung verursachen. Wir haben die Exploitation-Technik besprochen, die ein beliebiges Überschreiben von Dateien ausnutzen kann, um eine Primitive zum Löschen beliebiger Dateien zu erreichen; somit ist eine Privilegienausweitung erreichbar.

Danksagungen

Fangming Gu

Zhiniang Peng von Qihoo 360 Core Security

Zeitleiste

02. Feb. 2020: Sicherheitslücken gemeldet

08. Feb. 2020: MSRC untersuchte die 6 eingereichten OneDrive-Bugs und antwortete, dass sie keine Behebung vornehmen werden, weil zu viel Benutzerinteraktion erforderlich ist bzw. es zu schwierig ist, einen zuverlässigen Exploit zu erstellen.

08. Feb. 2020: Wir antworteten: Es ist keine Benutzerinteraktion erforderlich. Man muss nur warten, bis die geplante Aufgabe ausgeführt wird. Dieses Szenario ist also typisch.

11. Feb. 2020: MSRC antwortete: Wie gelangen Sie an die spezifische Datei auf dem Rechner des Benutzers? Und legen Sie jede Permutation dieser Datei in diesen Ordner? Muss sie exakt mit Datum/Stunde/PID übereinstimmen? Aus diesen Gründen scheint dies zu viel Benutzeraufwand zu erfordern.

11. Feb. 2020: Wir antworteten: Unser POC ist eine vereinfachte Version, um den Aufwand der Dateinamensvorhersage zu reduzieren. In Wirklichkeit muss man nur einen Oplock setzen. Dann erhält man alle {pid},{hour},{data}. Es ist also keine Benutzerinteraktion erforderlich.

12. Feb. 2020: Anfrage, ob wir den Writeup für diese 6 Sicherheitslücken veröffentlichen dürfen.

13. Feb. 2020: MSRC antwortete: Sie können einen Writeup veröffentlichen.

22. Feb. 2020: Details veröffentlicht

Status-Update: Alle 6 Sicherheitslücken wurden im Patch Tuesday im März 2020 behoben.