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

Writeup und Proof-of-Concept für CVE-2020-0753, CVE-2020-0754 und sechs ungefixte Window-DOS-Sicherheitslücken

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

Der Windows-Fehlerberichterstattungsdienst hat im letzten Patch Tuesday zwei Elevation-of-Privilege-Fehler behoben, den beiden Fehlern wurden die Bezeichnungen CVE-2020-0753 und CVE-2020-0754 zugewiesen. Beide Fehler nutzen einen Race-Condition-Fehler in den FileSystem-Operationen des Dienstes aus. Allerdings sind diese beiden Fehler aufgrund kleiner Race-Fenster und unsicherer Dateiablageorte nicht so einfach auszunutzen. Hier teilen wir unsere Techniken zu ihrer Ausnutzung.

Die Grundursache der beiden Race-Bugs wird in unseren Berichten dargelegt, die eigentliche Ursache kann als Vorhersagbar ist angreifbar ausgedrückt werden. Wenn der WER-Dienst temporäre Dateien verarbeitet, manipuliert er den Dateispeicherort C:\ProgramData\Microsoft\Windows\WER\Temp, ein für authentifizierte Benutzer les- und schreibbares Verzeichnis. Das bedeutet, dass ein normaler Benutzer mit mittlerer Integritätsstufe eine vom WER-Dienst erstellte Datei überschreiben und sogar in einen FileSystem-Link umwandeln kann, um andere Dateien zu beschädigen/löschen, die er sonst 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 unbelegten zufälligen Dateinamen in der Form "WER****.tmp" zu generieren.

Der zufällige Teil des Dateinamens wird mit einer 4-Byte-Hexadezimalzahl generiert, von 0000 bis FFFF; wenn eine Nummer bereits zur Erstellung einer Datei verwendet wurde, wählt die API einen anderen zufälligen Dateinamen.

Die Strategie hat eindeutig eine Schwachstelle: Wenn man 65535 Dateien mit den Namen von WER0000.tmp bis WERFFFE.tmp erstellt, wählt die API eine Zufallszahl und prüft, ob der Dateiname bereits existiert, z. B. WERA560.tmp. Sie stellt fest, dass die Datei bereits existiert, und fährt dann mit dem Test von WERA560.tmp bis WERFFFF.tmp fort. Während des Tests entsteht ein Vorbereitungsfenster, da wir einen Weg gefunden haben, WerSvc beim Aufruf von GetTempFileNameW für 4–5 Sekunden aufzuhalten, was eine ziemlich große Zeitspanne darstellt. In der Zeit zwingen wir den Dienst, eine temporäre Datei mit einem festen Dateinamen zu erstellen, und zwar WERFFFF.tmp.

Nachdem der Dienst die temporäre Datei mit dem Namen WERFFFF.tmp erstellt hat, schließt die API automatisch den von ihr gehaltenen Handle auf die Datei und gibt den Dateinamen an den Dienst für weitere Operationen an der Datei zurück. Genau hier liegt die Stelle, die den Fehler einführt. Drei Bedingungen sind erfüllt:

