In questo articolo riportiamo nel dettaglio il modo in cui i ricercatori di CheckPoint sono venuti a conoscenza di una vulnerabilità, presente nelle dll utilizzate da WinRAR, che permette di ottenere il controllo completo di un dispositivo.
WinRAR è un’utilità di archiviazione di file “trialware”, che può manipolare archivi RAR/ZIP e decomprimere numerose altre tipologie di archivi.
Secondo lo stesso produttore di WinRAR, oltre 500mln di utenti rendono WinRAR lo strumento di compressione oggi più popolare al mondo.
L’exploit, attivato tramite la semplice estrazione di un archivio, mette in grave pericolo l’intera clientela che utilizza questa utilità. Tale vulnerabilità, vecchia di oltre 19 anni, ha obbligato gli sviluppatori di WinRAR a prendere in tempi brevi una decisione drastica per porre rimedio al problema.
CheckPoint ha creato di recente un laboratorio di analisi volto ad analizzare la sicurezza dei software di terze parti. Tale laboratorio usa tecniche innovative tra le quali il “binary fuzzing”, ovvero una tipologia di attacco brute-force al codice binario che, “bombardando” un software con input formati da dati casuali, permette di individuare la presenza di vulnerabilità all’interno del codice.
Lo strumento utilizzato per questo tipo di attività è una particolare versione di WinAFL, una fork di AFL – American Fuzzy Lop, creata da GoogleProjectZERO.
L’analisi è stata incentrata verso le dll ritenute obsolete, ma ancora gestite dell’applicazione.
Come è facile immaginare, già dai primi test il fuzzer ha prodotto risultati che hanno evidenziato comportamenti “anomali” da parte di una dll. Tali anomalie hanno poi confermato la presenza di un bug logico denominato “Absolute Path Traversal”.
Prima partire con le analisi, sono richieste alcune operazioni preliminari volte ad ottimizzare l’esecuzione del fuzzer, tra le quali:
1. il patching dell’eseguibile WinRAR per:
a) processare qualsiasi tipo di archivio, senza dover ricorrere a test-case specifici per ogni formato;
b) disabilitare la GUI, evitando qualsiasi interazione umana;
2. reperire in rete della documentazione sulle utilità di archiviazione, come la ricerca condotta nel 2005 dall’Università di Oulu.
3. integrare WinAFL con le opzioni da riga di comando di WinRAR.
Fatto ciò è stato possibile procedere con il fuzzing dell’eseguibile.
I primi tentativi evidenziato delle vulnerabilità di tipo Memory Corruption – Writes Out-of-Bounds per gli archivi:
Purtroppo sfruttare queste vulnerabilità è risultato da subito infruttuoso, poiché le primitive di estrazione offrono controlli limitati verso la manipolazione di buffer sovrascritti.
Malgrado ciò, un crash relativo al parsing del formato ACE ha attirato l’attenzione dei ricercatori.
WinRAR utilizza una dll chiamata unacev2.dll per manipolare questo tipo di archivi. Si tratta di una vecchia libreria, compilata nel 2006, senza alcun meccanismo di protezione. Ed è proprio questa libreria l’input della seguente analisi.
Per analizzare la libreria è necessario capire come quest’ultima viene usata. Il reverse enginering del codice che invoca degli archivi ACE, ha evidenziato due funzioni chiave:
Non esiste un RFC per questo formato, ma vi sono numerose informazioni su internet a tal proposito:
Per comprendere a pieno il formato del file ACE è stato creato un archivio, col “vecchio” WinACE, contenente un semplice file “.TXT”. Successivamente è stata utilizzata l’utility acefile per analizzare l’header di tale archivio.
hdr_crc (contrassegnato in rosa):
filename (evidenziato in verde):
Poiché il campo filename contiene il percorso relativo al file, si possono sicuramente effettuare dei tentativi per verificare se l’algoritmo è vulnerabile al “Path Traversal”.
Va sottolineato che, per quanto accennato in precedenza, per ogni tentativo di attacco vi è la necessità di generare un valore CRC valido da inserire nell’intestazione del file, per permettere l’estrazione dell’archivio.
Eseguendo vari tentativi con il fuzzer, i ricercatori hanno immediatamente rilevato un comportamento anomalo: l’output di ogni analisi dovrebbe finire all’interno della cartella “output_folders”: ad esempio R:\ACE_FUZZER\<output_folders>\<analisys_number>\.
È stata invece riscontrata una nuova cartella denominata sourbe nella root. All’interno di essa, è stato trovato un file denominato “RED VERSION_¶” con il seguente contenuto:
È quindi il momento di evidenziare quali siano stati i vincoli che hanno indotto l’algoritmo ad utilizzare il campo filename come path di destinazione per l’estrazione.
Vi sono alcune regole che l’algoritmo di estrazione applica per la validazione del path nel quale saranno estratti i file dell’archivio.
Il validatore esegue i seguenti controlli:
In caso contrario, l’estrazione viene interrotta.
Rimane ancora da capire perché la cartella di destinazione reale viene ignorata a favore del path relativo (campo filename).
Decompilando il codice binario, ed analizzando con IDA il flusso di esecuzione e le varie chiamate a funzione, si evince quanto segue:
Di fatto, il codice all’interno della cornice verde sostituisce la cartella di destinazione con “” (stringa vuota); mentre la chiamata successiva alla funzione sprintf concatena la cartella di destinazione con il path relativo del file da estrarre.
Il flusso del codice è influenzato dalla chiamata alla funzione denominata GetDevicePathLen: se il risultato della chiamata è 0, sprintf apparirà come questo:
È questa la porzione di codice che effettivamente attiva la vulnerabilità Path Traversal.
Analizziamo nel dettaglio la funzione GetDevicePathLen per ottenere una migliore visione del bug:
Quest’ultima controlla che il nome del dispositivo o la lettera dell’unità siano presenti nel path, restituendo in output la lunghezza di tale sottostringa:
Se il valore restituito da GetDevicePathLen è >0, il path relativo del file estratto verrà considerato come path di destinazione, poiché la cartella di destinazione viene sostituita da una stringa vuota durante la chiamata a sprintf.
Tuttavia, è prevista una funzione che “pulisce” il path relativo da eventuali tentativi di Path Traversal, omettendo qualsiasi sequenza non consentita prima nella chiamata GetDevicePathLen.
Questo è uno pseudo-codice della funzione “CleanPath”:
L’obiettivo finale è creare un file exploit che faccia sì che WinRAR estragga un file su un percorso scelto arbitrariamente dall’attaccante. La destinazione ideale consiste nella cartella di Esecuzione Automatica, che esegue quanto al suo interno ad ogni avvio del SO.
Iniziamo col sostituire l’estensione “.ACE” in “.RAR”, tanto WinRAR rileva il formato del file dal contenuto dell’header, non dall’estensione.
Sappiamo poi che ci sono almeno due cartelle di Esecuzione Automatica nei seguenti percorsi di Windows:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Il primo percorso richiede privilegi elevati/livello di integrità elevato (nel caso di UAC attivo). WinRAR viene eseguito di default con un livello di integrità medio, quindi tale soluzione non è percorribile.
Il secondo percorso richiederebbe di conoscere l’account utente.
Esiste però un vettore d’attacco migliore, che non richiede di conoscere lo <user name>.
Considerando che:
utilizzando la seguente stringa nel campo filename nell’header dell’archivio ACE:
C:\C:C:../AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\some_file.exe
otterremo il seguente risultato finale:
C:../AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\some_file.exe
che permette di aggirare la convalida della stringa, poiché:
Va inoltre sottolineato che in Windows la sequenza “C:” referenzia la “directory corrente” del processo in esecuzione. Nel nostro caso la directory di default di WinRAR, tipicamente in C:\Program Files\WinRAR.
Tuttavia, interagendo con l’archivio tramite doppio clic, o facendo clic con il pulsante destro del mouse -> “Estrai”, la “directory corrente” sarà il path in cui risiede l’archivio, per l’appunto:
Quindi per arrivare alla cartella di Esecuzione Automatica, è bastato semplicemente salire di un livello ( ../) raggiungendo la cartella utente, senza saperne il nome, e concatenare il segmento di percorso che porta ad essa.
L’installazione di un eseguibile malevolo tramite questo exploit va a buon fine sia errori di progettazione delle librerie, sia per una serie di comportamenti imputabili all’utilizzo tipico effettuato dall’utenza.
Innanzitutto le funzioni di validazione del path non agiscono in maniera ricorsiva. Se così fosse, la sequenza “C:\C:C:../” sarebbe stata suddivisa in “C:\C:”, “C:” e “../”, impendendo di fatto il raggiungimento della cartella desiderata.
Inoltre, l’attaccante fa leva sulle modalità di utilizzo tipico dell’utente medio. In caso di estrazione di quest’ultimo al di fuori delle principali sottocartelle della cartella utente, tale exploit è totalmente inoffensivo.
Senza contare il fatto che l’utente predilige l’utilizzo della funzione “tasto dx -> estrai”, piuttosto che aprire l’archivio ed estrarre i file tramite GUI. In questo caso ci si renderebbe immediatamente conto che all’interno dell’archivio, oltre a file innocui, è presente un file eseguibile. E ci si renderebbe anche conto che, estratto tale archivio nelle modalità abituali, il file eseguibile non risulterebbe presente nella cartella di destinazione, evidenziando quantomeno un comportamento anomalo.
Ad ogni modo, i creatori di WinRAR hanno ovviato a tale situazione eliminando il supporto agli archivi ACE dalla versione 5.70b1. Si consiglia vivamente, per chi non avesse ancora provveduto, ad effettuare l’upgrade manuale della utility.
[1] È inoltre curioso che il creatore di tale progetto sia anche il creatore di WinRAR stesso.
[2] Si noti che non interessa la lettera dell’unità. I pattern sono validi per qualsiasi lettera.
Articolo a cura di Daniele Rigitano
Arrestato a Parigi il CEO di Telegram: cosa significa in termini di responsabilità delle piattaforme…
Introduzione In un contesto in cui la digitalizzazione sta crescendo costantemente, è importante sapere come…
Casi come Cellebrite Ufed v. Signal pongono in luce come la cybersecurity sia un fattore…
I Big Data stanno cambiando le regole del commercio online. Finalmente le aziende possono comprendere…
Dal punto di vista tecnico-operativo, le indagini di digital forensics vengono svolte utilizzando specifici strumenti…
Nell’ambito dell’email security esistono diversi protocolli volti a garantire l'autenticità, l'integrità e la riservatezza delle…