fortra/cve-2023-28252Analisi tecnica e exploit proof-of-concept per CVE-2023-28252, una vulnerabilità di escalation dei privilegi nel driver Windows Common Log File System (CLFS) utilizzata negli attacchi ransomware Nokoyawa.
Da febbraio 2022 è stato segnalato un nuovo ransomware che sembra sfruttare una vulnerabilità 0-day di Windows, secondo la ricerca condotta da Trend Micro.
Maggiori informazioni su questo ransomware si trovano a questo
link.
Secondo l'analisi di Kaspersky, il gruppo ransomware Nokoyawa ha utilizzato altri exploit che colpiscono il driver Common Log File System (CLFS) da giugno 2022, con caratteristiche simili ma distinte, tutti collegati a un singolo sviluppatore di exploit.
Nell'aprile 2023, quando Microsoft ha rilasciato la patch, è stato assegnato
CVE-2023-28252.
In precedenza, nel 2022, un bug simile nello stesso componente era stato studiato da noi e documentato in questo
blogpost
Per affrontare l'analisi, è necessario conoscere il formato del file .blf, gestito dal driver vulnerabile Common Log File System chiamato CLFS.sys e che si trova nella cartella dei driver all'interno di system32.
Maggiori informazioni su questo tipo di file si trovano nei link seguenti:
https://github.com/ionescu007/clfs-docs/blob/main/README.md
https://www.coresecurity.com/core-labs/articles/understanding-cve-2022-37969-windows-clfs-lpe
Questa analisi è fatta per Windows 11 21H2, clfs.sys versione 10.0.22000.1574 sebbene funzioni anche su Windows 10 21H2, Windows 10 22H2, Windows 11 22H2 e Windows server 2022.
Nelle versioni precedenti di Windows, è necessario regolare alcuni valori, altrimenti si produrrebbe un BSOD.
Microsoft Patch Tuesday aprile 2023.
È possibile controllare la versione del driver come mostrato
Quando la vulnerabilità è stata pubblicata, nell'aprile 2023 ho iniziato con Esteban Kazimirow a eseguire il reverse del driver CLFS.sys, sebbene in questo caso, analizzare solo la patch fosse molto difficile per dedurre dove fosse il bug e come innescarlo, poiché lo sfruttamento è molto complesso.
Successivamente, è uscito un blogpost il cui autore, a partire da un campione di malware, ha mostrato alcune parti del codice decompilato da HexRays e alcune informazioni che hanno guidato su dove doveva essere affrontato lo sfruttamento.
Ovviamente le informazioni fornite non erano complete, ma senza questo aiuto sarebbe stato improbabile riuscire a costruire il PoC e poi un exploit funzionante.
Per facilitare la comprensione, spiegheremo prima come costruire il PoC e poi faremo l'analisi della vulnerabilità.
Questo blogpost contiene due sezioni:
Costruzione del PoC:
1-Ottenere gli indirizzi kernel necessari per lo sfruttamento
2-Preparare il percorso per creare i file .blf:
3-Creare il file "trigger blf" usando la funzione CreateLogFile()
4-Costruire il file "trigger blf"
5-Ottenere l'indirizzo kernel del BASE BLOCK di trigger blf
6-Chiamare AddLogContainer con l'handle di trigger blf
7-Preparare i file spray blf
8-Preparare la memoria per eseguire lo spray
9-Innescare il bug
Debugging:
1-Controllare lo spray di memoria
2-Osservare RecordOffset[12] di trigger blf
3-Osservare il valore iFlushBlock nel file spray blf
4-Perché legge da BLOCK 1 SHADOW invece di BLOCK 0 CONTROL ?
5-Perché il checksum è uguale a zero nei file spray blf ?
6-Concludere lo sfruttamento.
7-La vera patch
Creerò una funzione chiamata InitEnvironment per ottenere alcuni indirizzi Kernel necessari.
Ottengo l'indirizzo EPROCESS del mio processo e lo memorizzo nella variabile g_EProcessAddress, poi l'indirizzo EPROCESS del processo SYSTEM e lo memorizzo in system_EPROCESS, poi l'indirizzo EHTREAD del thread principale del mio processo e lo memorizzo in g_EThreadAddress e infine l'indirizzo di PREVIOUS MODE che in questa versione del PoC non verrà utilizzato.
Questo metodo è ben noto, la funzione GetObjectKernelAddress chiama NtQuerySystemInformation due volte con il primo argomento SystemExtendedHandleInformation, la prima chiamata passa una dimensione errata e restituisce errore, ma restituisce anche la dimensione corretta che viene utilizzata nella seconda chiamata e ottiene le informazioni di tutti gli handle, quindi scorrendo in un ciclo le informazioni di ogni handle e nel campo Object del handleinfo corretto si ottiene l'indirizzo cercato nel kernel.
Ho anche bisogno degli indirizzi kernel delle seguenti funzioni esportate da CLFS.sys:
• ClfsEarlierLsn
• ClfsMgmtDeregisterManagedClient
E le funzioni esportate da NTOSKRNL.exe
• RtlClearBit/PoFxProcessorNotification
• SeSetAccessStateGenericMapping
Per ottenere questi indirizzi si usa un metodo simile a quello usato per ottenere la base kernel di entrambi i moduli, chiamando NtQuerySystemInformation due volte, ma in questo caso il primo argomento sarà SYSTEM_INFORMATION_CLASS (nel PoC usiamo la funzione FindKernelModulesBase per questo scopo).
Successivamente carica CLFS.sys e NTOSKRNL.exe come modelli normali in modalità utente chiamando LoadLibrary, ottiene gli indirizzi in modalità utente con GetProcAddress e poi sottrae l'imagebase da ciascuno, ottenendo così l'offset della funzione e infine aggiunge ciascun offset alle corrispondenti basi kernel e in questo modo ottiene gli indirizzi kernel di tutte le funzioni necessarie.
Creo una funzione chiamata createInitialTriggerBlfFile che genererà e scriverà un file .blf.
Il percorso utilizzato come argomento in CreateLogFile è diverso da un percorso normale; per esempio, per aprire il file 1280.blf situato nella cartella C:\Users\Public, dobbiamo impostare il percorso LOG:C:\Users\Public\1280. Questo verrà salvato nella variabile stored_name_CreateLog.
Faccio questo usando wsprintfW() poiché stored_env memorizza il percorso C:\Users\Public, precedentemente ottenuto dalle variabili d'ambiente. A questa stringa anteporrò la stringa LOG: e un nome casuale alla fine, senza l'estensione .blf.
