Shellshock: la vulnerabilità Bash che ha scosso il mondo Unix

Analisi di Shellshock (CVE-2014-6271), la vulnerabilità in Bash che ha esposto milioni di sistemi Unix. Scopri attacco, impatto e difese.

Nel mondo digitale, molte tecnologie largamente collaudate vengono considerate sicure e inattaccabili. Sono usate, integrate e replicate all’infinito. Quel che manca è porsi una domanda fondamentale: “Cosa c’è davvero sotto?”
Comandi, variabili, ambienti di esecuzione passano inosservati, in quanto non vi è mai alcuna trasparenza in termini di funzionamento puro. Il problema risiede proprio qui, poiché le insidie più gravi dipendono proprio da ciò che non si vede.

1. Cos’è Shellshock?
2. Come funziona Shellshock?
3. Impatto e conseguenze
4. Best practices contro Shellshock e vulnerabilità derivanti

Molte vulnerabilità non sono frutto di exploit sofisticati, né tantomeno di attacchi distribuiti. Nascono, infatti, da errori logici, ereditati nel tempo, che mettono in discussione l’affidabilità stessa dell’infrastruttura alla base del sistema. Quando questi errori si annidano in componenti cruciali, allora le conseguenze finiscono per essere a dir poco disastrose. Lo scenario appena descritto, riporta alla mente quanto accaduto nel 2014, anno in cui una vulnerabilità gravissima ha scatenato il caos in sistemi Unix e Linux di tutto il mondo.

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

Cos’è Shellshock?

Quando si nomina Shellshock, ci si riferisce a una vulnerabilità critica intrinseca alla shell Bash, ampiamente usata nei sistemi Unix e Linux. Scoperta il 12 settembre 2014 e divulgata il 24 settembre, si tratta di una falla di tipo ACE (Arbitrary Code Execution), poiché permette l’esecuzione di comandi arbitrari attraverso varaibili d’ambiente appositamente modificate. In altre parole, un attaccante è in grado di sfruttare il modo con cui Bash gestisce le definizioni di funzione, arrivando a compromettere interi servizi di rete. Poiché i web server e SSH impiegano proprio Bash per l’elaborazione delle richieste, è chiaro come milioni di sistemi siano stati esposti ad attacchi imprevedibili.

Shellshock è stata in seguito rinominata CVE-2014-6271 e classificata con un punteggio di 9.8 su 10 sulla scala CVSS v.3.1 (Common Vulnerability Scoring System), che indica una vulnerabilità critica. In seguito, sono emerse alcune varianti correlate, identificate con diversi codici CVE e che hanno richiesto svariate patch correttive per evitare il rischio di esposizione. Tra quelle più note si citano:

• CVE-2014-6277;
• CVE-2014-7169;
• CVE-2014-7169;
• CVE-2014-7187;

A seguito della sua scoperta e divulgazione, molte organizzazioni si sono viste costrette a rivedere le proprie pratiche di sicurezza. Ciò ha incluso, all’interno dei loro protocolli, la necessità di gestire in maniera oculata le librerie di sicurezza, unita a una revisione rigorosa del codice dei principali sistemi di protezione.

Come funziona Shellshock?

Per comprendere la reale portata di Shellshock, procederemo ad analizzarne il suo funzionamento attraverso una simulazione d’attacco. Questa sarà suddivisa in più fasi e, per ciascuna di esse, saranno riportati strumenti e metodologie atte a sfruttare appieno la vulnerabilità.
Iniziamo.

Individuazione del bersaglio

L’attacco ha inizio con una ricognizione mirata per identificare sistemi che utilizzano versioni vulnerabili di Bash. Attraverso il sempreverde Nmap e il relativo script http-shellshock, o mediante scanner personalizzati, l’attore malevolo va a caccia di servizi esposti. I suoi bersagli sono web server impieganti CGI, SSH o DHCP, che potrebbero essere vulnerabili all’exploit. Una volta individuato il bersaglio ideale, procede alla fase successiva.

Invio di richieste malformate

Con il bersaglio a portata di mano, l’attaccante procede a inviare una serie di richieste HTTP malformate. Ciascuna di esse contiene una variabile d’ambiente con una definizione di funzione, a cui seguono comandi arbitrari. Un esempio del genere è il seguente:

User-Agent: () { :;}; /bin/bash -c “comando_malevolo”

Durante l’elaborazione della richiesta da parte del server vulnerabile, Bash finisce inesorabilmente per eseguire il comando_malevolo. Questo meccanismo è ciò che innesca l’esecuzione di codice arbitrario sul sistema target.

Accesso e persistenza

Garantitosi l’accesso al sistema senza alcuna autenticazione, l’attaccante è adesso libero di agire indisturbato. Al fine di garantirsi una certa persistenza all’interno del sistema, questi da inizio a una privilege escalation, sfruttando ulteriori vulnerabilità locali fino a ottenere i privilegi di root. Quindi procede all’installazione di una backdoor, in modo da garantirsi accessi futuri al sistema. Infine, con le credenziali ottenuti dal privilegio root, è libero di muoversi lateralmente nella rete interna, espandendo così la sua superficie d’attacco.

Impatto e conseguenze

Sin dalla sua prima divulgazione, Shellshock è stata rapidamente sfruttata per orchestrare campagne di attacco su larga scala. Infatti, la relativa semplicità e replicabilità del suo exploit ha permesso a migliaia di attori malevoli di compromettere sistemi Unix e Linux in tutto il mondo. Dai gruppi APT (Advanced Persistent Threat) ai singoli script kiddie.

Un esempio tristemente famoso è il malware wopbot, responsabile della creazione di una botnet costituita da centinaia di web server compromessi. Questi sono stati impiegati in attacchi DDoS contro infrastrutture critiche su scala mondiale. Tra le vittime più famose figurano Akamai Tecnhologies e perfino il Dipartimento della Difesa degli Stati Uniti d’America, che ha dovuto implementare misure straordinarie per contenere l’ondata di traffico malevolo.

Data la natura stessa della vulnerabilità, è sorta anche l’impossibilità di tracciare con precisione ogni attacco avvenuto nei mesi successivi alla scoperta. In molti casi, le violazioni sono rimaste silenziose per settimane, permettendo agli attaccanti di muoversi lateralmente nella rete, installare backdoor persistenti o esfiltrare dati sensibili senza lasciare traccia. Per cui, il danno non è stato solo nell’immediato, ma si è protratto nel tempo. Complice soprattutto l’elevata diffusione di sistemi legacy mai aggiornati.

Best practices contro Shellshock e vulnerabilità derivanti

Poiché si tratta di una vulnerabilità annidata in componenti di base, è necessario adottare misure concrete non limitate al singolo aggiornamento dei sistemi. Di seguito sono riportate una serie di best practices e suggerimenti per proteggere sé stessi e la propria organizzazione al meglio.

• Aggiornare immediatamente Bash su tutti i sistemi esposti.
  Le versioni affette devono essere sostituite con release patchate. In ambienti Linux-based, è consigliabile configurare automatismi per l’aggiornamento delle librerie di sistema, soprattutto se si gestiscono server accessibili da remoto.
• Bloccare l’accesso alle interfacce non necessarie.
  Qualsiasi servizio che richiama Bash da input esterni, come CGI su web server, deve essere disattivato o isolato, a meno che non sia strettamente indispensabile. Ridurre i punti d’ingresso è essenziale per contenere la superficie d’attacco.
• Analizzare il traffico in entrata con IDS/IPS configurati correttamente.
  Sistemi come Suricata o Snort devono includere regole aggiornate per il rilevamento di exploit Shellshock. Una corretta configurazione può bloccare richieste sospette prima che raggiungano l’applicazione target.
• Monitorare le variabili d’ambiente nei processi critici.
  L’esecuzione di comandi tramite input malformato può essere intercettata tramite audit dei processi e dei log di sistema. L’analisi comportamentale dei processi Bash può anticipare l’escalation di attacchi in corso.
• Condurre vulnerability assessment periodici.
  Testare l’ambiente alla ricerca di Shellshock e di varianti correlate, è una misura preventiva obbligatoria. Nessuna patch è efficace se il sistema target non viene periodicamente analizzato.

In conclusione

Come spesso accade con vulnerabilità del genere, Shellshock ha rappresentato una svolta nel panorama della sicurezza informatica. Questo perché interi sistemi considerati affidabili da anni, sono stati messi in ginocchio pesantemente. Il suo impatto ha finito per mettere il mondo IT faccia a faccia con una verità scomoda: nessuna componente può dirsi sicura solo perché è collaudata nel tempo.

La fiducia cieca nei sistemi legacy e nel codice non aggiornato, ha finito per far pagare a tutti un prezzo carissimo. Tutt’oggi Shellshock ha una lezione importantissima da ricordarci: la vera consapevolezza informatica risiede nell’aggiornamento e nel monitoraggio costante. Ecco perché non dobbiamo mai abbassare la guardia e chiederci costantemente se il sistema da noi usato sia davvero sicuro.

Il nostro mondo digitale è più affascinante di quanto possiamo immaginare, ma anche più pericoloso di quanto possiamo credere.