1. Die vom Dienst erstellte Datei befindet sich an einem vom normalen Benutzer kontrollierbaren Ort.
2. Der Dienst schließt alle Handles zur Datei.
3. Der Dienst wird die Datei später verwenden (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 Ausnutzungstechniken.

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

• Wir legen alle WER***.tmp in $pwd\1\ und erzeugen eine Junction $pwd\2\ -> $pwd\1\;
• Wir erstellen einen Prozess, der diese Funktion kontinuierlich mit dem Pfad $pwd\2\ auslöst, und einen weiteren Prozess, der kontinuierlich den Befehl SetOplock $pwd\1\WERFFFF.tmp ausführt;
• Sobald der Oplock ausgelöst wird, leiten wir $pwd\2\ -> \RPC CONTROL\ um und erstellen dann ein symbolisches Objekt \RPC CONTROL\WERFFFF.tmp -> $target und \RPC CONTROL\WERFFFF.tmp.etl -> $target
• Wir geben den Oplock frei, die Zieldatei wird mit Systemberechtigung gelöscht.

Die detaillierte Ausnutzung und der Proof-of-Concept werden in WERReport-CVE-2020-0753 bereitgestellt.

Durch Ausnutzung des Fehlers in GetTempFileNameW erhalten wir einen vorhersagbaren Ort, an dem der Dienst operieren wird; durch die Verwendung von mehrstufigen FileSystem-Junctions machen wir den Race Condition zuverlässig ausnutzbar.

In der Zwischenzeit haben wir festgestellt, dass diese Art von Race-Bug auch mögliche Dateiüberschreibungsprobleme verursachen kann, was unter bestimmten Umständen wahrscheinlich zu Elevation-of-Privilege-Fehlern führt.

Von willkürlicher Dateibeschädigung mit teilweiser Kontrolle zur Privilegienausweitung

Um zu erklären, warum eine willkürliche Dateibeschädigung (wenn man einen sehr kleinen Teil des Dateiinhalts kontrollieren kann: weniger als 63 Bytes) in eine 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. Beispielsweise entwarf @icchy von TokyoWesterns bei WCTF2019 eine Windows-CTF-Challenge namens „Gyotaku The Flag“, die diese Funktion als Orakel nutzt, um Informationen preiszugeben.

Hier nutzen wir diese Funktion von Windows Defender, um eine beliebige Datei zu löschen, wenn wir eine willkürliche Dateibeschädigung mit teilweiser Kontrolle des Dateiinhalts haben. Wir können einfach eine Malware-Signatur in eine Datei schreiben und einen Standard-Scan durch Windows Defender auslösen; die Datei wird in den Isolationsbereich von Defender verschoben, der von einem normalen Benutzer (d. h. einem Nicht-Admin-Benutzer mit mittlerer Integritätsstufe) gelöscht werden kann, indem der Scan-Vorgang einfach zweimal ausgelöst wird.

Somit kann ein Fehler zur willkürlichen Dateibeschädigung in ein beliebiges Löschen von Dateien umgewandelt werden, solange mit dem Fehler eine Malware-Signaturzeichenfolge in die Zieldatei eingefügt werden kann.

• Schritt 1: Beschädigen Sie die Zieldatei mit einem Fehler und fügen Sie eine von Windows Defender erkennbare Signaturzeichenfolge ein.
• Schritt 2: Lösen Sie einen Scan von Windows Defender für die Zieldatei aus, was zur Isolierung der Datei führt.
• Schritt 3: Lösen Sie den Scan erneut aus; die Zieldatei wird gelöscht.

Durch diese Technik erreichen wir mit Defenders Hilfe ein beliebiges Löschen von Dateien.

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

Sechs ungefixte 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. Im Rahmen unserer Forschung wurden 6 Sicherheitslücken in den geplanten Wartungsaufgaben 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 werden:

Alle 6 Fehler werden dadurch verursacht, dass der Dienst Hardlinks und Symlinks unsachgemäß behandelt, während er an Orten arbeitet, die der normale Benutzer kontrollieren kann. Bei der Ausnutzung dieser Fehler besteht eine Schwierigkeit darin, dass der Dateiname normalerweise eine PID des aktuellen Prozesses oder einen Zeitstempel enthält, der angibt, wann die Datei bearbeitet wurde. Beides kann gelöst werden, indem man einen Oplock auf eine eindeutige DLL-Datei setzt, die der Dienst zu laden versucht, wenn er zum Laufen gebracht wird. Dabei haben wir die Möglichkeit, alles zu erfahren, was wir benötigen, um den Dateinamen vorherzusagen, den der Dienst später bearbeiten wird. Ein Beispiel-POC wird im Verzeichnis FileSyncConfigTemp_hardlink bereitgestellt.

Auswirkungen der Sicherheitslücken

Alle 6 oben genannten Sicherheitslücken werden mit vollständigem Bericht und POC-Programm bereitgestellt. Obwohl die meisten Fehler in erster Linie willkürliche Dateibeschädigungen verursachen, führt diese Art von Fehler dennoch zu Systemabstürzen (durch Überschreiben kritischer Systemkonfigurationsdateien). Alle würden eine Neuinstallation von Windows erfordern. Sie erfüllen somit den Standard des Windows-System-Denial-of-Service-Fehlertyps.

Darüber hinaus kann diese Art von Fehler unter bestimmten Umständen tatsächlich eine Erhöhung von Berechtigungen (Elevation of Privilege) verursachen. Wir haben die Ausnutzungstechnik besprochen, die ein Problem des willkürlichen Überschreibens von Dateien nutzen kann, um eine primitive Operation des willkürlichen Löschens von Dateien zu erreichen. Somit ist eine Erhöhung von Berechtigungen erreichbar.

Danksagungen zu den Sicherheitslücken

Fangming Gu

Zhiniang Peng of Qihoo 360 Core Security

Zeitplan

02. Feb 2020: Sicherheitslücken gemeldet

08. Feb 2020: MSRC untersuchte und antwortete zu den 6 von uns eingereichten Fehlern in OneDrive. Ihre Schlussfolgerung war, dass sie nicht behoben werden, weil zu viel Benutzerinteraktion erforderlich / zu schwierig, 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 bekommen Sie die spezifische Datei auf dem Rechner des Benutzers? Und legen Sie jede Permutation dieser Datei in diesen Ordner? Muss es genau 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 Vorhersage des Dateinamens zu reduzieren. In der Realität muss man nur einen Oplock setzen. Dann erhält man alle {pid},{hour},{data}. 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 dürfen einen Writeup veröffentlichen.

22. Feb 2020: Details veröffentlicht

Obwohl Hardlink in Windows Insider Preview-Builds bereits korrigiert wurde, ist es in der neuesten veröffentlichten Windows-Version nicht behoben. Und es scheint keinen Plan zu geben, dies auf alle unterstützten Betriebssysteme zurückzuportieren :( . Und die Weigerung, diese Sicherheitslücken zu beheben, wirkt nicht wie eine verantwortungsvolle Handlung.