vu-ls/crassusWindows Privilege Escalation Discovery Tool, das Process Monitor-Bootlogs parst, um DLL-Hijacking, schwache ACLs und andere Erhöhungspfade zu identifizieren und automatisch Proxy-DLL-Quellcode generiert.
Enable Boot Logging aus.
raw.PML.Strg-R zurück.boot.PML.Crassus.exe boot.PML aus.results.csv.Accenture hat ein Tool namens Spartacus entwickelt, das DLL-Hijacking-Möglichkeiten unter Windows findet. Ausgehend von Spartacus haben wir Crassus entwickelt, um die Fähigkeiten zur Erkennung von Windows-Privilege-Escalation über die bloße Suche nach fehlenden Dateien hinaus zu erweitern. Die ACLs, die von Dateien und Verzeichnissen privilegierter Prozesse verwendet werden, können mehr als nur die Suche nach fehlenden Dateien umfassen, um das Ziel zu erreichen.
...aber mit einer Besonderheit, da Crassus den SysInternals Process Monitor nutzt und rohe PML-Protokolldateien parst. Die typische Verwendung besteht darin, ein Boot-Protokoll mit Process Monitor zu generieren und es dann mit Crassus zu parsen. Es wird außerdem automatisch Quellcode für Proxy-DLLs mit allen relevanten Exporten für anfällige DLLs generieren.
version.dll ist, erstellt Crassus für Sie Dateien version.cpp und version.def mit allen darin enthaltenen Exporten. Standardmäßig starten die Proxy-DLLs calc.exe. Es sind Build-Skripte enthalten, um die DLLs in Visual Studio oder MinGW zu erstellen.Die allgemeine Funktionsweise von Crassus lässt sich in diesem Flussdiagramm zusammenfassen:
Crassus wurde als Visual Studio 2019-Projekt entwickelt. So erstellen Sie Crassus.exe:
Crassus.slnStrg+Umschalt+B auf Ihrer TastaturWenn Sie dem Ausführen von fremdem Code vertrauen, ohne zu wissen, was er tut, wird Crassus.exe in diesem Repository bereitgestellt.
Enable Boot Logging aus.
Strg-R zurück.boot.PML. Der Grund für das erneute Speichern der Protokolldatei ist zweierlei:
| Argument | Beschreibung |
|---|---|
<PMLFILE> | Speicherort (Datei) der vorhandenen ProcMon-Ereignisprotokolldatei. |
--verbose | Ausführliche Ausgabe aktivieren. |
--debug | Debug-Ausgabe aktivieren. |
Analysieren Sie das in boot.PML gespeicherte Process Monitor-Boot-Protokoll. Alle anfälligen Pfade werden als results.csv und alle Proxy-DLL-Quelldateien im Unterverzeichnis stubs gespeichert.
C:\tmp> Crassus.exe boot.PML
Nachfolgend finden Sie die Vorlage, die beim Generieren von Proxy-DLLs verwendet wird. Bei DLLs, die von Crassus gefunden werden, enthält die Proxy-DLL dieselben Exportnamen, die in %_EXPORTS_% angegeben sind, sowie dieselben Ordnungszahlen, die in der .def-Datei angegeben sind. Crassus erkennt, ob die DLL als 32-Bit-Bibliothek oder als 64-Bit-Bibliothek erstellt werden muss, indem es die Architektur des übergeordneten Prozesses prüft und den Quellcode im Feld %_BUILD_AS_% entsprechend kennzeichnet.
Wenn die echte DLL nicht mit dem Process Monitor-Protokoll gefunden werden kann oder der Exportname problematisch ist, greifen die Build-Skripte auf die Erstellung einer DLL ohne angegebene Exporte zurück.
#pragma once
//%_BUILD_AS%
#include <windows.h>;
extern "C" {
VOID Payload() {
// Run your payload here.
WinExec("calc.exe", 1);
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
Payload();
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
#ifdef ADD_EXPORTS
%_EXPORTS_%
#endif
}
Für Anwendungen, die den Wert der OPENSSLDIR-Variable unsicher verwenden, kann eine manipulierte openssl.cnf-Datei am angegebenen Ort abgelegt werden. In diesem Beispiel lädt die Software C:\tmp\calc.dll. Stellen Sie sicher, dass Sie eine 32-Bit-Bibliothek für 32-Bit-Prozesse und eine 64-Bit-Bibliothek für 64-Bit-Prozesse verwenden.
[openssl_init]
# This will attempt to load the file c:\tmp\calc.dll as part of OpenSSL initialization
# Build scripts should detect whether the calc.dll library needs to be built as 32-bit or 64-bit
/tmp/calc = asdf
Die Kompilierung ist mit der in Visual Studio enthaltenen cl.exe-Binärdatei möglich. Insbesondere:
cl.exe /DADD_EXPORTS /D_USRDLL /D_WINDLL <target>.cpp /LD /Fe<target>.dll /link /DEF:<target>.def
Um den Build-Prozess zu automatisieren, einschließlich der Angabe, ob die Bibliothek 64-Bit oder 32-Bit sein soll:
build.bat..dll endet.Hinweis: Aufgrund eines ungünstigen Verhaltens von vcvarsall.bat, das definitiv kein Fehler ist, können Sie auf Probleme stoßen, wenn Sie versuchen, build.bat mehrmals in derselben Visual Studio Developer-Eingabeaufforderungssitzung auszuführen. Wenn ein Fehler auftritt, schließen Sie das Fenster einfach und starten Sie es erneut.
Wenn Visual Studio nicht ohne weiteres verfügbar ist, können Proxy-DLLs stattdessen mit MinGW-w64 kompiliert werden. Auf einer Ubuntu-Plattform kann MinGW beispielsweise wie folgt installiert werden: sudo apt install g++-mingw-w64-x86-64-win32 g++-mingw-w64-i686-win32
# Create a 32-bit DLL
i686-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
i686-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows
# Create a 64-bit DLL
x86_64-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
x86_64-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows
Um den Build-Prozess zu automatisieren, einschließlich der Angabe, ob die Bibliothek 64-Bit oder 32-Bit sein soll:
bash ./build.sh aus..dll endet.Wie in VU#114757 beschrieben, enthalten ältere Acronis-Software mehrere Privilege-Escalation-Schwachstellen.
openssl.cnf an einem von nicht privilegierten Benutzern erstellbaren Ort.C:\ProgramData\Acronis.Crassus findet beide Probleme automatisch.
Indem wir unsere kompilierte curl.dll-Datei im Verzeichnis C:\ProgramData\Acronis\Agent\var\atp-downloader\ platzieren und mit einem neuen Process Monitor-Boot-Protokoll neu starten, können wir sehen, dass unsere Nutzlast, die calc.exe ausführt, mit SYSTEM-Berechtigungen läuft.
Die anfällige Acronis-Software versucht, openssl.cnf von zwei verschiedenen Orten zu laden. Wir platzieren unsere Vorlagendatei openssl.cnf in c:\jenkins_agent\workspace\tp-openssl-win-vs2013\17\product\out\standard\vs_2013_release\openssl\ssl und eine 32-Bit-Nutzlast calc.dll in c:\tmp.
Wie in VU#240785 beschrieben, ist ältere Atlassian Bitbucket-Software aufgrund schwacher ACLs des Installationsverzeichnisses anfällig für Privilege Escalation. Wie bei jeder Windows-Software, die an einem anderen Ort als C:\Program Files\ oder anderen ACL-beschränkten Orten installiert wird, liegt es am Software-Installer, explizit ACLs für das Zielverzeichnis festzulegen.
Crassus findet viele Möglichkeiten, mit dieser Software Privilege Escalation zu erreichen, darunter:
In der Crassus-Ausgabe sehen wir, dass c:\atlassian\bitbucket\7.9.1\elasticsearch\bin\elasticsearch-service-x64.exe privilegiert ist, aber da es läuft, können wir es nicht einfach ersetzen. Wir können jedoch einen anderen Trick anwenden, um es zu kapern. Wir können einfach das Verzeichnis umbenennen, in dem es sich befindet, ein neues Verzeichnis mit demselben Namen erstellen und unsere Nutzlast dort unter demselben Namen platzieren.
Sobald wir mit einem Process Monitor-Boot-Protokoll neu starten, sehen wir, dass unsere platzierte Datei elasticsearch-service-x64.exe anstelle der echten ausgeführt wird, basierend auf dem Windows-Rechner-Symbol.
Wie in VU#287178 beschrieben, sind ältere Versionen der McAfee-Software anfällig für Privilege Escalation über openssl.cnf. Werfen wir einen Blick darauf:
Um zu sehen, warum es in diesem Boot-Protokoll zwei verschiedene Referenzen auf openssl.cnf gibt, können wir die Datei results.csv betrachten:
Beachten Sie, dass das Laden der openssl.cnf-Datei aus dem Pfad D:\ eine weitere manuelle Untersuchung erfordert, da die Machbarkeit des Ladens eines solchen Pfads von der jeweiligen Plattform und dem verfügbaren Zugriff auf das System abhängt. Es könnte möglich sein, eine optische Disk zu erstellen, die eine openssl.cnf-Datei bereitstellt, die ebenfalls auf einen Pfad verweist, der auf das optische Laufwerk aufgelöst wird.
SQL Server 2022 ist offensichtlich nicht anfällig für Privilege Escalation aufgrund schwacher ACLs, es sei denn, es wird an einem nicht standardmäßigen Ort installiert. Wenn es an einem Ort außerhalb von C:\Program Files installiert wird, deckt Crassus mehrere Möglichkeiten für Privilege Escalation auf. Die meisten Windows-Anwendungen, die eine privilegierte Komponente enthalten, scheinen auf diese Weise ausnutzbar zu sein, wenn sie in einem Verzeichnis installiert werden, das nicht bereits von Natur aus sichere ACLs aufweist.
Wenn Crassus das privilegierte Laden einer Datei meldet, die ein Benutzer platzieren oder ändern kann, bedeutet das nicht unbedingt, dass es sich um ein ausnutzbares Szenario handelt. Während Crassus nach potenziell interessanten Dateitypen sucht, gibt eine Process Monitor-Protokolldatei nicht direkt an, was der zugehörige Prozess mit der Datei getan hätte, wenn sie vorhanden gewesen wäre. Es könnte so einfach sein wie das Extrahieren eines Programmsymbols. Die Untersuchung des Aufrufstapels des Dateivorgangs in Process Monitor kann einen Hinweis darauf geben, was getan worden wäre. Oder platzieren Sie die Datei einfach und untersuchen Sie das Verhalten mit einem neuen Process Monitor-Boot-Protokoll, wenn Sie den einfacheren Brute-Force-Weg bevorzugen. Sie können auch auf eine fehlende Bibliothek stoßen, bei der Crassus entweder die Bibliothek nicht finden kann, um zu wissen, welche Exporte vorhanden sein sollten, oder dass die von Crassus gefundenen Exporte in einer Weise kollidieren, die eine ordnungsgemäße DLL-Kompilierung verhindert. In solchen Fällen greift Crassus auf die Erstellung einer DLL zurück, die keine Funktionsnamen exportiert. Abhängig davon, wie die Zielanwendung die Bibliothek lädt, kann das Fehlen erwarteter Funktionsnamen und/oder Ordnungszahlen verhindern, dass die Zielanwendung die Bibliothek erfolgreich lädt. Dieses Szenario erfordert manuellen Aufwand, um zu bestimmen, wie die Proxy-DLL aussehen sollte.
Crassus sucht nach privilegierten Dateivorgängen, um interessante Pfade zu entdecken. Sie können auf ein Szenario stoßen, in dem sowohl ein privilegierter als auch ein nicht privilegierter Prozess auf einen Pfad zugreifen, aber nur der nicht privilegierte Prozess die Ausführung dessen durchführt, was vorhanden sein könnte. Alternativ können Sie auf ein Szenario stoßen, in dem ein übergeordneter Prozess zwar mit Berechtigungen ausgeführt wird, aber explizit untergeordnete Prozesse mit niedrigeren Berechtigungen erzeugt.
Insbesondere bei der erstmaligen Installation von Software oder bei der Installation von Updates protokolliert Process Monitor möglicherweise einen Dateivorgang, der ausnutzbar erscheint, aber nicht bei jedem Systemstart auftritt. Das Ausnutzen dieser Vorgänge ist möglicherweise beim ersten Neustart nach einem solchen Ereignis möglich. Um solche Randfälle zu vermeiden, vergewissern Sie sich, dass nachfolgende Boot-Protokolle dieselben gemeldeten Dateivorgänge bei späteren Neustarts enthalten.
Ob es sich um einen Tippfehler, einen Fehler oder eine neue Funktion handelt, Crassus ist offen für Beiträge, solange wir uns auf Folgendes einigen: