Qualitätsmaßstäbe für Berichte zum Microsoft-Bug-Bounty-Programm

Microsoft möchte gemeldete Sicherheitsrisiken so schnell wie möglich beheben. Einer der Faktoren, die sich darauf auswirken, wie schnell ein Sicherheitsrisiko behoben wird, ist die Zeit, die für die Bewertung der Grundursache, des Schweregrads und der Auswirkung des Sicherheitsrisikos anfällt. In der Praxis wird die Zeit, die Microsoft zur Bewertung eines Sicherheitsrisikos aufwenden muss, erheblich durch die Qualität der Informationen des Berichts zum Sicherheitsrisiko beeinflusst.

Damit unsere Sicherheitsexperten die Informationen besser deuten können, müssen wir die Bewertung eines Sicherheitsrisikos beschleunigen. Wir haben drei Qualitätsstufen für Berichte zu Sicherheitsrisiken definiert: Niedrig, Mittel und Hoch. Diese Qualitätsstufen werden in der folgenden Tabelle zusammengefasst. Wir möchten allen Benutzern raten, nach Möglichkeit hochwertige Berichte einzureichen. Unser Bug-Bounty-Programm spornt durch bessere Belohnungen für hochwertigere Berichte zusätzlich dazu an.

Obwohl wir hochwertige Berichte bevorzugen, möchten wir natürlich immer über Sicherheitsrisiken informiert werden, die sich auf Microsoft-Produkte auswirken. Deshalb möchten wir unsere Benutzer bitten, Sicherheitsrisiken auch dann zu melden, wenn sie keinen Bericht höchster Qualität erstellen können.

 

Qualität

Beschreibung

Erforderliche Informationen

Niedrig

Ein Sicherheitsrisikobericht mit niedriger Qualität enthält ausreichend Informationen, um das Sicherheitsrisiko zu reproduzieren, aber keinen zuverlässigen Proof of Concept.

  • Art des Sicherheitsrisikos
  • Betroffene Komponente (Name, Version)
  • Betroffene Zielumgebung (Art, Version)
  • Ausgabe der Reproduktion des Sicherheitsrisikos (Debuggerausgabe, Screenshots usw.)
  • Proof of Concept

Mittel

Ein Sicherheitsrisikobericht mit mittlerer Qualität enthält im Gegensatz zu einem Bericht niedriger Qualität einen zuverlässigen und minimierten Proof of Concept.

  • Alle Informationen, die für einen Bericht niedriger Qualität erforderlich sind
  • Zuverlässiger und minimierter Proof of Concept

Hoch

Ein Sicherheitsrisikobericht mit hoher Qualität enthält im Gegensatz zu einem Bericht mittlerer Qualität eine ausführliche und korrekte Analyse des Sicherheitsrisikos.

  • Alle Informationen, die für einen Bericht mittlerer Qualität erforderlich sind
  • Ausführliche und korrekte Analyse
Explanation of information required

Informationen

Erläuterung

Art des Sicherheitsrisikos

Eine Klassifizierung der Art des gemeldeten Sicherheitsrisikos, wie z. B. Use-after-free oder Cross-Site-Scripting. Beispiele für diese Sicherheitsrisiken finden Sie unter https://nvd.nist.gov/vuln/categories.

Betroffene Komponente

Die Komponente oder der Dienst, auf die bzw. den sich das Sicherheitsrisiko auswirkt. Hier sollten Sie den Namen der Komponente und sämtliche relevanten Versionsinformationen angeben.

Betroffene Zielumgebung

Die Zielumgebung, auf die sich das Sicherheitsrisiko auswirkt (z. B. das betroffene Betriebssystem oder die betroffene Anwendung). Hier sollten Sie eine Beschreibung der Zielumgebung angeben, die den Namen und sämtliche relevanten Versionsinformationen enthält.

 

Für Windows-Ziele sollte die Zeichenfolge BuildLabEx enthalten sein, die Sie hier finden:

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx

Ausgabe der Reproduktion des Sicherheitsrisikos

Die Ausgabe einer erfolgreichen Reproduktion des Sicherheitsrisikos. Diese kann beispielsweise aus einer Debuggerausgabe, einem Screenshot, einem Video oder einem anderen Format bestehen, das die Reproduktion des Fehlers veranschaulicht. Ausführlichere Informationen wie eine Debuggerausgabe werden dabei bevorzugt.

Proof of Concept

Eine Beschreibung des Sicherheitsrisikos in Form von Text, Code oder in einem entsprechenden anderen Format (je nach Art des Sicherheitsrisikos). Diese Beschreibung sollte alle Schritte enthalten, die erforderlich sind, um das Sicherheitsrisiko auszulösen. Auch sämtliche Informationen dazu, wie das Ziel konfiguriert werden muss, um das Sicherheitsrisiko auszulösen, sollten enthalten sein.

Zuverlässiger und minimierter Proof of Concept

Ein Proof of Concept, der das Sicherheitsrisiko beispielsweise durch Code automatisch reproduziert (falls vorhanden). Dieser Proof of Concept sollte folgende Kriterien erfüllen:

 

  • Er sollte ohne oder mit minimalen Systemänderungen funktionieren.
  • Er sollte minimiert sein, also keine überflüssigen oder unerheblichen Informationen enthalten.
  • Er sollte zuverlässig und schnell reproduziert werden können.

Ausführliche und korrekte Analyse

In dieser Analyse sollte korrekt beschrieben werden, wie jeder Faktor des Proof of Concept sich auf die Auslösung des Sicherheitsrisikos im Ziel auswirkt. Darüber hinaus sollte die Analyse Informationen zum Timing, der Umgebung und anderen Einschränkungen enthalten, die sich auf das erfolgreiche Auslösen des Sicherheitsrisikos auswirken. Auch die Grundursache des Sicherheitsrisikos sollte so gut wie möglich in der Analyse beschrieben werden.

Beispiel für einen hochwertigen Bericht

Fenster:
Risikovermeidungstechnik für die Erstellung von Bereitstellungsanalysepunkten in einer Sandbox
Plattform:
Windows 10 (Build 10240), frühere Versionen enthalten die notwendigen Funktionen nicht
Art:
Umgehung einer Sicherheitsfunktion
Bug-Bounty-Programm:
Bug-Bounty-Programm zur Risikovermeidung
Zusammenfassung:
Eine Risikominderung wurde zu Windows 10 hinzugefügt, um zu verhindern, dass NTFS-Bereitstellungsanalysepunkte umgangen werden können, die auf einer Integritätsebene unter „Mittel“ erstellt wurden.
Beschreibung:
In Windows 10 wurden neue Risikominderungen hinzugefügt, um die Erstellung oder das Verhalten bestimmter symbolischer Links zu ändern, wenn diese von einem Sandboxprozess oder einem Prozess mit niedriger Integrität aufgerufen werden. Dadurch sollen diese Tricks zum Verlassen einer Sandbox schwerer missbraucht werden können.
 
In früheren Windows 10-Builds wurden NTFS-Bereitstellungsanalysepunkte aus einem Sandboxprozess direkt ausgeschlossen. In Build 10240 (ein finaler Build) wurde die Überprüfung jedoch in IopXXXControlFile in den Kernel verschoben und geringfügig verändert, sodass Sandboxprozesse einige Bereitstellungspunkte erstellen können. Die Überprüfung erfolgt etwa folgendermaßen:
 
