vu-ls/crassusStrumento di scoperta per escalation dei privilegi su Windows che analizza i log di boot di Process Monitor per identificare DLL hijacking, ACL deboli e altri percorsi di elevazione, generando automaticamente il codice sorgente di proxy DLL.
Enable Boot Logging.
raw.PML.Ctrl-R.boot.PML.Crassus.exe boot.PML.results.csv.Accenture ha creato uno strumento chiamato Spartacus, che trova opportunità di DLL hijacking su Windows. Utilizzando Spartacus come punto di partenza, abbiamo creato Crassus per estendere le capacità di scoperta di escalation dei privilegi su Windows oltre la semplice ricerca di file mancanti. Gli ACL utilizzati da file e directory di processi privilegiati possono trovare più della semplice ricerca di file mancanti per raggiungere l'obiettivo.
...ma con un twist: Crassus utilizza il SysInternals Process Monitor e analizza file di log PML grezzi. L'uso tipico è generare un log di avvio usando Process Monitor e poi analizzarlo con Crassus. Genererà anche automaticamente il codice sorgente per DLL proxy con tutti gli export rilevanti per DLL vulnerabili.
version.dll, Crassus creerà i file version.cpp e version.def con tutti gli export inclusi. Per impostazione predefinita, le DLL proxy avvieranno calc.exe. Sono inclusi script di build per compilare le DLL su Visual Studio o MinGW.Il succo generale di come funziona Crassus può essere riassunto in questo diagramma di flusso:
Crassus è stato sviluppato come progetto Visual Studio 2019. Per compilare Crassus.exe:
Crassus.slnCtrl+Shift+B sulla tastieraSe ti fidi di eseguire codice di altri senza sapere cosa fa, Crassus.exe è fornito in questo repository.
Enable Boot Logging.
Ctrl-R.boot.PML. Il motivo per salvare di nuovo il file di log è duplice:
| Argomento | Descrizione |
|---|---|
<PMLFILE> | Percorso (file) del file di log eventi ProcMon esistente. |
--verbose | Abilita output dettagliato. |
--debug | Abilita output di debug. |
Analizza il log di avvio di Process Monitor salvato in boot.PML. Tutti i percorsi vulnerabili verranno salvati come results.csv e tutti i file sorgente delle DLL proxy nella sottodirectory stubs.
C:\tmp> Crassus.exe boot.PML
Di seguito è riportato il template utilizzato per generare le DLL proxy. Per le DLL trovate da Crassus, la DLL proxy conterrà gli stessi nomi di export specificati in %_EXPORTS_%, così come gli stessi ordinali specificati nel file .def. Crassus rileverà se la DLL deve essere compilata come libreria a 32 bit o a 64 bit esaminando l'architettura del processo padre e contrassegnando il codice sorgente nel campo %_BUILD_AS_% di conseguenza.
Se la DLL reale non può essere trovata utilizzando il log di Process Monitor, o se il nome dell'export è problematico, gli script di build ripiegheranno sulla creazione di una DLL senza export specificati.
#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
}
Per le applicazioni che utilizzano in modo non sicuro il valore della variabile OPENSSLDIR, un file openssl.cnf modificato può essere posizionato nel percorso indicato. Per questo esempio, il software caricherà C:\tmp\calc.dll. Assicurati di utilizzare una libreria a 32 bit per i processi a 32 bit e una libreria a 64 bit per i processi a 64 bit.
[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
La compilazione è possibile utilizzando il binario cl.exe incluso in Visual Studio. Nello specifico:
cl.exe /DADD_EXPORTS /D_USRDLL /D_WINDLL <target>.cpp /LD /Fe<target>.dll /link /DEF:<target>.def
Per automatizzare il processo di compilazione, inclusa la specifica se la libreria deve essere a 64 bit o a 32 bit:
build.bat..dll.Nota: A causa di un comportamento sfortunato di vcvarsall.bat, che non è sicuramente un bug, potresti incontrare problemi nel tentativo di eseguire build.bat più di una volta nella stessa sessione del Prompt dei comandi per sviluppatori di Visual Studio. Se incontri un errore, chiudi semplicemente la finestra e avvia di nuovo.
Se Visual Studio non è prontamente disponibile, le DLL proxy possono essere compilate con MinGW-w64 invece. Su una piattaforma Ubuntu, ad esempio, MinGW può essere installato con: 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
Per automatizzare il processo di compilazione, inclusa la specifica se la libreria deve essere a 64 bit o a 32 bit:
bash ./build.sh.dll.Come descritto in VU#114757, il vecchio software Acronis contiene molteplici vulnerabilità di escalation dei privilegi.
openssl.cnf in un percorso creabile da un utente non privilegiato.C:\ProgramData\Acronis.Crassus trova automaticamente entrambi questi problemi.
Posizionando il nostro file curl.dll compilato nella directory C:\ProgramData\Acronis\Agent\var\atp-downloader\ e riavviando con un nuovo log di avvio di Process Monitor, possiamo vedere che il nostro payload che esegue calc.exe viene eseguito con privilegi SYSTEM.
Il software Acronis vulnerabile tenta di caricare openssl.cnf da due diverse posizioni. Posizioneremo il nostro file template openssl.cnf in c:\jenkins_agent\workspace\tp-openssl-win-vs2013\17\product\out\standard\vs_2013_release\openssl\ssl, e un payload calc.dll a 32 bit in c:\tmp.
Come descritto in VU#240785, il vecchio software Atlassian Bitbucket è vulnerabile all'escalation dei privilegi a causa di ACL deboli della directory di installazione. Come per qualsiasi software Windows che si installa in una posizione al di fuori di C:\Program Files\ o di altre posizioni con ACL ristretti, spetta all'installatore del software impostare esplicitamente gli ACL sulla directory di destinazione.
Crassus trova molti modi per ottenere l'escalation dei privilegi con questo software, tra cui:
Nell'output di Crassus, possiamo vedere che c:\atlassian\bitbucket\7.9.1\elasticsearch\bin\elasticsearch-service-x64.exe è privilegiato, ma dato che è in esecuzione non possiamo semplicemente sostituirlo. Tuttavia, possiamo usare un altro trucco per dirottarlo. Possiamo semplicemente rinominare la directory in cui si trova, crearne una nuova con lo stesso nome e posizionare il nostro payload con lo stesso nome.
Una volta riavviato con un log di avvio di Process Monitor, possiamo vedere che il nostro file elasticsearch-service-x64.exe posizionato è in esecuzione al posto di quello reale, basandoci sull'icona di Windows Calculator.
Come descritto in VU#287178, le versioni precedenti del software McAfee sono vulnerabili all'escalation dei privilegi tramite openssl.cnf. Diamo un'occhiata:
Per vedere perché ci sono due diversi riferimenti a openssl.cnf in questo log di avvio, possiamo fare riferimento al file results.csv:
Nota che il caricamento del file openssl.cnf dal percorso D:\ richiederà un'indagine manuale più approfondita, poiché la fattibilità del caricamento di tale percorso dipende dalla piattaforma in questione e dall'accesso al sistema disponibile. Potrebbe essere possibile creare un disco ottico che fornisca un file openssl.cnf che faccia anche riferimento a un percorso che risolva all'unità ottica.
SQL Server 2022 non è ovviamente vulnerabile all'escalation dei privilegi a causa di ACL deboli a meno che non sia installato in una posizione non standard. Se è installato in una posizione al di fuori di C:\Program Files, Crassus scoprirà diverse possibilità di escalation dei privilegi. La maggior parte delle applicazioni Windows che includono un componente privilegiato sembrano essere sfruttabili in questo modo se sono installate in una directory che non ha già ACL intrinsecamente sicuri.
Se Crassus segnala il caricamento privilegiato di un file che un utente può posizionare o modificare, ciò non significa necessariamente che sia uno scenario sfruttabile. Mentre Crassus cerca tipi di file potenzialmente interessanti, un file di log di Process Monitor non indicherà direttamente cosa il processo associato avrebbe fatto con il file se fosse stato presente. Potrebbe essere semplice come estrarre un'icona del programma. Investigare lo stack di chiamate dell'operazione sul file in Process Monitor può dare un indizio su cosa sarebbe stato fatto. Oppure basta posizionare il file e investigare il comportamento con un nuovo log di avvio di Process Monitor, se preferisci la via più semplice della forza bruta. Potresti anche incontrare una libreria mancante in cui Crassus non riesce a trovare la libreria per sapere quali export dovrebbero essere presenti, o gli export trovati da Crassus sono in conflitto in un modo che impedisce una corretta compilazione della DLL. In tali casi, Crassus ripiegherà sulla creazione di una DLL che non esporta alcun nome di funzione. A seconda di come l'applicazione target carica la libreria, l'assenza di nomi di funzione e/o numeri ordinali attesi potrebbe impedire all'applicazione target di caricare correttamente la libreria. Questo scenario richiederà uno sforzo manuale per determinare come dovrebbe apparire la DLL proxy.
Crassus cercherà operazioni sui file privilegiate per scoprire percorsi di interesse. Potresti incontrare uno scenario in cui sia un processo privilegiato che uno non privilegiato accedono a un percorso, ma solo il processo non privilegiato è quello che esegue ciò che potrebbe essere presente. In alternativa, potresti incontrare uno scenario in cui un processo padre viene eseguito con privilegi, ma potrebbe generare esplicitamente processi figlio con privilegi inferiori.
Specialmente quando si installa software per la prima volta, o quando si installano aggiornamenti, Process Monitor potrebbe registrare un'operazione su un file che sembra sfruttabile ma non si verifica ogni volta che il sistema si avvia. Sfruttare queste operazioni potrebbe essere possibile al primo riavvio dopo che si verifica un tale evento. Per evitare questi casi limite, conferma che i log di avvio successivi contengano le stesse operazioni sui file segnalate nei riavvii successivi.
Che si tratti di un errore di battitura, un bug o una nuova funzionalità, Crassus è molto aperto ai contributi purché concordiamo su quanto segue: