Altri dettagli su Shellshock, la falla sui sistemi Linux

Tutti, in queste ore, stanno parlando di Shellshock, la vulnerabilità che affligge la shell Bash dei sistemi Linux e Unix-like. La Bash è un po´ l’equivalente di explorer.exe in Windows e consente all’utente ed agli script di interagire con il sistema operativo.

Nella giornata di ieri abbiamo tempestivamente dato conto della problematica: Shellshock, a rischio milioni di sistemi Linux.

Torniamo però sull’argomento del bug della Bash e su Shellshock perché, nelle ultime ore, si è innescata una girandola di commenti.

Ad integrazione di quanto riportato ieri, è bene precisare che non tutti i sistemi che utilizzano la bash possono essere automaticamente ritenuti, all’atto pratico, vulnerabili.

– Come può, qualcuno, eseguire comandi da remoto su una shell locale?
Se la bash funziona localmente, come può un agressore sfruttare una sua vulnerabilità per eseguire comandi arbitrati? Sebbene bash sia vulnerabile, sono tre le differenti modalità con cui la vulnerabilità può essere esposta all’esterno:

1) HTTP: nel caso in cui sul server siano utilizzato script cgi-bin che utilizzano la bash (non è necessario che tali script vengano eseguiti dalla directory cgi-bin
2) DHCP: è il protocollo comunemente utilizzato per l’assegnazione dinamica degli indirizzi IP ai client che si collegano. In Linux i client DHCP impostano delle variabili d’ambiente sulla base dei dati ricevuti da parte del server DHCP. Un server DHCP malevolo può trasmettere ai client, quindi, i comandi da eseguire. Il problema, in questo caso, è particolarmente importante perché i comandi vengono eseguiti con i diritti di root.
Si pensi ad un hotspot Wi-Fi ostile: questo può essere in grado di provocare l’esecuzione di comandi arbitrati sui sistemi Linux e derivati che via a via si collegheranno richiedendo l’assegnazione di un IP. Una dimostrazione di questo tipo d’attacco è stata pubblicata da TrustedSec.
3) SSH: Utilizzando SSH, protocollo di rete che consente di stabilire una sessione di lavoro remota basata sulla riga di comando, l’utente può richiedere l’impostazione di alcune variabili d’ambiente utilizzabili anche per bypassare le limitazioni imposte dall’amministratore del sistema vulnerabile.

– Come verificare la presenza della vulnerabilità nella Bash

Chi amministra un server Linux è bene provveda immediatamente all’installazione delle patch di sicurezza disponibili per le varie distribuzioni ed a verificare, in ogni caso, la presenza della vulnerabilità battezzata Shellshock.

Per verificare se il proprio sistema risulta vulnerabile, si può digitare – all’interno della finestra del terminale – il comando che segue:

env x='() { :;}; echo VULNERABILE' bash -c 'test'

Nel caso in cui il sistema in uso risultasse vulnerabile, apparirà il seguente output:

env x='() { :;}; echo VULNERABILE' bash -c 'test'
VULNERABILE
test

La semplice esecuzione dei comandi sudo apt-get install bash o sudo yum update bash, a seconda della distribuzione in uso, dovrebbero permettere di tappare la falla Shellshock.

Ripetendo il test, in caso di sistema non vulnerabile, dovrebbe apparire quanto segue:

env x='() { :;}; echo VULNERABILE' bash -c 'test'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
test

Per effettuare dei test su indirizzi IP remoti, è possibile utilizzare i seguenti tre test: [1]; [2]; [3] (alcuni di essi potrebbero non funzionare correttamente in seguito all’elevato numero di richieste).

– C’è davvero da preoccuparsi?

Sucuri getta acqua sul fuoco: se è vero che i sistemi Linux dovrebbero essere patchati prima possibile, anche perché i primi attacchi stanno già cominciando ad aver luogo, a rischio sono più che altro coloro che utilizzano mod_cgi e script CGI. Inoltre, chi utilizza cPanel, pannello di controllo grafico per la gestione e l’amministrazione di siti internet e web hosting, potrebbe essere egualmente a rischio.

Come riportato da Robert Graham di Errata Security, inoltre, la vulnerabilità Shellrock è “wormable” ossia può essere sfruttata per attivare la scansione di gruppi di indirizzi IP, alla ricerca di altre macchine vulnerabili, e per provocare ulteriori infezioni – capaci di diffondersi in maniera automatizzata -.

Chi volesse approfondire ulteriormente l’analisi tecnica, può documentarsi a questo indirizzo.