Come verificare se il mio server è vulnerabile al bug ShellShock?


80

Come posso garantire che la mia installazione di Bash non sia più vulnerabile al bug ShellShock dopo gli aggiornamenti?



Si noti che ci sono altre due vulnerabilità in bash ancora prive di patch (CVE-2014-7186 e CVE-2014-7187).
Deer Hunter,

Le patch che correggono CVE-2014-7186 e CVE-2014-7187 sono disponibili non molto tempo dopo che Deer Hunter ha pubblicato il suo commento. Se hai una patch fornita dalla distribuzione per CVE-2014-7169 potresti già avere abbastanza per bloccare 7186/7187, testare il sistema con i comandi seguenti e vedere. Controlla anche eventuali altri aggiornamenti di sicurezza per la tua distribuzione.
BeowulfNode42

Risposte:


83

Per verificare la vulnerabilità CVE-2014-6271

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

NON deve restituire la parola vulnerabile.


Per verificare la vulnerabilità di CVE-2014-7169
(avviso: se il tuo non riesce, creerà o sovrascriverà un file chiamato /tmp/echoche è possibile eliminare dopo, ed è necessario eliminare prima di ripetere il test)

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

dovrebbe dire la data data quindi lamentarsi con un messaggio come cat: echo: No such file or directory. Se invece ti dice qual è il datetime corrente, allora il tuo sistema è vulnerabile.


Per verificare CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

NON deve ripetere il testo CVE-2014-7186 vulnerable, redir_stack.


Per verificare CVE-2014-7187

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

NON deve ripetere il testo CVE-2014-7187 vulnerable, word_lineno.


Per verificare CVE-2014-6277. Non sono sicuro al 100% su questo in quanto sembra fare affidamento su un sistema parzialmente patchato a cui non ho più accesso.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

Un risultato positivo su questo è che riecheggia SOLO il testo testing CVE-2014-6277. Se esegue perl o si lamenta che perl non è installato, si tratta sicuramente di un errore. Non sono sicuro su altre caratteristiche di errore in quanto non ho più sistemi senza patch.


Per verificare CVE-2014-6278. Ancora una volta, non sono sicuro al 100% se questo test in quanto non ho più sistemi senza patch.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

Un passaggio per questo test è che dovrebbe ripetere SOLO il testo testing CVE-2014-6278. Se il tuo risuona hi momovunque, questo è sicuramente un fallimento.


1
Possiamo aggiungere il test generale foo='() { echo not patched; }' bash -c fooa questo? Fino a quando le esportazioni di funzioni non vengono inserite in uno spazio dei nomi separato, non smetteremo di eseguire da un bug del parser al successivo.
Billyw,

Quel test ha un CVE? Hai qualche riferimento per descrivere questo problema? Anche questo tipo di informazioni può appartenere a una delle altre domande sullo shellshock a causa di questa Q su come testare il successo o il fallimento delle patch esistenti.
BeowulfNode42,

È dal post del blog di Michal Zalewski su alcuni CVE Shellshock in arrivo ( lcamtuf.blogspot.com/2014/09/… ). È il suo test suggerito per CVE-2014-6278, che è ancora non pubblico. Sembra però che mi sia sbagliato sulla generalità del test; Ho già riscontrato un caso in cui il test di Zalewski è stato superato ma il test CVE-2014-7187 ha avuto esito negativo.
Billyw,

Ed ecco la piena divulgazione su CVE-2014-6277 e CVE-2014-6278, insieme ai comandi per verificarli: seclists.org/fulldisclosure/2014/Oct/9
billyw,

Un punto da notare: anche se la versione di BASH è vulnerabile, se nulla la utilizza (ovvero tutti gli account utilizzati dai demoni, come "www" o "tazze" o altro) sono configurati con BASH come shell predefinita e nessuno di i tuoi codici chiamano system () o simili, avere la versione vulnerabile potrebbe essere meno rischioso, ma comunque aggiornare BASH il prima possibile.
DTK,

32

