Ricordate Heartbleed? Se credete all’hype di oggi, Shellshock è in quella lega e con un nome altrettanto impressionante anche se privo di un logo figo (qualcuno nel dipartimento di marketing di questi vuln ha bisogno di occuparsene). Ma in tutta serietà, ha il potenziale per essere un grosso problema e, come ho fatto con Heartbleed, ho voluto mettere insieme qualcosa di definitivo sia per me per venire a capo della situazione che per gli altri per sezionare l’hype dal vero rischio sottostante.
Per preparare la scena, lasciatemi condividere alcuni contenuti dal post del blog di Robert Graham che ha fatto alcune analisi eccellenti su questo. Immaginate una richiesta HTTP come questa:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Che, quando viene emessa contro una serie di indirizzi IP vulnerabili, dà come risultato questo:
In poche parole, Robert ha appena orchestrato un gruppo di macchine esterne che lo pingano semplicemente emettendo una richiesta attentamente elaborata sul web. Ciò che è davvero preoccupante è che ha effettivamente fatto in modo che queste macchine emettessero un comando arbitrario (anche se un ping piuttosto benevolo) e questo apre un intero mondo di possibilità molto gravi. Lasciatemi spiegare.
Che cos’è Bash e perché ne abbiamo bisogno?
Skip questo se è una notizia vecchia, ma il contesto è importante per coloro che non hanno familiarità con Bash quindi cerchiamo di stabilire una comprensione di base. Bash è una shell *nix o in altre parole, un interprete che permette di orchestrare comandi su sistemi Unix e Linux, tipicamente collegandosi tramite SSH o Telnet. Può anche funzionare come un parser per gli script CGI su un server web, come tipicamente vediamo in esecuzione su Apache. È in circolazione dalla fine degli anni ’80, dove si è evoluta da precedenti implementazioni di shell (il nome deriva dalla Bourne shell) ed è enormemente popolare. Ci sono altre shell là fuori per le varianti di Unix, ma la cosa importante di Bash è che è la shell predefinita per Linux e Mac OS X, che sono ovviamente sistemi operativi estremamente diffusi. Questo è un fattore importante nel perché questo rischio è così significativo – l’ubiquità di Bash – ed è stato descritto come “una delle utility più installate su qualsiasi sistema Linux”.
Si può avere un senso dell’impronta di Bash quando si guardano le ultime statistiche dei server web Netcraft:
Quando metà della rete sta eseguendo Apache (che si trova tipicamente su Linux), è una dimensione significativa di una torta molto, molto grande. Lo stesso articolo di Netcraft riporta che abbiamo appena superato il traguardo del miliardo di siti web e mentre un sacco di questi condividono gli stessi host, si tratta ancora di un sacco di installazioni di Bash. Oh – questo è solo per i server web, non dimenticate che ci sono un mucchio di altri server con Linux e torneremo anche su altri dispositivi con Bash un po’ più tardi.
Bash può essere usato per un’intera gamma di funzioni amministrative tipiche, tutto dalla configurazione di siti web fino al controllo del software incorporato in un dispositivo come una webcam. Naturalmente questa non è una funzionalità che è destinata ad essere aperta al mondo e in teoria, stiamo parlando di utenti autenticati che eseguono comandi che sono stati autorizzati ad eseguire. In teoria.
Qual è il bug?
Partiamo con il CVE dal database delle vulnerabilità del NIST perché dà un buon senso della gravità (evidenziazione mia):
GNU Bash through 4.3 elabora le stringhe di trascinamento dopo le definizioni di funzione nei valori delle variabili d’ambiente, il che permette agli aggressori remoti di eseguire codice arbitrario attraverso un ambiente manipolato, come dimostrato da vettori che coinvolgono la funzione ForceCommand in OpenSSH sshd, i moduli mod_cgi e mod_cgid in Apache HTTP Server, gli script eseguiti da non specificati client DHCP, e altre situazioni in cui l’impostazione dell’ambiente avviene attraverso un confine di privilegi dall’esecuzione Bash.
Continuano a valutarlo un “10 su 10” per la gravità o, in altre parole, peggio di così non si può. Questo è aggravato dal fatto che è facile eseguire l’attacco (la complessità di accesso è bassa) e forse più significativamente, non è richiesta l’autenticazione quando si sfrutta Bash tramite script CGI. Il riassunto di cui sopra è un po’ contorto, quindi riduciamo la questione alla meccanica del bug.
Il rischio si concentra sulla capacità di definire arbitrariamente variabili d’ambiente all’interno di una shell Bash che specificano una definizione di funzione. Il problema inizia quando Bash continua a processare i comandi della shell dopo la definizione della funzione, dando luogo a quello che classifichiamo come un “attacco di iniezione di codice”. Guardiamo di nuovo l’esempio di Robert e prendiamo solo questa linea:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
La definizione della funzione è () { :; }; e il comando della shell è la dichiarazione ping e i parametri successivi. Quando questo viene elaborato nel contesto di una shell Bash, il comando arbitrario viene eseguito. In un contesto web, questo significherebbe attraverso un meccanismo come uno script CGI e non necessariamente come intestazione della richiesta. Vale la pena di leggere l’avviso di seclists.org dove entrano più in dettaglio, tra cui si afferma che il percorso e la stringa di query potrebbero essere potenziali vettori per l’attacco.
Naturalmente un mezzo per mitigare questo particolare vettore di attacco è semplicemente quello di disabilitare qualsiasi funzionalità CGI che fa chiamate a una shell e infatti alcuni lo stanno raccomandando. In molti casi, però, questo sarà un cambiamento gravemente dannoso e, come minimo, uno che richiederà alcuni test approfonditi per garantire che non causi problemi immediati nel sito web, cosa che in molti casi accadrà.
La prova HTTP di cui sopra è una semplice ma efficace, anche se solo un’implementazione su un protocollo comune. Una volta che si inizia a gettare in Telnet e SSH e apparentemente anche DHCP, la portata aumenta drammaticamente, quindi non stiamo assolutamente parlando solo di sfruttare i server delle applicazioni web qui. (Apparentemente il rischio è presente solo in SSH post-auth, ma in una fase così precoce della divulgazione pubblica vedremo inevitabilmente altri vettori di attacco emergere ancora.)
Quello che dovete anche ricordare è che la portata del danno potenziale si estende ben oltre il ping di un indirizzo arbitrario come nell’esempio di Robert, che è semplicemente una piccola prova pulita che potrebbe orchestrare una macchina per emettere un comando shell. La domanda diventa questa: Quali danni potrebbe fare un attaccante quando può eseguire un comando shell a sua scelta su qualsiasi macchina vulnerabile?
Quali sono le potenziali ramificazioni?
Il potenziale è enorme – “ottenere la shell” su una macchina è sempre stata una grande vittoria per un attaccante a causa del controllo che offre sull’ambiente di destinazione. Accesso ai dati interni, riconfigurazione degli ambienti, pubblicazione del proprio codice maligno, ecc. È quasi illimitato ed è anche facilmente automatizzabile. Ci sono molti, molti esempi di exploit là fuori che potrebbero essere facilmente sparati contro un gran numero di macchine.
Purtroppo quando si tratta di esecuzione di codice arbitrario in una shell su fino alla metà dei siti web su Internet, il potenziale è piuttosto ampio. Uno di quelli ovvi (e particolarmente brutto) è il dumping dei file interni per il recupero pubblico. I file di password e i file di configurazione con le credenziali sono quelli ovvi, ma potrebbero plausibilmente estendersi a qualsiasi altro file sul sistema.
Similmente, lo stesso approccio potrebbe essere applicato per scrivere file sul sistema. Questo è potenzialmente il più facile vettore di defacement di siti web che abbiamo mai visto, per non parlare di un modo molto facile di distribuire malware
Ovvero: una parola che continuo a vedere spesso è “worm”:
Quando parliamo di worm in un contesto di malicious computing, stiamo parlando di un attacco auto-replicante in cui un attore maligno crea codice che è in grado di propagarsi attraverso gli obiettivi. Per esempio, abbiamo visto un’implementazione molto efficace di questo con il MySpace XSS Worm di Samy, dove alcuni JavaScript accuratamente realizzati sono riusciti a “infettare” un milione di pagine delle vittime in meno di un giorno.
La preoccupazione con Shellshock è che un attacco di questa natura potrebbe replicarsi ad un ritmo allarmante, in particolare all’inizio mentre la maggior parte delle macchine rimane a rischio. In teoria, questo potrebbe assumere la forma di una macchina infetta che scansiona altri obiettivi e propaga l’attacco ad essi. Questo non sarebbe in alcun modo limitato alle macchine che si affacciano sul pubblico, ma dietro il firewall aziendale e il cielo è il limite.
La gente sta lavorando sullo sfruttamento di questo in questo momento. Questo è ciò che rende questi primi giorni così interessanti, mentre la corsa agli armamenti tra coloro che si affannano a patchare e quelli che si affannano ad attaccare si riscalda.
Quali versioni di Bash sono colpite?
I titoli dichiarano tutto fino alla 4.3 o in altre parole, circa 25 anni di versioni di Bash. Dato che tutti continuano a paragonare questo a Heartbleed, considerate che le versioni colpite di OpenSSL sono durate solo due anni, che è una goccia nell’oceano rispetto a Shellshock. Sì, le persone aggiornano le loro versioni, ma no, non lo fanno in modo coerente e in qualsiasi modo lo si tagli, l’ampiezza delle macchine a rischio sarà significativamente più alta con Shellshock di quanto non fosse con Heartbleed.
Ma il rischio potrebbe anche estendersi oltre la 4.3. Stiamo già vedendo rapporti di patch non del tutto efficaci e data la velocità con cui sono state distribuite, questo non è così sorprendente. Questo è il tipo di cosa che coloro che ne sono colpiti vogliono tenere d’occhio molto da vicino, non solo “patch e dimenticare”.
Quando ne siamo venuti a conoscenza per la prima volta e da quanto tempo siamo a rischio?
La prima menzione che ho trovato sull’etere pubblico è stato questo brevissimo riassunto su seclists.org che funziona alle 14:00 GMT di mercoledì (circa mezzanotte di questa mattina per quelli di noi nella parte orientale dell’Australia). I dettagli sono arrivati nell’avviso che ho menzionato prima un’ora dopo, quindi verso la metà del pomeriggio di mercoledì in Europa o la mattina negli Stati Uniti. È ancora una notizia molto fresca con tutte le solite speculazioni della stampa e le previsioni di Chicken Little; è troppo presto per osservare qualsiasi sfruttamento diffuso in natura, ma questo potrebbe anche arrivare molto presto se il rischio è all’altezza del suo potenziale.
Scorri indietro oltre a ciò che è stato rivelato pubblicamente e il bug è stato apparentemente scoperto la scorsa settimana da Stéphane Chazelas, un tipo “Unix/Linux, specialista di rete e telecomunicazioni” nel Regno Unito. Detto questo, nel post di Akamai sul bug, si parla che è stato presente per “un lungo periodo di tempo” e naturalmente le versioni vulnerabili di Bash risalgono a due decenni e mezzo fa. La domanda, come per Heartbleed, sarà se gli attori malintenzionati erano a conoscenza di questo prima di adesso e se lo stavano attivamente sfruttando.
Le nostre “cose” sono colpite?
Questo è dove diventa interessante – abbiamo un sacco di “cose” che potenzialmente eseguono Bash. Naturalmente quando uso questo termine mi riferisco all'”Internet delle cose” (IoT) che è la crescente prevalenza dell’inserimento di un indirizzo IP e di un adattatore wireless in ogni cosa, dalle nostre posate alle serrature delle porte alle nostre lampade.
Molti dispositivi IoT eseguono distribuzioni Linux embedded con Bash. Questi stessi dispositivi hanno già dimostrato di dimostrare gravi vulnerabilità di sicurezza in altre aree, per esempio i globi luminosi LIFX solo un paio di mesi fa sono stati trovati a perdere le credenziali wifi. Anche se non è una vulnerabilità Bash come Shellshock, ci mostra che collegando le nostre cose stiamo entrando in un intero nuovo mondo di vulnerabilità in luoghi che non sono mai stati a rischio prima.
Modifica: Alcune persone hanno fatto riferimento alla prevalenza di BusyBox che esegue la shell Ash sui dispositivi mobili. I dispositivi che eseguono questo non sembrano essere a rischio di Shellshock. La difficoltà per un consumatore è che non sa cosa sia in esecuzione sui suoi dispositivi, e questo include anche “cose” più tradizionali come i router. La lunga storia di questo bug significa che abbiamo più di un paio di decenni di dispositivi là fuori che sono passati attraverso varie evoluzioni di diversi OS embedded e ora abbiamo un panorama molto vario di macchine e shell che coprono un lungo periodo di tempo.
Questo porta con sé molte nuove sfide; per esempio, chi pensa attivamente di dover patchare regolarmente le proprie lampadine? Considerate anche la longevità dei dispositivi in cui questo software appare e se sono effettivamente mantenuti attivamente. In un caso come quello delle telecamere vulnerabili Trendnet di un paio di anni fa, ce n’è senza dubbio un numero enorme ancora sul web, perché in termini di patch, sono praticamente una proposta “imposta e dimentica”. Infatti in quel caso c’è un intero account Twitter dedicato a trasmettere le immagini che ha catturato di ignari proprietari di versioni vulnerabili. È un grosso problema senza facili soluzioni e ci accompagnerà per molto tempo.
Ma le shell Bash sono presenti anche in molti dispositivi più comuni, per esempio i nostri router domestici che sono generalmente rivolti a Internet. Ricordate l’ultima volta che avete patchato il firmware del vostro router? Ok, se stai leggendo questo allora forse sei il tipo di persona tecnica che effettivamente patcha il proprio router, ma mettiti nei panni dell’Average Joe Consumer e chiediti di nuovo questo. Esattamente.
Tutte le nostre cose sono sullo stack Microsoft, siamo a rischio?
Risposta breve “no”, risposta lunga “sì”. Affronterò prima quella facile – Bash non si trova nativamente su Windows e mentre ci sono implementazioni di Bash per Windows, non è certamente comune e non si troverà sui PC di consumo. Non è nemmeno chiaro se prodotti come win-bash siano effettivamente vulnerabili a Shellshock in primo luogo.
La risposta più lunga è che solo perché si opera in un ambiente prevalentemente Microsoft-centrico non significa che non si abbia Bash in esecuzione su macchine che servono altri scopi discreti all’interno di quell’ambiente. Quando ho scritto su Heartbleed, ho fatto riferimento al post di Nick Craver sullo spostamento di Stack Overflow verso SSL e ho fatto riferimento a questo diagramma della loro infrastruttura:
Ci sono componenti non-Microsoft seduti davanti al loro stack di applicazioni Microsoft, componenti che il traffico deve attraversare prima di raggiungere i server web. Questi sono anche componenti che possono avere privilegi elevati dietro il firewall – qual è l’impatto se Shellshock viene sfruttato su questi? Potrebbe essere significativo e questo è il punto che sto facendo qui; Shellshock ha il potenziale di avere un impatto sulle risorse al di là delle sole implementazioni Bash a rischio quando esiste in un ecosistema più ampio di altre macchine.
Sono un amministratore di sistema – cosa posso fare?
In primo luogo, scoprire se si è a rischio è banale poiché è un rischio facilmente riproducibile. C’è un test molto semplice che The Register suggerisce, che è semplicemente l’esecuzione di questo comando all’interno della vostra shell:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Si ottiene “busted” echo’d indietro e si è sfruttato con successo il bug.
Ovviamente la priorità qui sta per essere la patch dei sistemi a rischio e la patch si riduce essenzialmente a garantire che nessun codice possa essere eseguito dopo la fine di una funzione Bash. Le distro Linux come Red Hat stanno rilasciando una guida sulla patch del rischio, quindi saltate su quella come una questione di priorità.
Inevitabilmente vedremo anche definizioni per i sistemi di rilevamento delle intrusioni e certamente ci saranno modelli comuni da cercare qui. Questo potrebbe rivelarsi una buona implementazione a breve termine per molte organizzazioni, in particolare dove ci possono essere requisiti di test onerosi prima di distribuire le patch ai sistemi a rischio. Qualys sta puntando ad avere una definizione per rilevare l’attacco abbastanza rapidamente e inevitabilmente altri fornitori di IDS stanno lavorando su questo 24 ore su 24.
Altre opzioni più drastiche includono la sostituzione di Bash con un’implementazione shell alternativa o l’isolamento dei sistemi a rischio, entrambe le quali potrebbero avere ramificazioni di vasta portata e difficilmente sono decisioni da prendere alla leggera. Ma questa sarà probabilmente la natura di questo bug per molte persone – decisioni difficili che potrebbero avere un impatto tangibile sul business al fine di evitare ramificazioni potenzialmente molto più significative.
L’altra questione che ora inizierà a venire fuori molto è la questione se Shellshock è già stato sfruttato in un ambiente. Questo può essere difficile da determinare se non c’è una registrazione dei vettori di attacco (spesso non c’è se viene passata dall’intestazione della richiesta HTTP o dal corpo del POST), ma è più probabile che venga catturato rispetto a Heartbleed quando, a corto di pcaps completi, i payloads dell’heartbeat normalmente non sarebbero stati registrati da nessuna parte. Ma ancora, la risposta più comune a “siamo stati attaccati tramite Shellshock” sarà questa:
purtroppo, questo non è “No, abbiamo prove che non ci sono stati compromessi;” piuttosto, “non abbiamo prove che coprono la durata di questa vulnerabilità.” Dubitiamo che molte persone lo sappiano – e questo lascia i proprietari del sistema nella scomoda posizione di non sapere quali, se ci sono stati, compromessi potrebbero essere accaduti.
Lasciate che le speculazioni sul fatto che la NSA fosse coinvolta in questo iniziano…
Sono un consumatore – cosa posso fare?
Dipende. Shellshock colpisce i Mac, quindi se stai usando OS X, in questa fase sembra essere a rischio, il che da un lato è un male a causa della prevalenza di OS X, ma dall’altro sarà facilmente (e si spera rapidamente) rimediato a causa di un meccanismo di aggiornamento abbastanza ben collaudato (cioè Apple può spingere da remoto gli aggiornamenti alla macchina).
Se siete su un Mac, il rischio è facilmente verificabile come descritto in questa risposta di Stack Exchange:
E’ un test facile, anche se dubito che l’utente medio Mac si senta a suo agio nell’affrontare la correzione suggerita, che comporta la ricompilazione di Bash.
La preoccupazione maggiore riguarda i dispositivi che non hanno un percorso di patch facile, per esempio il router. A parte il controllo sul sito web del produttore per un firmware aggiornato, questo sarà un problema molto difficile da risolvere. Spesso i router forniti dagli ISP sono bloccati in modo che i consumatori non cambino a caso la configurazione o il firmware e non c’è sempre un percorso di aggiornamento remoto che possano attivare. Combinate questo con la massiccia gamma di dispositivi ed età che ci sono là fuori e questo potrebbe essere particolarmente difficile. Naturalmente non è nemmeno il tipo di cosa che il consumatore medio si troverà a suo agio a fare da solo.
In breve, il consiglio ai consumatori è questo: state attenti agli aggiornamenti di sicurezza, in particolare su OS X. Tenete anche d’occhio qualsiasi consiglio che potreste ricevere dal vostro ISP o da altri fornitori di dispositivi che hanno un software incorporato. Siate cauti con le e-mail che richiedono informazioni o che vi istruiscono ad eseguire un software – eventi come questo sono spesso seguiti da attacchi di phishing che sfruttano le paure dei consumatori. Le bufale attualmente hanno persone che mettono i loro iPhone nel microonde, quindi non pensate nemmeno per un momento che non eseguiranno un pezzo di software casuale inviato loro via e-mail come “correzione” per Shellshock!
Sommario
Con tutta probabilità, non abbiamo nemmeno iniziato a sondare la portata di questa vulnerabilità. Naturalmente ci sono molti paragoni con Heartbleed e ci sono diverse cose che abbiamo imparato da quell’esercizio. Una è che c’è voluto un po’ di tempo per capire fino a che punto eravamo dipendenti da OpenSSL. L’altra è che aveva una coda molto lunga – mesi dopo aver colpito c’erano ancora centinaia di migliaia di host conosciuti lasciati vulnerabili.
Ma in un modo, il confronto Heartbleed non è giusto – questo è potenzialmente molto peggio. Heartbleed permetteva l’accesso remoto a piccole quantità di dati nella memoria delle macchine colpite. Shellshock sta permettendo l’iniezione di codice remoto di comandi arbitrari pre-auth che è potenzialmente molto più terribile. A questo proposito, devo essere d’accordo con Robert:
È ancora molto, molto presto – solo mezza giornata da quando ha colpito l’etere al momento della scrittura – e ho il sospetto che finora stiamo solo grattando la superficie di ciò che deve ancora venire.
Sicurezza