Shellshock in profondità: Perché questa vecchia vulnerabilità non andrà via

Shellshock è un bug nella shell dell’interfaccia a riga di comando Bash che esiste da 30 anni ed è stato scoperto come una minaccia significativa nel 2014. Oggi, Shellshock rimane ancora una minaccia per le imprese.

La minaccia è certamente meno rischiosa rispetto all’anno della scoperta. Tuttavia, in un anno in cui le priorità della sicurezza si sono ricalibrate per tenere il passo con il panorama caotico, è un buon momento per guardare indietro a questa minaccia e ai fattori sottostanti che mantengono in vita questi attacchi oggi.

Perché Shellshock è rilevante nel 2020?

Shellshock è una vulnerabilità critica a causa dell’escalation dei privilegi concessi agli attaccanti, che permette loro di compromettere i sistemi a piacimento. Anche se la vulnerabilità ShellShock, CVE-2014-6271, è stata scoperta nel 2014, è noto che esiste ancora su un gran numero di server nel mondo. La vulnerabilità è stata aggiornata (CVE-2014-7169) poco dopo ed è stata modificata fino al 2018.

La ragione principale per cui Shellshock è ancora in uso non è uno shock. Questa vulnerabilità è un attacco semplice e poco costoso che i cattivi attori possono implementare contro un obiettivo inconsapevole. Le patch sono state disponibili fin dalla voce CVE, ma qualsiasi organizzazione senza un adeguato sistema di gestione delle patch in atto può essere ancora vulnerabile.

Shellshock era ancora in primo piano nel 2017. Quando tutti gli attaccanti hanno bisogno di alcune competenze di programmazione di base, un server e l’accesso al malware, non è sorprendente. Inoltre, il costo per effettuare un attacco non è molto più di pochi dollari al mese. La matematica è a favore degli attaccanti. Conoscenza minima, poco sforzo e basso costo equivalgono a una facile strategia di hacking.

Nonostante tutta la vasta copertura mediatica sulla cybersicurezza e persino un allarme del Dipartimento della Sicurezza Nazionale, alcuni sistemi rimangono senza patch. In un esempio, i funzionari del Center for Election Systems non sono riusciti ad applicare una patch che ha compromesso i sistemi elettorali della Georgia.

Come funziona Shellshock?

In termini profani, Shellshock è una vulnerabilità che permette ai sistemi contenenti una versione vulnerabile di Bash di essere sfruttata per eseguire comandi con privilegi superiori. Questo permette agli aggressori di prendere potenzialmente il controllo di quel sistema.

Inoltrandosi più a fondo nella tecnica, Shellshock è un bug di sicurezza nella shell Bash (GNU Bash fino alla versione 4.3) che fa sì che Bash esegua comandi bash non intenzionali da variabili di ambiente. Gli attori minacciosi che sfruttano la vulnerabilità possono emettere comandi in remoto sull’host di destinazione. Mentre Bash non è intrinsecamente rivolto a Internet, molti servizi interni ed esterni come i server web utilizzano variabili d’ambiente per comunicare con il sistema operativo del server.

Se questi input di dati non vengono sanificati – il processo standard di codifica che assicura che il codice non faccia parte dell’input – prima dell’esecuzione, gli attaccanti possono lanciare comandi di richiesta HTTP eseguiti tramite la shell Bash.

Vulnerabilità in dettaglio

I server web non sono le uniche risorse di rete vulnerabili. Anche i server di posta elettronica e i server DNS che usano BASH per comunicare con il sistema operativo potrebbero essere colpiti. Mentre BASH si trova normalmente su sistemi basati su Unix, le organizzazioni che utilizzano sistemi basati su Windows non sono immuni. Quelli stanno probabilmente sfruttando apparecchiature o hardware che sono vulnerabili. Ricordate, BASH può essere parte di router domestici, molti dispositivi IoT e sistemi embedded.

Shellshock può anche essere utilizzato per lanciare attacchi Denial of Service (DOS).

Ecco la linea di codice (una dichiarazione di funzione Bash seguita da un punto e virgola e il comando ‘sleep’ eseguito da tre possibili percorsi per garantire che venga eseguito):

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

Questo comando “sleep” forza il server ad aspettare venti secondi prima di rispondere. Così facendo, le risorse sulla macchina sono essenzialmente tenute in ostaggio perché la macchina non può fare altro per venti secondi.

Un comando “sleep” può essere innocuo, ma un attaccante può essere in grado di sostituirlo con del codice maligno. Poi, quel codice può ammanettare il server o la risorsa in modo che sia incapace di gestire qualsiasi richiesta.

Il rischio di permettere agli utenti Internet dannosi di eseguire comandi di loro scelta in remoto è alto. Usando l’apertura, i cattivi attori possono lanciare programmi sul sistema, creare connessioni in uscita verso i propri sistemi ed eseguire software dannoso.

Forse la cosa più critica è che la vulnerabilità può essere sfruttata per rubare dati riservati e informazioni memorizzate sul sistema, come i dettagli della carta di credito, le password e le informazioni personali identificabili (PII).

Shellshock è ancora dilagante?

Shellshock non è così diffuso come quando è stato scoperto nel 2014. Immaginate la sfida di dover patchare tutti i server vulnerabili della vostra azienda (e ce n’erano molti all’epoca).

Detto questo, Shellshock rimane un problema.

Per esempio, c’è una minaccia informatica in corso e una campagna di vulnerabilità chiamata “Sea Turtle” che sfrutta i record DNS per ottenere l’accesso a sistemi sensibili. Affinché gli attacchi abbiano successo, è necessaria una serie di vulnerabilità hardware e software comuni – Shellshock è una di queste.