Esporta una variabile d'ambiente appositamente predisposta che verrà valutata automaticamente dalle versioni vulnerabili di Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Ora esegui una semplice eco per vedere se Bash valuterà il codice in $ testbug anche se non hai usato tu stesso quella variabile:

$ bash -c "echo Hello"
VULNERABLE
Hello

Se mostra la stringa "VULNERABLE", la risposta è ovvia. Altrimenti, non devi preoccuparti e la tua versione patchata di Bash è OK.

Si noti che sono state rilasciate più patch dalle principali distribuzioni Linux e talvolta non risolvono completamente la vulnerabilità. Continua a controllare gli avvisi di sicurezza e la voce CVE per questo errore.


5
Oltre a CVE-2014-6271, la correzione incompleta di Red Hat in particolare ha una sua che vale anche la pena seguire: CVE-2014-7169 .
DocMax,

3
One-liner che non inquina il tuo ambiente shell e funziona anche se 'stai usando una shell di login alternativa (che potrebbe non sapere export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki,

1
Ci sono alcuni dettagli specifici di Ubuntu qui askubuntu.com/questions/528101/… - personalmente ho dovuto aggiornare da Ubuntu 13.10 a 14.04 per risolvere il problema
dodgy_coder,

2

ShellShock è praticamente una congiunzione di più di una vulnerabilità di bash , e in questo momento esiste anche un malaware che sfrutta questa vulnerabilità , quindi ShellShock può essere un problema ancora aperto, c'è un thread con gli aggiornamenti di RedHat su questi problemi .

Redhat raccomanda quanto segue:

Esegui comando:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

Se l'output è:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

non hai alcuna correzione.

Se l'output è:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

hai CVE-2014-6271risolto

Se l'output è:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

non sei vulnerabile.

L'altra parte del controllo ShellShock è il controllo di vulnerabilità CVE-2014-7169 che assicura che il sistema sia protetto dal problema di creazione del file. Per verificare se la tua versione di Bash è vulnerabile a CVE-2014-7169, esegui il comando seguente:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

Se il sistema è vulnerabile, verranno visualizzate l'ora e la data e verrà creato / tmp / echo.

Se il tuo sistema non è vulnerabile, vedrai un output simile a:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

2

Ho scritto un'utilità CLI chiamata ShellShocker per testare il tuo server web per le vulnerabilità sugli script CGI. Per testare il tuo sito, avresti eseguito:

python shellshocker.py <your-server-address>/<cgi-script-path>

vale a dire

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

EDIT: questa utility è stata rimossa, scusa: '(


Il tuo link è morto
SSK il

@SSK Siamo spiacenti;) Mistype.
Liam Marshall,

Il tuo link è ancora morto.
Mxx,

Sì, scusa, l'ho buttato giù. Era sfruttato in modi che non mi piacevano.
Liam Marshall,

1

Puoi inviare il tuo URL CGI a questo test online:

http://shellshock.iecra.org


4
È educato fornire ragioni per i voti negativi.
David,

4
"Registriamo tutte le scansioni" ??? Raccapricciante. Scaricherei Python ed eseguirlo da solo.
Brad,

1
@brad almeno te lo stanno dicendo. Sono sicuro che se stavo fornendo un servizio di sicurezza whitehat che offriva questo servizio, potrei tenere un registro (se solo un contatore senza dettagli individuali) di quante persone hanno inserito ciecamente i dettagli del loro sito in un sito web che diceva che stava andando tentare un test di penetrazione, senza sapere molto sull'autenticità del sito che offre il test ... e vorrebbero un registro di chi ha testato ciò nel caso in cui qualcuno avesse usato il proprio servizio per trovare siti vulnerabili appartenenti ad altri ...
Rob Moir,

-1

digitare env x = '() {:;}; echo vulnerable 'bash -c "echo this is a test" e se questo diventa vulnerabile e questo è un test significa che il tuo computer OSX / Linux è interessato. Il rimedio è aggiornare all'ultima versione di bash.


6
Perché come root? Completamente inutile
Mat
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.