Shellshock, il ‘bash bug’ che fa tremare la rete: quanto è pericoloso?

C’è chi lo definisce peggiore di HeartBleed e chi, invece, mantiene la calma: scopriamo la natura di questa nuova vulnerabilità

L’ultima volta che il mondo dell’open source è caduto letteralmente nel panico risale ai tempi della scoperta di Heartbleed, un potente bug nel protocollo (e nelle annesse librerie) OpenSSH che ha letteralmente messo in ginocchio server da ogni dove. Oggi la storia si ripete con un secondo bug, “adulto” più o meno quanto un quarto di secolo, che riguarda la shell Bash (o Bourne Again Shell) e prende appunto il nome di bash bug – o di Shellshock, come il simpatico R. Graham l’ha ribattezzato.

Secondo alcuni importanti esponenti della sicurezza, tra cui lo stesso Graham, Shellshock sarebbe addirittura più pericoloso di Hearbleed: la causa è da ritrovarsi al diffusissimo utilizzo della shell bash – sia come applicazione attiva che come applicazione in background da parte di altri programmi – e la semplicità con cui agisce il criterio di sfruttamento della falla.

Prima di farne una pandemia, però, capiamone qualcosa in più!


Cosa è Shellshock?

Shellshock – il bash bug – altri non è che un bug insito nella shell Bash, la “console dei comandi” tipicamente inclusa in quasi tutti i sistemi operativi GNU/Linux-based (incluso Android) e Mac. Sostanzialmente il funzionamento di Shellshock coinvolge la dichiarazione e l’utilizzo di variabili d’ambiente, con un modus operandi che cercheremo di semplificare il più possibile.

In pratica, prima dell’esecuzione di Bash è possibile definire in determinati file - richiamabili anche da programmi esterni – delle variabili, che servono spesso a “semplificare” l’eventuale passaggio dei parametri al programma eseguito tramite bash.

Il problema è nella dichiarazione di tali variabili: se una variabile viene dichiarata sulla stessa riga viene specificato un particolare comando, tale comando può essere eseguito arbitrariamente da qualsiasi applicazione abbia accesso a quella variabile. In parole povere, dichiarando una o più variabili con una particolare sintassi può rendere il sistema vulnerabile.

Se masticate lo scripting bash, il tutto sarà più chiaro con un esempio. Considerate questa dichiarazione di variabile:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Shellshock fa si che Bash intepreti la parte di codice in grassetto (quindi echo vulnerable) come un vero e proprio comando da eseguire, cosa che in condizioni “normali” non dovrebbe succedere.

Infatti, eseguendo questo codice su una versione di Bash vulnerabile, l’output ottenuto è il seguente:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Se invece lo stesso codice viene eseguito su una versione di Bash non vulnerabile, il codice echo vulnerable viene riconosciuto da Bash come una potenziale dichiarazione di funzione e viene ignorato, generando un warning e lasciando la variabile non inizializzata ed il comando non eseguito (comportamento normale).

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

Shellshock è davvero pericoloso come dicono?

Diciamo che non è un gioco da ragazzi usare vulnerabilità del genere e che c’è bisogno del verificarsi di condizioni ben precise – uno script deve essere presente sul sistema con delle dichiarazioni di variabili alterate, pronte per essere usate dal programma comandato da un utente malintenzionato – ma, purtroppo, bisogna ammettere che a causa della diffusione di Bash e dell’interazione imprevista di Shellshock con i vari programmi (innumerabili) che interagiscono con essa il rischio esiste. 

Purtroppo Bash non è soltanto la “classica” shell dei sistemi operativi GNU/Linux based di conoscenza comune come Ubuntu, Debian, Gentoo, Red Hat, CentOS e via discorrendo, ma è presente in tante altre varianti di Linux presenti anche su dispositivi differenti dai PC - come router, NAS, sistemi embedded, computer di bordo, che se obsoleti potrebbero essere davvero a rischio.

Senza contare che, inoltre, Bash è presente anche su Android e su tutti i sistemi operativi Mac.


 

Chi è vulnerabile a Shellshock?

Categorizzare i dispositivi vulnerabili non è possibile, tuttavia esistono diverse linee guida per intuire se si è vulnerabili o meno. Innanzitutto bisogna specificare che le versioni di Bash vulnerabili a Shellshock vanno dalla 4.3 (inclusa) in giù, per cui la prima cosa da fare è indubbiamente aggiornare il proprio sistema operativo all’ultima versione dei pacchetti, se possibile.