Anche se non è più così dilagante come prima, ogni azienda dovrebbe assicurarsi che tutto l’hardware e il software siano applicati e aggiornati.

Come sapere se si è colpiti

Perché Shellshock ha sei anni, sono disponibili molti scanner di vulnerabilità. Alcuni di essi sono gratuiti. Uno, bashcheck, può essere scaricato usando Github.

Per quelle persone tecniche, anche digitare un semplice comando nel prompt di Bash farà il trucco:

env X=”() { :;} ; echo Bash è infetto” /bin/sh -c “echo completato”

env X=”() { :;} ; echo Bash è infetto” `che bash` -c “echo completed”

env VAR='() { :;}; echo Bash è infetto’ bash -c “echo completed”

Se il prompt restituisce un messaggio “Bash è infetto”, è ora di aggiornare e correggere. Se il tuo output non restituisce “Bash è infetto”, risponderà con qualcosa come:

bash: warning: VAR: ignora il tentativo di definizione della funzione

bash: error importing function definition for `VAR’

Bash Test

Se vuoi testare la vulnerabilità di siti web o specifici script CGI, il seguente strumento può aiutarti: ‘ShellShock’ Bash Vulnerability CVE-2014-6271 Test Tool. In uno dei due campi di input, inserire l’URL del sito web o dello script CGI che si desidera testare e fare clic sui pulsanti blu.

Cosa possiamo imparare sulle minacce alla sicurezza informatica

La più grande lezione per l’impresa qui – e vale la pena ripeterla – è di applicare le patch ai sistemi.

Le squadre che possono ridurre i tempi di patch sono in una posizione migliore per spostare quelle risorse a problemi di sicurezza più pressanti. Mentre alcune aziende considerano la gestione delle patch più una responsabilità IT che di sicurezza, la gestione delle patch deve essere sempre in cima alla mente dei dipartimenti di sicurezza in quanto è fondamentale per la postura di sicurezza di un’azienda.

Se i vostri sistemi sono ancora vulnerabili oggi, ci sono probabilmente alcuni problemi operativi sottostanti che dovrebbero essere affrontati. Shellshock è una vulnerabilità molto vecchia con patch disponibili per quasi tutti i sistemi. Il modo migliore per proteggersi da questo tipo di vulnerabilità è quello di mantenere i sistemi aggiornati, applicando tutte le correzioni rilasciate per questo exploit.

Quando si applicano le patch alle risorse, in genere un processo semplice, si dovrebbe abbracciare un approccio strategico.

Le patch testate a fondo sono un ottimo modo per minimizzare l’impatto aziendale – come un server mission-critical che esegue un vecchio sistema operativo, per esempio. Se un sistema non può essere patchato immediatamente, il rischio potenziale della vulnerabilità deve essere soppesato rispetto all’impatto aziendale.

Shellshock è solo una di una lunga lista di vulnerabilità con cui l’azienda deve fare i conti. Gestire il flusso apparentemente infinito di vulnerabilità è e sarà sempre una strategia critica alla base della cybersecurity.

Lista di controllo per un’organizzazione sicura

Per una gestione delle vulnerabilità di successo, le aziende devono avere la capacità di avere successo in queste tre aree:

• Identificare rapidamente le vulnerabilità di potenziale impatto: La velocità è tutto qui. Avere tutti sulla stessa pagina con un piano solido dovrebbe promuovere tempi di reazione più rapidi.
• Determinare il livello di gravità della vulnerabilità: Conoscere la tolleranza al rischio della vostra organizzazione vi aiuterà a determinare quanto grave possa essere una vulnerabilità. A seconda della vostra infrastruttura di rete, alcune vulnerabilità sono più dannose di altre.
• Avere un piano d’azione che bilanci l’urgenza della sicurezza con il potenziale impatto sugli ambienti di produzione: Bilanciare la sicurezza con la produzione e la produttività è un ostacolo costante, ma le organizzazioni con i piani più ben definiti per la gestione delle vulnerabilità in genere trovano il miglior equilibrio.

Per il ricercatore di sicurezza indipendente Rod Soto, la più grande lezione appresa da Shellshock è stata che Internet si basa su molte applicazioni vulnerabili e porta sempre il potenziale per compromettere una grande parte dei suoi segmenti.

“Il modo per gestire queste potenziali vulnerabilità in futuro è quello di mantenere la comunicazione aperta e trasparente tra sviluppatori, manutentori e professionisti della sicurezza”, dice Soto. “Quindi, se viene trovata una vulnerabilità così estesa e significativa, il coordinamento tra tutte le parti interessate può essere utilizzato per applicare una patch o mitigare i sistemi interessati.”

Anche nei casi in cui la vostra azienda ha successo nel mitigare il rischio di Shellshock o qualsiasi altra vulnerabilità, non si può presumere che il vostro piano di risposta sia perfetto. Il piano di risposta dovrebbe essere un documento che vive e respira, e dovrebbe essere rivisto spesso in modo che la vostra organizzazione possa rispondere rapidamente alle minacce.

Infine, come in qualsiasi scenario post-attacco, ci sono domande che dovreste porvi mentre rivedete ogni fase del piano.

• Quali parti del piano hanno avuto successo?
• Quali parti del piano non hanno avuto successo?
• Cosa non abbiamo fatto che ora sappiamo di dover fare?
• Cosa abbiamo imparato che ci permette di essere più preparati per la prossima vulnerabilità che ci si presenta?

Shellshock può essere un vecchio attacco, ma per un attaccante, ha tutte le carte in regola per sfruttare le vittime che mancano di una corretta igiene di sicurezza.