if (RtlIsSandboxedProcess()) { 
   if(ControlCode == FSCTL_SET_MOUNT_POINT) { 
       if (FsRtlValidateReparsePointBuffer(buffer) && buffer->ReparseTag == TAG_MOUNT_POINT) { 
         NTSTATUS status = ZwOpenFile(..., buffer->ReparseTarget, FILE_GENERIC_WRITE, ... , FILE_DIRECTORY_FILE); 
        if (!NT_SUCCESS(status)) { 
         return status; 
       } 
   } 
}
 
Der Kernel prüft daher, ob das Ziel des Bereitstellungspunkts ein Verzeichnis ist und ob der aktuelle Prozess Schreibzugriff auf das Verzeichnis hat. Dadurch wird die Fähigkeit eines Sandboxprozesses, diese Methode für Schreibvorgänge in Dateien mit erhöhter Berechtigung einzusetzen, ausreichend eingeschränkt. Leider liegt bei dieser Überprüfung ein möglicherweise unerwartetes Problem vor, denn der Sandboxprozess kann den Aufruf „ZwOpenFile“ beliebig an eine Komponente umleiten, die diese für Schreibvorgänge öffnen kann. Der ursprüngliche Wert wird jedoch als Bereitstellungspunkt festgelegt. Das liegt daran, dass die Überprüfung für das Öffnen von Dateien innerhalb des Prozesses vorgenommen wird, der den Aufruf ausführt. Das bedeutet, dass die Gerätezuordnung des Benutzers berücksichtigt wird.
 
Der Sandboxprozess kann zwar nicht die Gerätezuordnung pro Benutzer ändern, aber die Gerätezuordnung des Prozesses, indem NtSetInformationProcess mit der ProcessDeviceMap-Informationsklasse eingesetzt wird. Da beliebige Objektverzeichnisse und symbolische Verknüpfungen (für diese sind auch Risikominderungen verfügbar, die lediglich verhindern, dass ein Prozess mit erhöhten Rechten diesen folgt – dies ist aktuell jedoch nicht relevant) erstellt werden können, können auch gefälschte Gerätezuordnungen erstellt werden, die den Öffnungsvorgang in ein anderes Verzeichnis umleiten. Ein Pfad wie \Device\NamedPipe\ (beachten Sie den nachstehenden Schrägstrich) ist ein gutes Ziel, da dieser mit jeder Berechtigungsstufe (einschließlich dem Chrome-Rendererprozess) für Schreibzugriff und als Verzeichnis geöffnet werden kann. Wenn wir also einen beliebigen Bereitstellungspunkt für \??\c:\irgendwo festlegen möchten, können wir beispielsweise Folgendes schreiben:
 
<UNNAMED>(DIR) -> C:(DIR) -> irgendwo(LINK to \Device\NamedPipe\)
 
Wenn das unbenannte Verzeichnis auf die Prozessgerätezuordnung festgelegt wird, können wir die Überprüfung umgehen und den Bereitstellungspunkt erstellen.
 
Aus einer festen Perspektive heraus könnte man den geöffneten Pfad abfragen und diesen verwenden, um in den NTFS-Analysepunkt zu schreiben, anstatt den ursprünglichen Wert zu verwenden.
 
Proof of Concept:
Mit diesem Proof of Concept wird die Umgehung veranschaulicht. Er sollte mit geringer Integrität mithilfe von PsExec oder durch Ändern der Zugriffssteuerungsliste der ausführbare Datei in „Niedrig“ ausgeführt werden. Stellen Sie sicher, dass Sie die richtige Version für die Architektur unter Windows verwenden, da ein Fehler in NtSetInformationProcess vorliegt, der dazu führt, dass WOW64-Apps die Prozessgerätezuordnung festlegen. Dieser Vorgang ist mit dem mklink-Tool der Befehlsshell vergleichbar, mit dem das Erstellen des Bereitstellungspunkt mit niedriger Integrität fehlschlägt. Führen Sie die folgenden Schritte aus:
 
1. Extrahieren Sie den Proof of Concept an einen Speicherort auf der lokalen Festplatte, für den normale Benutzer Schreibzugriff haben.
 
2. Führen Sie die ausführbare Datei für den Proof of Concept mit niedriger Integrität aus, sodass zwei Argumente übergeben werden: der Pfad zu einem Verzeichnis, das erstellt werden soll (an einem Ort wie AppData\Temp\Low, für den Benutzer mit niedriger Integrität Schreibzugriff haben), und der beliebige Dateipfad, auf den der Bereitstellungspunkt festgelegt werden soll. Beispiel:

poc.exe c:\users\user\appdata\local\low\abc c:\notreal.
 
Erwartetes Ergebnis:
Es sollte nicht möglich sein, einen Bereitstellungspunkt zu erstellen, der auf einen Speicherort zeigt, für den Benutzer mit niedriger Integrität keinen Schreibzugriff haben.
 
Beobachtetes Ergebnis:
Der Bereitstellungspunkt wurde erfolgreich erstellt.
 
Besonderer Dank geht an James Forshaw für seine stetigen und hochwertigen Beiträge zum Microsoft Security Response Center.
 
 

Beispiel für einen minderwertigen Bericht

 

# win32kfull!NtGdiHLSurfGetInformation+0x11f kernelinfo verlust 

## grundursache 
die lokale Kernelstackvariable KernerStackStuctVar ist nicht initialisiert. 
und nach dem Aufruf von _GreSfmGetDirtyRgn@40 direkt in Benutzermodus kopieren. 
```cpp 
.text:0008718A ; int __stdcall NtGdiHLSurfGetInformation(int, int, void *, int) 
.text:0008718A public _NtGdiHLSurfGetInformation@16 
.text:0008718A _NtGdiHLSurfGetInformation@16 proc near 
.text:0008718A 
.text:0008718A KernerStackStuctVar = dword ptr -58h 
``` 
```cpp 
.text:0008729E push edi ; size_t 
.text:0008729F lea ecx, [ebp+KernerStackStuctVar] 
.text:000872A2 push ecx ; void * 
.text:000872A3 push eax ; void * 
.text:000872A4 call _memcpy ; xxxx 
``` 
```cpp 
"t": "ob", 
"v": { 
"pid": { 
"t": "nb", 
"v": 1044 
}, 
"tid": { 
"t": "nb", 
"v": 1108 
}, 
"imageName": { 
"t": "st", 
"v": "dwm.exe" 
}, 
"count": { 
"t": "nb", 
"v": 2 
}, 
"from": { 
"t": "st", 
"v": "NtGdiHLSurfGetInformation" 
}, 
"eip": { 
"t": "st", 
"v": "nt!memcpy+0x33" 
}, 
"data": { 
"t": "ob", 
"v": { 
"value": { 
"t": "n4", 
"s": false, 
"v": "0xaaaaaaaa" 
}, 
"type": { 
"t": "nu" 
} 
} 
}, 
"address": { 
"t": "n4", 
"s": false, 
"v": "0x36ef25c" 
}, 
"stacks": { 
"t": "ar", 
"v": [ 
{ 
"t": "st", 
"v": "win32kfull!NtGdiHLSurfGetInformation+0x11f" 
}, 
{ 
"t": "st", 
"v": "nt!KiSystemServicePostCall" 
}, 
{ 
"t": "nu" 
}, 
{ 
"t": "nu" 
} 
```