Particolare attenzione va posta inoltre in ambiente server: si è comunque a rischio se la versione di Bash installata è inferiore alla 4.3 (inclusa), ma bisogna aprire gli occhi e correre ancor più rapidamente ai ripari, a causa dei danni collaterali potenziali causati da Shellshock, in caso il server esegua:

  • una configurazione di sshd che prevede attiva la clausola ForceCommand;
  • vecchie versioni di Apache che usano mod_cgi o mod_cgid, estremamente vulnerabili se gli script CGI sono scritti in bash o lanciano a loro volta shell bash (ciò non succede invece con gli script eseguiti tramite mod_php, neanche se questi lanciano shell bash a loro volta); tuttavia, i potenziali comandi indesiderati vengono eseguiti con gli stessi privilegi d’accesso del server web;
  • server DHCP che invocano script da shell per configurare il sistema; solitamente, tali script vengono eseguiti con privilegi di root, il che è estremamente pericoloso;
  • vari demoni o i programmi SUID che agiscono sul sistema con privilegi da superutente utilizzando però variabili settate da utenti non root.

In generale, il sistema può rimanere vittima di qualsiasi altra applicazione che venga eseguita da shell o esegue uno script shell che prevede l’interprete bash – solitamente, tali script iniziano con la dicitura #!/bin/bash.

Ma non finisce qui: purtroppo qualsiasi altro dispositivo obsoleto è a rischio, specie quelli per cui non è prevista la verifica della versione di Bash installata e per cui non sia possibile procedere semplicemente all’aggiornamento. Ancora una volta, ciò rappresenta un rischio ma non è detto che tali dispositivi siano effettivamente exploitabili (ad esempio, è difficile fare in modo che un computer di bordo o un NAS non collegato ad Internet eseguano codice arbitrario).

Per correttezza, è bene specificare ancora una volta che alcune versioni di Android e di Mac OS X sono vulnerabili – ad esempio, Mavericks lo è.


 

Quali dati sono a rischio e come faccio a proteggermi?

Purtroppo, anche se in precise e difficilmente coincidenti condizioni, ad essere a rischio è qualsiasi cosa sia presente sulla memoria del sistema; tenendo comunque conto dei meccanismi intrinsechi di protezione di Bash e di GNU/Linux come l’assegnazione dei permessi d’esecuzione, il margine di rischio potrebbe diventare comunque molto minore.

Prima di preoccuparsi, bisogna verificare se si è effettivamente vulnerabili a Shellshock. Ciò è possibile semplicemente verificando la versione di Bash installata sul proprio sistema: se questa non è precedente alla 4.3 - Bash 4.3.0 e inferiori sono VULNERABILI ma non le versioni successive – allora il vostro sistema non è vulnerabile. 

In caso contrario, se possibile aggiornate Bash ed i pacchetti dell’intero sistema operativo all’ultima versione disponibile, in attesa di un’eventuale patch che dovrebbe comunque essere rilasciata in maniera celere per la maggior parte dei sistemi operativi e dei pacchetti di Bash interessati, a prescindere dalla piattaforma su cui essi sono installati.

Per verificare di essere protetti, aprite una shell bash ed eseguite il test spiegato nella sezione “Cosa è Shellshock”.


 

In definitiva…

Purtroppo Shellshock è un bug che cade come un fulmine a ciel sereno e non è possibile affermare che sia innocuo poiché, come visto fino ad ora, i rischi materiali esistono.

Come vi ho detto all’inizio non bisogna comunque farne una pandemia: se si tratta di sistemi operativi casalinghi, è necessario accertarsi che il proprio OS sia ancora ufficialmente supportato ed aggiornarlo all’ultima versione disponibile, che si tratti di GNU/Linux o di Mac. Stessa cosa per i sistemi operativi server, per i quali ci si aspetta una “correzione” dei pacchetti relativi alle versioni di Bash pari o inferiori alla 4.3 quanto prima.

Discorso differente va fatto per i vari sistemi embedded, per i NAS, per i router o per tutti quei dispositivi non verificabili facilmente: accertatevi di avere installata l’ultima versione disponibile del firmware e, nel caso, contattate il produttore per ulteriori delucidazioni.

