l3cr0f/dccwbypassuacBypass UAC su Windows 8.1 e 10 abusando di WinSxS in "dccw.exe".
Questo exploit sfrutta il modo in cui "WinSxS" viene gestito da "dccw.exe", tramite un metodo derivato dal "Bypass UAC" di Leo Davidson, al fine di ottenere una shell di amministratore senza richiedere il consenso. Supporta le architetture "x86" e "x64". Inoltre, è stato testato con successo su Windows 8.1 9600, Windows 10 14393, Windows 10 15031 e Windows 10 15062.
Se vuoi vedere come eseguire lo script, dai un'occhiata alla sezione utilizzo. Inoltre, puoi eseguirlo in Metasploit e ottenere una sessione Meterpreter con diritti di amministratore.
Per sviluppare un nuovo bypass UAC, dobbiamo prima trovare una vulnerabilità nel sistema e, per essere più precisi, una vulnerabilità in un processo ad auto-elevazione. Per ottenere un elenco di tali processi abbiamo usato lo strumento Sysinternals chiamato Strings. Dopo di che, abbiamo potuto vedere alcuni processi ad auto-elevazione come "sysprep.exe", "cliconfig.exe", "inetmgr.exe", "consent.exe" o "CompMgmtLauncher.exe" che avevano (alcuni di essi hanno ancora) vulnerabilità che consentono l'esecuzione di un "bypass UAC". Quindi, abbiamo iniziato a studiare come funzionavano altri processi ad auto-elevazione con l'applicazione Sysinternals chiamata Process Monitor (ProcMon), concentrandoci però sul processo "dccw.exe".
Tuttavia, prima di iniziare con ProcMon, abbiamo controllato il manifest di tali applicazioni con un'altra applicazione Sysinternals chiamata Sigcheck e, ovviamente, nel nostro caso "dccw.exe" è un processo ad auto-elevazione.
Poi, abbiamo potuto iniziare a seguire il flusso di esecuzione di "dccw.exe" con ProcMon per vedere se accadeva qualcosa di strano, cosa che abbiamo verificato immediatamente. A un certo punto, se abbiamo eseguito "dccw.exe" come processo a 64 bit su una macchina Windows a 64 bit, esso cerca la directory "C:\Windows\System32\dccw.exe.Local\" per caricare una DLL specifica chiamata "GdiPlus.dll", come farebbe se fosse eseguito su una macchina Windows a 32 bit, mentre se lo eseguiamo come processo a 32 bit sulla stessa macchina, il processo cercherà la directory "C:\Windows\SysWOW64\dccw.exe.Local\". Quindi, poiché essa non esiste, il processo cerca sempre una cartella nel percorso "C:\Windows\WinSxS\" per ottenere la DLL desiderata; questa cartella ha un nome con la seguente struttura:
[architecture]_microsoft.windows.gdiplus_[sequencial_code]_[Windows_version]_none_[sequencial_number]
Se diamo un'occhiata alla directory "WinSxS", possiamo vedere più di una cartella che corrisponde a questa struttura; questo significa che "dccw.exe" può caricare la DLL desiderata da una qualsiasi di queste cartelle. L'unica cosa di cui siamo certi è che se l'applicazione viene richiamata come processo x86, il nome della cartella inizierà con la stringa "x86", mentre se la eseguiamo come processo x64, il suo nome inizierà con la stringa "amd64".
Questa situazione può essere sfruttata per eseguire un DLL hijacking e poi eseguire codice con integrità elevata senza richiedere il consenso.
Una volta trovato un errore durante l'esecuzione di un processo ad auto-elevazione, dobbiamo verificare se esso può essere sfruttato o meno. Per fare questo, abbiamo semplicemente creato la cartella "dccw.exe.Local" nel percorso desiderato e, all'interno di quella cartella, abbiamo creato le cartelle situate in "WinSxS" che potevano essere richiamate dal processo per caricare "GdiPlus.dll", ma senza tale DLL.
Ora, se eseguiamo "dccw.exe" vedremo che il processo ha trovato la cartella "dccw.exe.Local" e una delle cartelle di "WinSxS", ma non la DLL desiderata, il che genera un errore. Questo è ciò che ci aspettavamo, poiché tale situazione può essere sfruttata da un attaccante come abbiamo menzionato in precedenza.
A questo punto, sappiamo già che possiamo eseguire un bypass UAC su Windows 10 sfruttando "dccw.exe", ma come?
Il metodo più utilizzato per bypassare UAC è quello sviluppato da Leo Davidson. Tuttavia, esso esegue un'iniezione di processo per richiamare l'oggetto COM IFileOperation, che può essere rilevata da alcuni software antivirus, quindi un approccio migliore da utilizzare è quello chiamato Masquerade PEB usato da Cn33liz nel suo bypass UAC.
Inoltre, dobbiamo modificare il modo in cui IFileOperation viene richiamato nelle versioni più recenti di Windows 10, poiché il metodo di Leo Davidson attiva UAC a partire dalla build 15002. Quindi, il modo in cui dobbiamo richiamare tale operazione è lo stesso dell'originale, ma senza i flag "FOF_SILENT", "FOFX_SHOWELEVATIONPROMPT" e "FOF_NOERRORUI".
Prima di eseguire l'exploit, è importante controllare alcuni aspetti per non eseguirlo senza successo e quindi far scattare alcuni allarmi. La prima cosa che controlliamo è la versione della build di Windows, poiché alcune versioni non sono vulnerabili al nostro exploit (quelle con una build inferiore a 7600). Dopo di che, verifichiamo di non avere ancora diritti di amministratore; se così non fosse, non ci sarebbe motivo di eseguire lo script. Quindi, controlliamo le impostazioni UAC per confermare che non sia impostato su "Notifica sempre", poiché se fosse impostato su quel valore, il nostro exploit sarebbe inutile. Infine, verifichiamo se l'utente appartiene al gruppo degli amministratori, perché, in caso contrario, l'exploit non avrebbe successo.
Quando si sviluppa un exploit, è importante che possa funzionare sul maggior numero possibile di sistemi; questo include i sistemi Windows a 32 bit. Per raggiungere questo obiettivo, dobbiamo compilare il nostro exploit per tali sistemi, dato che possiamo eseguirlo anche su sistemi a 64 bit.
Quando il nostro exploit a 32 bit viene eseguito su una macchina Windows a 64 bit, il modo in cui "dccw.exe" opera è leggermente diverso a causa del richiamo di WOW64 (il sottosistema Windows che consente alle macchine a 64 bit di eseguire applicazioni a 32 bit). Questo significa che la cartella "dccw.exe.Local" verrà cercata nella directory "C:\Windows\SysWOW64\" invece che in "C:\Windows\System32\", ma anche che la "GdiPlus.dll" presa di mira sarà una DLL a 32 bit, il che implica che verrà cercata in una cartella che corrisponde al pattern di nome "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*". Tuttavia, se viene eseguito su un sistema Windows a 32 bit, l'exploit funzionerà come previsto.
Infine, è importante sottolineare che dobbiamo considerare tutti i percorsi che corrispondono al pattern "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" quando viene eseguito il DLL hijacking, al fine di garantire un'efficacia del 100%.
Per eseguire un processo con integrità elevata dobbiamo sviluppare una DLL che verrà richiamata tramite DLL hijacking. Tuttavia, non è così semplice come sembra, perché se facciamo solo questo, né "dccw.exe" né il nostro codice verranno eseguiti. Questo perché "dccw.exe" dipende da alcune funzioni di "GdiPlus.dll", quindi dobbiamo implementare o inoltrare l'esecuzione di tali funzioni alla DLL legittima.
L'opzione migliore è inoltrare l'esecuzione alla DLL legittima, perché in questo modo la dimensione della nostra DLL sarà inferiore. Per fare ciò, abbiamo usato il programma ExportsToC++ per portare tutti gli export di "GdiPlus.dll" in linguaggio C++. Ora, il problema è l'enorme numero di export che "GdiPlus.dll" possiede, 631 per l'esattezza; tuttavia, "dccw.exe" non li importa tutti, ma solo alcuni. Per sapere quali funzioni di "GdiPlus.dll" vengono importate da "dccw.exe", ne abbiamo fatto il reverse engineering con "IDA Pro". Infine, solo 15 funzioni vengono importate da "GdiPlus.dll", quindi dobbiamo includere solo quelle nella nostra DLL.
Ora, sembra che il problema sia stato risolto, ma se inoltriamo l'esecuzione a una "GdiPlus.dll" specifica in C:\Windows\WinSxS\", la DLL funzionerà solo su alcuni sistemi, poiché il nome delle cartelle interne di "WinSxS" cambia a ogni build di Windows. Per superare questo problema, abbiamo avuto l'idea di inoltrare l'esecuzione a "C:\Windows\System32\GdiPlus.dll", poiché il percorso è lo stesso su tutti i sistemi Windows 10
L'ultima cosa che dobbiamo fare è fermare l'esecuzione di "dccw.exe" dopo l'esecuzione del nostro codice dannoso, in modo da evitare l'apertura della finestra di quel processo.
Ora, una volta sviluppata la nostra DLL dannosa, dobbiamo rilasciarla sulla macchina bersaglio. Per fare ciò, la nostra DLL è stata compressa e codificata in "base64" nell'exploit, in modo che possa essere decodificata e decompressa a runtime per essere rilasciata come previsto.
Infine, la nostra "GdiPlus.dll" appositamente creata viene copiata nella posizione bersaglio utilizzando l'oggetto COM IFileOperation come menzionato in precedenza.
Quando un attaccante compromette un sistema, vuole rimanere non rilevato il più a lungo possibile; questo significa rimuovere ogni traccia delle azioni che esegue. Per questo motivo, tutti i file temporanei che vengono creati durante l'esecuzione dell'exploit vengono rimossi quando non sono più necessari.
Infine, dobbiamo determinare quale processo vogliamo eseguire con integrità elevata. Nel nostro caso, abbiamo scelto l'applicazione "cmd.exe" perché ci consente di eseguire tutte le operazioni con integrità elevata che vogliamo una volta che avremo i diritti di amministratore, ma, in realtà, possiamo eseguire qualsiasi applicazione vogliamo.
Per eseguire l'exploit devi essere sicuro che la macchina bersaglio soddisfi i requisiti. Quindi, devi semplicemente eseguire l'exploit come qualsiasi altro script da riga di comando:
C:\Users\L3cr0f> DccwBypassUAC.exe
Il modulo Metasploit di questo PoC usa l'iniezione DLL invece del Masquerading PEB ed è disponibile in:
- Metasploit Framework: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/local/bypassuac_injection_winsxs.rbQuesto exploit è stato sviluppato per mostrare come un attaccante potrebbe ottenere privilegi su un sistema, non per essere usato per scopi dannosi. Questo significa che non mi assumo alcuna responsabilità se qualcuno lo utilizza per compiere attività criminali.
User Access Control (UAC) è una tecnologia introdotta con Windows Vista che fornisce un metodo per separare i privilegi e le attività degli utenti standard da quelli che richiedono l'accesso come Amministratore. Se un utente standard sta usando il sistema e tenta di eseguire un'azione per la quale non ha autorizzazione, appare un prompt di Windows che chiede la password dell'account Amministratore. Se un Amministratore sta usando il sistema e tenta di eseguire la stessa operazione, appare solo un prompt di avviso. Tale prompt è noto come "Consent Prompt" perché all'amministratore viene solo chiesto di accettare l'azione prima di procedere. Una debolezza che consentirebbe di bypassare il "Consent Prompt" non è considerata una vulnerabilità di sicurezza, poiché non è considerato un confine di sicurezza.
Tuttavia, Microsoft afferma anche che "User Account Control (UAC) è un componente fondamentale della visione complessiva di Microsoft in materia di sicurezza".
Fonti:
- Definizione di vulnerabilità di sicurezza.
- Come funziona User Account Control.