alfarom256/cve-2022-45451PoC für Acronis Arbitrary File Read - CVE-2022-45451
Der Anti-Malware-Scanner-Treiber „ngscan" von Acronis leidet unter einer falschen/unsachgemäßen Zugriffskontrolle, die auf den Filter-Kommunikationsport angewendet wird. Der Minifilter-Treiber unterstützt die folgenden Funktionen, die ausgenutzt werden können:
Die Analyse des Treibers ngscan.sys begann mit der Dekompilierung des Treibers mit Ida Pro. Dem Forscher fiel auf, dass zwar ein Device-Objekt erstellt wurde, aber keine Symlinks erstellt wurden, um über DeviceIoControl mit dem Treiber zu interagieren.
Daher wurde die Analyse fortgesetzt, indem die Fähigkeiten des Filter-Kommunikationsports beobachtet wurden.
Während der Initialisierung erstellt der Treiber fünf (5) Kommunikationsports, um die Interaktion mit anderen Prozessen zu unterstützen.
Abb. 1: Routine, die die Erstellung von bis zu fünf (5) Filter-Kommunikationsports (FCP) unterstützt
Es wurde beobachtet, dass diese Funktion aufgerufen wird und jeden der 5 FCPs mit einem Standard-DACL initialisiert, wobei der letzte FCP mit einem NULL-DACL erstellt wird.
Abb. 2: FCP-Erstellung mit Standard-/NULL-DACL
Die Analyse wurde fortgesetzt, indem die vom Filtertreiber angegebenen CreateNotifyCallback- und MessageNotifyCallback-Funktionen beobachtet wurden. Diese Callback-Funktionen werden immer dann aufgerufen, wenn ein Prozess eine Verbindung öffnet und eine Nachricht an den Kommunikationsport sendet.
Die erste Untersuchung des MessageNotifyCallback zeigte, dass der Puffer der eingehenden Nachricht die folgenden Anforderungen erfüllen muss:
Sobald die Prüfungen bestanden sind, wird eine Funktionsnummer aus dem InputBuffer geparst und in den folgenden switch-Fällen verwendet, um auszuwählen, welche Funktion mit der bereitgestellten Eingabe ausgeführt werden soll.
Abb. 3: Teilmenge der vom MessageNotifyCallback unterstützten Funktionen
Die Untersuchung jeder der unterstützten Funktionen zeigte zwei Funktionen, die für einen möglichen Missbrauch hin zu beliebigem Dateilesen von Interesse sind.
Abb. 4: Funktionen, die das Erstellen eines Scan-Kontexts und die Rückgabe des Dateihandles des Scan-Kontexts unterstützen (Zeilen 206, 233)
Obwohl die genaue Funktionalität eines „Scan-Kontexts" nicht vollständig bekannt ist, zeigte die Analyse, dass für jede im Benutzer-InputBuffer angegebene Datei ein Datei-Scan-Kontext erstellt werden kann. Sobald ein Scan-Kontext erstellt wurde, wird die Scan-Kontext-ID über den Ausgabepuffer an den Benutzer zurückgegeben.
Abb. 5: Routine zum Erstellen eines Scan-Kontexts, die die Scan-Kontextdaten an den Benutzer zurückgibt
Abb. 6: Daten, die an den Minifilter-Treiber gesendet werden und Zugriff auf die geschützte SAM-Registrierungsdatei anfordern (\??\C:\Windows\System32\config\SAM)
Abb. 7: Antwort vom Minifilter-Treiber einschließlich Scan-Kontext-ID (0x3aaf)
Sobald ein Scan-Kontext erstellt und die ID abgerufen wurde, kann ein Handle auf die Datei, für die der Scan-Kontext erstellt wurde, in der anfordernden Anwendung geöffnet werden, indem erneut eine Nachricht an den Kommunikationsport gesendet wird.
Abb. 8: Abruf des Dateihandles des erstellten Scan-Kontexts
Die Funktion mit der Bezeichnung CreateFileReturnHandle0 wurde nur aufgerufen, wenn die vorherige Funktion SearchScanContextsByID einen gültigen Scan-Kontext zurückgab.
Z. B. nur, wenn der anfordernde Prozess eine gültige Kontext-ID bereitstellte, die zuvor durch Aufruf der oben genannten Scan-Erstellungsfunktion erzeugt wurde.
Das anfordernde Programm öffnete erfolgreich ein Handle auf die privilegierte Datei, indem es die Scan-Kontext-ID an die in Abbildung 8 (Abbildung 4, Zeile 233) angegebene Funktion übergab.
Abb. 9: Erfolgreicher Abruf des Dateihandles für die SAM-Datei
Mit processhacker wurde der Zugriff auf das Dateihandle bestätigt, indem die Handles des anfordernden Prozesses angezeigt wurden:
Abb. 10: Prozess, der ein Handle auf die SAM-Datei enthält
Abb. 11: Lesezugriff auf das erhaltene Handle gewährt
Die weitere Untersuchung der unterstützten Funktionen zeigte die Kontrolle über drei Registrierungsschlüssel, die möglicherweise genutzt werden können, um Codeausführung zu erlangen.
Abb. 12: Funktionen, die das Öffnen von Handles auf Registrierungsschlüssel unterstützen
Abb. 13: Öffnen der Registrierungsschlüssel, die die Hook-Monitor-DLL angeben, die in einen Prozess injiziert werden soll
Abb. 14: OpenKey-Funktion, die die Möglichkeit demonstriert, einen Registrierungsschlüssel mit benutzerkontrollierten Daten zu ändern
Die Umstände für die DLL-Injektion zum Hooking durch die Acronis-Suite wurden nicht ermittelt. Es wird jedoch angenommen, dass bei aktiviertem Hook-Monitoring die durch die Registrierungsschlüssel x64HookLib und x86HookLib angegebene DLL in einen bestimmten Prozess injiziert würde.
Abb. 15: x64HookLibKey mit der Hooking-DLL C:\ProgramData\Acronis\NGMP\shared\acr_protect.x64.dll
Der Vorgang des Öffnens eines Scan-Kontexts wurde in der Analyse für das beliebige Dateilesen ausgelassen.
Ein Prozess kann anstatt einen Scan-Kontext zu erstellen, Scan-Kontext-IDs per Brute-Force ermitteln, indem er wiederholt Anfragen an die Funktion GetScanContextByID sendet und dabei ContextID-Werte durchläuft, bis ein oder mehrere gültige Scan-Kontexte gefunden werden.