Shellshock è purtroppo un bug molto grande, reso enorme dalla diffusione di Bash, tuttavia gli eventuali danni possono essere arginati usando un po’ di prudenza ed attenzione in più.

Purtroppo, come disse il grande Spaf, la verità è soltanto una:

L’unico vero sistema sicuro è quello spento, gettato in una colata di cemento, sigillato in una stanza rivestita da piombo e protetta da guardie.
Ma anche in quel caso ho i miei dubbi.

 

fonte: (http://www.chimerarevo.com/linux/shellshock-bash-bug-terrorizza-rete-quanto-pericoloso-176876/)

Heartbleed, una delle più grandi falle nella sicurezza della Rete.

Heartbleed è il nome assegnato a una vulnerabilità “zero day” che riguarda OpenSSL, il sistema per criptare le comunicazioni in Internet usato da oltre due terzi dei siti web mondiali, e permette il furto di password e dati sensibili; fino ad oggi considerato uno dei sistemi più sicuri. Ecco tutto quello che c’è da sapere…

Aggiornamento alla mattina del 10 aprile: si consiglia di cambiare password, anche solo a titolo precauzionale, agli account sui siti di Google, Facebook, Yahoo, Tumblr, Dropbox, che hanno già riparato la falla. Su Mashable una lista con spiegazione dettagliata di dove e perché cambiare password, PayPal invece sostiene di non essere stata affetta e che gli utenti non dovrebbero neppure cambiare password (operazione che comunque è sempre consigliabile, ma assicuratevi prima che il servizio in questione abbia chiuso la falla).

Vanno anche aggiornati i software dei wallet e cambiate le password di molti servizi Bitcoin. LocalBitcoins, Blockchain.info, Bitfinex hanno chiuso la falla. Bitstamp aveva sospeso le operazioni, e ora le ha riaperte.

Più che un cuore sanguinante è una carneficina. Heartbleed, una gravissima vulnerabilità che compromette buona parte dei sistemi e dei servizi usati per crittografare il traffico internet, è già stata ribattezzata l’epic falla (dall’espressione epic fail). Da lunedì sera, quando è stata rivelata al mondo, amministratori di sistema e IT manager si sono trovati a gestire una situazione di emergenza, i cui potenziali effetti catastrofici (e del resto, bug catastrofico è stato definito dall’esperto di crittografia Bruce Schneier) sono ancora tutti da capire. Ma vediamo punto per punto di che si tratta e cosa sta succedendo.

La “falla” (oppure “bug”)
Heartbleed è il nome assegnato a una vulnerabilità zero day (CVE-2014-0160) che riguarda OpenSSL, il sistema usato per criptare le comunicazioni internet usato da due terzi dei server e fino ad oggi considerato uno dei sistemi più sicuri. La falla – e questa è una pessima notizia – esiste da due anni, dal dicembre 2011, ed è stata messa a posto in questi giorni nella versione OpenSSL 1.0.1g.  Le versioni vulnerabili di OpenSSL vanno dalla 1.0.1 alla 1.0.1f, mentre non lo sono OpenSSL 1.0.0 e 0.9.8.

Aspetta: cosa sarebbe OpenSSL?
Una implementazione open source di SSL e TSL, i due protocolli che garantiscono la sicurezza delle comunicazioni e transazioni di gran parte di ciò che sta sul web. Avete presente https nel browser, insomma il lucchetto che compare con l’online banking, Gmail e molti altri servizi che devono proteggere (leggi: cifrare) le loro comunicazioni? Ecco è un esempio.

Chi ha scoperto la falla?
La falla è stata individuata da un ingegnere di Google, Neel Mehta, e da alcuni ricercatori di Codenomicon, che hanno poi creato un sito ad hoc, appunto Heartbleed. Non senza qualche polemica riguardo a come la falla è stata comunicata.

Chi ne è colpito?
Molti sistemi operativi sono vulnerabili, tra cui Debian Wheezy, Ubuntu 12.04.4 LTS, CentOS 6.5, Fedora 18, OpenBSD 5.3, FreeBSD 8.4, NetBSD 5.0.2 and OpenSUSE 12.2. Ma al di là di questo, il punto è che OpenSSL gira su due dei web server più usati, Apache e nginx, così come server mail, servizi di chat, VPN e altri servizi. Ora immaginate che il lucchetto per blindare il traffico e le comunicazioni con tutti questi servizi sia potenzialmente apribile da chiunque conosca la falla e vi renderete conto della enormità del problema.

Quali aziende web sono interessate?
Fornitori di servizi, social media, webmail, online banking sono potenzialmente tutti interessati. In particolare: Apple, Microsoft, Twitter, Facebook e Google NON sembra siano state colpite dalla vulnerabilità, al contrario di Yahoo, che è stata esposta dal bug. Gli esperti di sicurezza hanno consigliato agli utenti di non entrare nei proprio account Yahoo in questo momento (il rischio era farsi rubare le credenziali da qualcuno che sfruttando la vulnerabilità sniffasse il traffico).
Tuttavia successivamente da Yahoo hanno fatto sapere che la vulnerabilità è stata messa a posto, quindi allo stato attuale i seguenti servizi sono tornati sicuri: Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr e Tumblr. Il consiglio rimane comunque dicambiare la propria password una volta loggati.
Fortunati gli utenti Google: poiché Gmail usa un avanzato sistema di protezione chiamato Perfect Forward Secrecy, i suoi utenti dovrebbero essere al sicuro anche per quanto riguarda le passate comunicazioni. Con l’occasione la Electronic Frontier Foundation ha consigliato di implementare Perfect Forward Secrecy – che protegge i dati cifrati, anche nel caso siano stati intercettati e salvati da qualche “spione”, e la chiave del sito sia successivamente compromessa – su più servizi possibili.

Qui si trova una lista di possibili siti interessati dalla falla, ma molti potrebbero aver già messo la toppa.

Il problema riguarda anche Tor, il software per l’anonimato, che ieri ha rilasciato una dichiarazione poco rassicurante: “Se avete bisogno di un anonimato e una privacy forte su internet, forse dovreste starre sconnessi per i prossimi giorni finché la situazione non si sistema“.
Tails – il sistema operativo live super sicuro e pro-privacy, basato su Linux (Debian)  – sarebbe invece al riparo.

Che fare? Upgrade, upgrade and revoke
La versione più recente di OpenSSL, 1.0.1g, chiude la falla, quindi ogni sito che usi OpenSSL dovrebbe aggiornare all’ultima releaseimmediatamente. Se un attaccante avesse usato la falla per entrare in un server web, avrebbe potuto accedere ai suoi gioielli:le chiavi di cifratura. Con queste avrebbe potuto decriptare il traffico da e al server; o impersonarlo, cioè far credere a un utente che sta visitando un certo sito mentre in realtà è un altro; o decifrare i database dei server, inclusi username, password, indirizzi email, informazioni sui pagamenti ecc

Quindi oltre ad aggiornare, è anche necessario che siti e servizi rigenerino le chiavi, revochino i loro certificati di cifratura e ne emettano dei nuovi. Qui si può controllare se un sito ha aggiornato i suoi certificati.

E’ possibile calcolare i danni di questa falla? Ed è già stata usata?
Non possiamo sapere se un sito è stato attaccato attraverso la falla (se non a posteriori nel caso escano fuori leaks o altro), non lascia tracce, diciamo. Inoltre non sappiamo se il bug è stato sfruttato, quanto e da quando. La situazione è del tipo: aggiorna, revoca, e incrocia le dita per il passato.

Cosa deve fare un utente?
Cambiare le password dei servizi che usano OpenSSL dopo che sono stati aggiornati. Aggiornare il proprio sistema, le distribuzioni Linux stanno rilasciando update in questo momento. Tenere sotto controllo i propri account.

fonte: http://www.wired.it/attualita/tech/2014/04/09/come-funziona-falla-heartbleed

Cybercrime – L’epidemia silenziosa

Il Cybercrime è un fenomeno criminale che si caratterizza nell’abuso della tecnologia informatica, sia hardware che software. Alcuni crimini in particolare sono finalizzati allo sfruttamento commerciale della rete, a porre a rischio i sistemi informativi di sicurezza nazionale.

A livello internazionale, molti governi ed agenzie non governative investono risorse nello spionaggio, nella truffa e in altri crimini transnazionali che coinvolgono interessi economici e politici. La difesa sociale internazionale è impegnata nell’individuare e denunciare tali attori alla Corte Internazionale dell’Aja.