Bash Shellshock quando un bug compromette il mondo

Si lo sò se nè parlato tanto di questo bug ma vedendo le testate giornalistiche dei quotidiani italiani l’ignoranzità quotando vegeta è di questo tipo:

it__s_over_9000_by_hellknight10-d256p79

Facciamo qualche esempio:

Per avere un responso da google molto interessante date un’occhiata a questo link.

Vediamo di capire un attimo il problema di questo bug. Si perchè a discapito dei titoli non è un virus ma è un bug. Si l’hanno messo nel titolo ma poi negli articoli si riferiscono ad un bug. Si l’hanno fatto per l’effetto OHMAMMAMIAHOUNVAIRUS.

54753255

Un’pò di storia ShellShock era il termine usato nella Prima Guerra Mondiale per definire lo stress da combattimento e il disturbo post traumatico da stress.

Che è la cosa che è successa a tutti i possessori di un sistema Unix (anche windows se si ha cygwin).

54782438La prima cosa che ho fatto è stata di provare la vulnerabilità e poi di aggiornare i miei computer e la mia VPS.

Dopo ho voluto studiare la questione e per spiegare la vulnerabilità ho trovato questo diagramma della Symantec. Si quelli di Norton. Si uno dei peggiori antivirus, ma il diagramma è fatto bene.

shellshock-command-diagram

  • env imposta la variabile a livello globale
  • Creiamo una variabile
  • Mettiamo dei caratteri che creano dei problemi al parser di bash
  • In coda mettiamo il comando che vogliamo eseguire
  • Dopo mettiamo un comando vero

Detto così serve poco a niente ma vediamo cosa può fare a livello locale con uno screen della IBM

shellshock

Praticamente mettiamo la variabile a livello globale che venendo chiamata con export sarà eseguita senza restrizioni.

In questo modo potremo fare tutto quello che ci pare e richiedere anche i permessi di root se conosciamo la password.

Un altro modo di usarlo è passare questa riga di bash negli header di una pagina web. In questo modo se Apache è stato avviato da bash in alcune occasioni il bug potrebbe uscire dal web server e permetterebbe di scaricare uno script nel sistema e di eseguirlo. Che effettivamente è già successo.

Un altro metodo è quello di iniettare il codice in una configurazione DHCP da remoto che poi sarà eseguito sul server, come si può leggere qui. Questo esempio di vulnerabilità è stata inserito in MetaSploit.

Dopo qualche tecnicismo (e mi sono contenuto) su internet si discute se ShellShock è più pericoloso di HeartBleed.

HeartBleed come da diagramma su Wikipedia:

Simplified_Heartbleed_explanation.svgCome si può vedere HeartBleed permetteva di ottenere delle informazioni facendo una richiesta che il server non si aspettava.

ShellShock permette di eseguire codice bash senza restrizioni a seconda del metodo di attacco e dei permessi di esecuzione.

Potenzialmente HeartBleed è più pericoloso perche permetteva di ottenere informazioni senza problemi di restrizione o permessi di esecuzione mentre ShellShock a seconda del metodo di attacco e della configurazione del sistema può avere danni lievi o giganteschi.

Potenzialmente HeartBleed è più pericoloso ma SheelShock combinato con più exploit può esserlo ancora di più.

Considerando che questa vulnerabilità di Bash esiste della versione 1.1.4 dal 1994 può avere degli effetti esponenziali nel tempo ma come ho detto l’azione di questo bug può essere pericoloso solo a seconda della configurazione e di exploit combinati.

Il mondo dei ricercatori ha iniziato subito a fixare il bug del parser rilasciando diverse versioni di bash ma i programmatori hanno trovato altri modi in cui sfruttare il bug. Questo perchè usando alcuni caratteri o sintassi di bash usati in modo improprio sono stati rilevati altri bug.

Al momento siamo a quattro varianti che potete approfondire sulla storia ed i metodi sulla pagina dedicata su Wikipedia.

La comunità si è data da fare per creare degli scanner, il migliore al momento è shellshocker.net che contiene l’elenco di comandi.

Ho potuto verificare che il mio sistema anche se è aggiornato all’ultima versione su Debian sid è debole a due dei comandi presenti.

La domanda di oggi è L’Open Source è meglio per la sicurezza?

Opensource-What-is

Grazie all’open source possiamo sapere che questa vulnerabilità esiste dal 1994, per lo stesso motivo i produttori stanno aggiornando tutti i loro prodotti e sistemi. Per lo stesso motivo nello stesso giorno sono state individuate 4 vulnerabilità e rilasciate due patch di sicurezza.

In ambiti closed sarebbe stato più difficile avere un tale responso dal mondo sia per informazioni che alternative di attacco.

Inoltre questi aggiornamenti sono gratis, di solito i prodotti closed dopo qualche anno perdono gli aggiornamenti di sicurezza.

Certo essendo un programma presente in tutto il mondo open ha un’effetto esponenziale per la gravità ma anche per la sua risoluzione.

Inoltre è possibile effettuare l’aggiornamento in più modalità rispetto ad altri ambiti in cui non sai cosa fà di preciso il sistema.

Concludendo il bug è grave, ma può essere sfruttato solo combinando più tecniche dopo un’analisi avanzata e quindi una sua identificazione sarebbe più facile visto proprio l’analisi per sfruttarlo al meglio. Sulla rete sono stati già creati dei tool per la scansione, identificazione ed aggiornamento automatico dei sistemi in caso di sistema vulnerabile.

Era doveroso fare un’altra analisi sulla questione, su HeartBleed non ho mai detto niente ritenendo il problema molto circostanzialeperchè può avere ripercussione solo sui sistemi con accesso ssh.

Bash invece è presente praticamente in tutti i web server come in tutti i server quindi per me ha un pericolo maggiore mitigato solamente da quello che ho ripetuto sopra.

Liked it? Take a second to support Mte90 on Patreon!
Become a patron at Patreon!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *