Domanda:
C'è un breve comando per verificare se il mio server è protetto contro il bug bash di shellshock?
kqw
2014-09-25 16:24:08 UTC
view on stackexchange narkive permalink

Ho eseguito apt-get update; apt-get upgrade -y su tutti i sistemi in esecuzione. Non sono sicuro che il mio /etc/apt/sources.list sia abbastanza buono su tutti questi sistemi. Vorrei ricontrollare rapidamente ogni sistema, idealmente con un comando di shell a una riga.

Esiste un comando di shell di una riga di questo tipo e se sì, che cos'è?

Tieni presente che questa domanda riguarda principalmente CVE-2014-6271.

bash --version Il bug ha effetti sulle versioni di bash fino alla 4.3 inclusa
@raz Controllare la versione bash è inutile (tranne che le versioni successive alla 4.3, che non esistono ancora, non saranno interessate). La maggior parte dei sistemi risolverà il buco correggendo solo il buco (di solito applicando il normale processo di aggiornamento della loro distribuzione), non aggiornando a una versione completamente nuova di bash (che, ancora una volta, non esiste ancora).
@Gilles `bash --version` riporterà un numero di versione come` 4.3.25` (che è la patch che corregge la vulnerabilità Shell Shock iniziale, anche se non completa). Non c'è motivo di pensare che una versione a livello di patch sia meno in grado di correggere completamente il problema rispetto a qualche futura versione 4.4.
@chepner ... che è esattamente il motivo per cui controllare il numero di versione è inutile. Sulla maggior parte delle distribuzioni, l'aggiornamento che risolve il buco non cambia il numero di versione. La versione vulnerabile e la versione fissa hanno lo stesso numero di versione. Non è possibile utilizzarlo per sapere se la vulnerabilità è presente.
Sarei un po 'seccato se la mia distribuzione applicasse la patch al codice senza battere il numero di versione * del tutto *.
@chepner: perché? C'è una differenza tra la versione riportata dal programma e la versione del pacchetto. Beh, può esserci, mettiamola in questo modo.
Sì, ma il pacchetto può indicare una divergenza dall'upstream utilizzando i livelli di revisione. Se il gestore dei pacchetti decide di inviare una versione di `bash` 4.3.25 insieme alle proprie patch, la versione del pacchetto dovrebbe essere qualcosa come 4.3.25-1.0, 4.3.25-1.1, ecc, * non * 4.3.26, 4.3.27 o peggio, 4.3.25, 4.3.25 con * nessuna * modifica nella versione. Cambiare la versione del pacchetto è una cosa; calpestare lo schema di versioning dell'upstream (almeno, un upstream sano di mente) è un altro. L'intero * punto * di un numero di versione indica le modifiche nel codice sottostante.
Sei risposte:
#1
+124
Eliah Kagan
2014-09-25 18:43:04 UTC
view on stackexchange narkive permalink

La mia bash è vulnerabile?

Questo semplice comando è un test sufficiente per vedere se la tua versione di bash è vulnerabile:

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

Non è necessario stampare del testo extra per indicare che il comando è stato effettivamente eseguito, perché le versioni patchate di bash riporteranno un avviso quando una variabile al suo avvio l'ambiente contiene codice di exploit per la vulnerabilità corretta.

Su un sistema vulnerabile:

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

Su un sistema patchato:

  $ x =' () {:;}; echo VULNERABILE 'bash -c: bash: warning: x: ignora la definizione della funzione trybash: errore durante l'importazione della definizione della funzione per `x'  

Per una spiegazione dettagliata di cosa fa e fa non testare e perché, vedere "Altri bug di analisi delle funzioni" di seguito.

Il mio sistema è vulnerabile?

Se la tua bash non è vulnerabile, il tuo sistema non lo è non è vulnerabile.

Se la tua bash è vulnerabile, allora il tuo sistema è vulnerabile in quanto utilizza bash lungo vettori di attacco come script CGI, client DHCP e account SSH limitati. Controlla se / bin / sh è bash o qualche altra shell. La vulnerabilità è in una funzionalità specifica di bash e altre shell come dash e ksh non sono interessate. Puoi testare la shell predefinita eseguendo lo stesso test di cui sopra con sh invece di bash:

  x = '() {: ;}; echo VULNERABILE 'sh -c:  
  • Se vedi un messaggio di errore, il tuo sistema ha una bash patchata e non è vulnerabile.
  • Se tu vedi VULNERABILE , la shell predefinita del tuo sistema è bash e tutti i vettori di attacco sono un problema.
  • Se non vedi alcun output, la shell predefinita del tuo sistema non è bash e solo parti del tuo sistema che usa bash sono vulnerabili. Controlla:
    • Script eseguiti da bash (che iniziano con #! / Bin / bash , non #! / Bin / sh ) da CGI o da un Client DHCP.
    • Account SSH limitati la cui shell è bash.

Come funziona questo test

Esegue il comando bash -c: con il testo letterale () {:;}; echo VULNERABILE impostato come valore della variabile d'ambiente x.

  • Il builtin : esegue nessuna azione; è usato qui dove è richiesto un comando non vuoto.

  • bash -c: crea un'istanza di bash che esegue : ed esce.

    Anche questo è sufficiente per consentire l'attivazione della vulnerabilità. Anche se bash viene invocato per eseguire un solo comando (e quel comando è un no-op), legge comunque il suo ambiente e interpreta ogni variabile il cui contenuto inizia con () { come una funzione (in almeno quelli i cui nomi sono nomi di funzione validi) e lo esegue in modo che la funzione venga definita.

    L'intento dietro questo comportamento di bash è quello di eseguire solo una definizione di funzione, che rende una funzione disponibile per l'uso ma non in realtà non eseguo il codice al suo interno.

  • () {:;} è la definizione di una funzione che non esegue alcuna azione quando viene chiamata. È necessario uno spazio dopo { in modo che { venga analizzato come un token separato. È necessario un ; o un newline prima del } affinché venga accettato come sintassi corretta.

    Vedi 3.3 Funzioni di shell nel Bash Reference Manual per maggiori informazioni sulla sintassi per la definizione delle funzioni di shell in bash. Ma nota che la sintassi usata (e riconosciuta) da bash come una valida funzione di shell esportata la cui definizione dovrebbe essere eseguita è più restrittiva:

    1. Deve iniziare con la stringa esatta () { , con esattamente uno spazio tra ) e {.
    2. E sebbene le funzioni di shell occasionalmente abbiano la loro istruzione composta racchiusa in () invece di {} , vengono comunque esportate all'interno della sintassi {} . Le variabili i cui contenuti iniziano con () ( invece di () { non testeranno o attiveranno in altro modo la vulnerabilità.
  • bash dovrebbe interrompere l'esecuzione del codice dopo la chiusura di } . Ma (a meno che non sia patchato) non lo fa! Questo è il comportamento sbagliato che costituisce CVE -2014-6271 ("Shellshock").

    ; termina l'istruzione che definisce la funzione, consentendo la lettura e l'esecuzione del testo successivo come comando separato. E il testo dopo ; non deve essere un'altra definizione di funzione: può essere qualsiasi cosa.

  • In questo test, il comando dopo ; è echo VULNERABLE . Lo spazio iniziale prima di echo non fa nulla ed è presente solo per leggibilità. Il comando code> echo scrive il testo nello standard output. Il comportamento completo di echo è in realtà un po 'complicato, ma qui non è importante: echo VULNERABLE è semplice . Visualizza il testo VULNERABLE.

    Poiché echo VULNERABLE viene eseguito solo se bash non ha patch e esegue codice dopo le definizioni di funzione nelle variabili di ambiente, questo (e molti altri test simili ad esso) è un test efficace per verificare se il bash installato è vulnerabile o meno a CVE-2014-6271.


Altri bug di analisi delle funzioni (e perché quel test e quelli simili non li controllano)

La patch che è stata rilasciata al momento della stesura di questo documento, ei comandi descritti e spiegati sopra per controllare la vulnerabilità, si applicano al bug molto grave noto come CVE-2014-6271. Né questa patch né i comandi sopra descritti per il controllo della vulnerabilità si applicano al bug correlato CVE-2014-7169 (né si deve presumere che si applichino a qualsiasi altro bug che potrebbe non essere stato ancora scoperto o divulgato).

Il bug CVE-2014-6271 è nato da una combinazione di due problemi:

  1. bash accetta definizioni di funzioni in variabili di ambiente arbitrarie, e
  2. mentre lo fa, bash continua a eseguire qualsiasi codice esistente dopo la parentesi graffa di chiusura (} ) di una definizione di funzione.

Al momento della stesura di questo documento, la correzione esistente per CVE-2014-6271 che è stata rilasciata (e implementata da molti fornitori a valle), ovvero la correzione che si otterrebbe aggiornando il sistema o applicando la patch esistente manualmente: è una correzione per 2”.

Ma in presenza di altri errori nel codice di bash, 1 è potenzialmente una fonte di molti bug di analisi aggiuntivi. E sappiamo che esiste almeno un altro bug simile, in particolare CVE-2014-7169.

Il comando presentato in questa risposta verifica se oppure no una bash installata è patchata con la correzione esistente (cioè la prima ufficiale) per CVE-2014-6271. Verifica la vulnerabilità a quello specifico bug di analisi: "GNU Bash fino alla 4.3 elabora le stringhe finali dopo le definizioni di funzione nei valori delle variabili di ambiente [...]"

Questo bug specifico è estremamente grave - e la patch disponibile lo lo risolve - mentre CVE-2014-7169 sembra essere meno grave ma è sicuramente ancora motivo di preoccupazione.

Come Stéphane Chazelas ( scopritore del bug di Shellshock) ha recentemente spiegato in una risposta a Quando è avvenuto lo shellshock (CVE -2014-6271) bug introdotto e qual è la patch che lo risolve completamente? su Unix.SE:

C'è una patch che impedisce bash dall'interpretazione di qualsiasi altra cosa oltre alla definizione della funzione contenuta ( https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html), e questo è quello che è stato applicato in tutti gli aggiornamenti di sicurezza dalle varie distribuzioni Linux.

Tuttavia, bash interpreta ancora il codice e qualsiasi bug nell'interprete potrebbe essere sfruttato. Uno di questi bug è già stato trovato (CVE-2014-7169) sebbene il suo impatto sia molto minore. Quindi ci sarà presto un'altra patch.


Ma se questo è l'aspetto dell'exploit ...

Alcune persone , qui e altrove, hanno chiesto perché x = '() {:;}; echo VULNERABILE 'bash -c: la stampa di VULNERABILE (o simile) dovrebbe essere considerata allarmante. E di recente ho visto circolare l'idea sbagliata che poiché devi già avere accesso interattivo alla shell per digitare quel particolare comando e premere invio , Shellshock in qualche modo non deve essere una grave vulnerabilità.

Sebbene alcuni dei sentimenti che ho sentito esprimere - che non dovremmo precipitarci nel panico, che gli utenti desktop dietro i router NAT non dovrebbero mettere le loro vite in attesa per costruire bash dal codice sorgente - sono abbastanza corretti, confusi la vulnerabilità stessa con la possibilità di testarla eseguendo un comando specifico (come il comando presentato qui) è un grave errore.

Il comando fornito in questo post è una risposta alla domanda: "C'è un breve comando per verificare se il mio server è sicuro contro il bug bash di shellshock?" non è una risposta a "Che aspetto ha lo shellshock quando viene usato contro di me da un vero attaccante?" e non è una risposta alla domanda: "Cosa deve fare qualcuno per sfruttare con successo questo bug?" (E anche non è una risposta a "è esiste un semplice comando per dedurre da tutti i fattori tecnici e sociali se sono personalmente ad alto rischio? ")

Quel comando è un test, per vedere se bash eseguirà codice scritto, in un modo particolare, in variabili d'ambiente arbitrarie. La vulnerabilità Shellshock non è x = '() {:;}; echo VULNERABILE 'bash -c: . Invece, quel comando (e altri simili) è una diagnostica per aiutare a determinare se uno è influenzato da Shellshock.

  • Shellshock ha conseguenze di vasta portata, anche se è vero che il rischio è quasi certamente minore per gli utenti desktop che non utilizzano server di rete accessibili da remoto. (Quanto meno è qualcosa che non credo sappiamo a questo punto.)
  • Al contrario, il comando x = ' () {:;}; echo VULNERABLE 'bash -c: è del tutto irrilevante tranne per il fatto che è utile per testare Shellshock (in particolare, per CVE-2014-6271).

Per coloro che lo sono interessati, ecco alcune risorse con informazioni sul motivo per cui questo bug è considerato grave e sul perché le variabili di ambiente, in particolare sui server di rete, possono contenere dati non attendibili in grado di sfruttare il bug e causare danni:

Per illustrare ulteriormente la distinzione concettuale qui, si consideri due ipotetici:

  1. Immagina se invece di suggerire x = '() {:;}; echo VULNERABLE 'bash -c: come test, avevo suggerito bash --version come test. (Ciò in realtà non sarebbe particolarmente appropriato, perché i fornitori di sistemi operativi spesso eseguono il backport di patch di sicurezza su versioni precedenti del software. Le informazioni sulla versione fornite da un programma possono, su alcuni sistemi, far sembrare che il programma sia vulnerabile, quando in realtà lo è stato patchato.)

    Se venisse suggerito il test eseguendo bash --version , nessuno direbbe: "Ma gli aggressori non possono sedersi al mio computer e digitare bash --version , quindi devo stare bene! " Questa è la distinzione tra un test e il problema per cui viene eseguito il test.

  2. Immagina se venisse emesso un avviso che suggerisce che la tua auto potrebbe avere qualche problema di sicurezza, come un guasto o uno scoppio dell'airbag in fiamme in caso di collisione, e le dimostrazioni in fabbrica erano state trasmesse in streaming. Nessuno direbbe: "Ma non guiderei o rimorcherei mai accidentalmente la mia macchina per 900 miglia fino alla fabbrica e la caricherò con un costoso manichino da crash e sbatterò contro un muro di cemento. Quindi devo stare bene!" Questa è la distinzione tra un test e il problema per cui viene eseguito il test.

Hmm, ma se posso eseguire bash, non posso già eseguire comandi arbitrari su un sistema? In che modo questa è una vulnerabilità?
@Ajedi32 `x = '() {:;}; echo VULNERABLE 'bash -c: `è un test per vedere se il tuo bash è patchato. Il motivo per cui CVE-2014-6271 è un vuln è che dà il potere di eseguire comandi arbitrari a chiunque possa impostare il valore di una variabile di ambiente (in condizioni in cui una bash verrà eseguita con quella variabile impostata). Le variabili di ambiente vengono comunemente utilizzate per trasferire dati non disinfettati e forniti dall'utente tra i processi. Ad esempio, * questo è spesso sfruttabile tramite HTTP. * Vedi http://seclists.org/oss-sec/2014/q3/650 in "Finora, le richieste HTTP agli script CGI sono state identificate come il principale vettore di attacco."
@Ajedi32 `/ bin / sh -c` è molto usato per avviare processi figlio. Se l'ambiente può essere controllato da un aggressore, allora c'è un problema: il caso più comune è un server web che utilizza l'ambiente come una forma di [IPC] (http://en.wikipedia.org/wiki/Inter-process_communication) quando eseguire uno script CGI.
@mr.spuratic Il tuo esempio è `/ bin / sh -c` che non è` bash` ma solo il processo base della vanilla shell. Quindi non sto ancora correndo il vero rischio qui. Certo, questo è tutto un utilizzo non intenzionale. Ma se l'utente non può ottenere privilegi elevati oltre ciò che ha il processo genitore, il rischio è esattamente cosa?
Se bash non è la shell predefinita, non sarebbe più facile usare: bash -c "env x = '() {:;}; echo vulnerable' bash -c echo this is a test" oneliner?
@JakeGould La cosa peggiore di questa vulnerabilità è che per sfruttarla non è necessario disporre di un account. Anche se (ad esempio) il tuo server web funziona con un account utente strettamente limitato, sarebbe molto brutto per un attaccante essere in grado di eseguire comandi arbitrari come quell'utente limitato, controllando completamente il tuo server web (e altro). Vedi [la spiegazione qui] (http://seclists.org/oss-sec/2014/q3/650). I modi più convenienti per * testare * una vulnerabilità non sono sempre della stessa forma dei modi più devastanti per * sfruttarla in natura. *
@JakeGould È vero che "sh" è solo a volte "bash". Ci si può aspettare che questo mitighi in qualche modo il rischio / danno. Ma anche quando non è il sistema sh, bash è ampiamente utilizzato per lo scripting, quindi è ancora possibile eseguire codice arbitrario. I comandi dopo la definizione di una funzione in una variabile d'ambiente vengono eseguiti quando viene eseguito uno script bash (poiché l'esecuzione di uno script bash, in particolare da una shell o da un altro processo che non è bash, implica l'esecuzione dell'eseguibile bash per interpretarlo). Il grado di rischio per gli utenti desktop è sconosciuto, ma i dati dannosi (ad esempio file appositamente predisposti) elaborati tramite bash sono ancora un rischio.
@somelooser28533 Il chiamante non ha bisogno di essere bash per `env x = '() {:;}; echo vulnerable 'bash -c' echo ... '`, una qualsiasi [shell Bourne-style (POSIX)] (https://en.wikipedia.org/wiki/Unix_shell#Bourne_shell_compatible) o qualche altra shell che accetta` VARIABLE = valore` sintassi del comando. Con `env`, la shell potrebbe essere praticamente qualsiasi cosa, il che potrebbe essere il motivo per cui [il test BadSkillz cita] (http://security.stackexchange.com/a/68169) la usa. "sh -c" env x = '() {:;}; echo vulnerable' bash -c 'echo ...' "`, indipendentemente dal fatto che sh sia bash, funziona anche. Anche in una shell non in stile Bourne, non hai bisogno sia di `env` che di` sh -c`.
@EliahKagan Vedo il rischio per i server in determinate condizioni, ma se guardi i forum degli utenti Mac, ad esempio, c'è questo panico assoluto che Mac OS X a livello di client è a rischio. E onestamente non lo vedo. Ma apprezza il tuo punto di vista.
@EliahKagan "" È vero che sh è solo a volte bash. "" No, non è un problema "a volte". `bash` è bash e` sh` è la shell Unix standard. Se non capisci questo fatto incredibilmente semplice, non dovresti davvero avvisare nessuno su problemi di sicurezza.
@JakeGould Non esiste un programma che sia "la shell Unix standard". Sistemi operativi differenti usano shell differenti per `/ bin / sh`. Su GNU / Linux `sh` di solito è un collegamento o una copia di qualche altra shell. [In Ubuntu e Debian, `dash` fornisce` sh`, sebbene `bash` lo facesse negli anni passati.] (Https://wiki.ubuntu.com/DashAsBinSh) Su alcuni sistemi operativi,` sh` rimane `bash`. (Credo che Slackware sia un esempio, anche se non l'ho usato di recente.) Una rapida ricerca sul web, [o Wikipedia] (https://en.wikipedia.org/wiki/Bourne_shell#Usage), ti avrebbe salvato da il tuo malinteso e mi ha salvato dalla tua falsa accusa di ignoranza.
@EliahKagan Sono corretto. Ma "dash" semplicemente non è "bash" e onestamente penso che il panico attorno a "shellshock" causerà più problemi dell'exploit stesso.
Ho appena corretto il mio server e ora ottengo l'errore dopo aver eseguito il comando sopra. Ciò significa che sono ancora vulnerabile a CVE-2014-7169 che afferma che la correzione per lo shock da shell 6271 è incompleta?
@user53029 La correzione rilasciata per CVE-2014-6271 non corregge il difetto di progettazione sottostante che rende così bash deve analizzare le definizioni delle funzioni dall'ambiente * giusto * o subire potenziali bug di sicurezza. In questo senso la correzione è incompleta. Ma (per quanto è noto) risolve completamente il bug dell'esecuzione del codice finale dopo una definizione di funzione. Quindi ha in gran parte senso considerare CVE-2014-7169 una vulnerabilità separata. ** La patch per 6271 e il test in questa risposta per determinare se quella patch è effettivamente applicata non testano per 7169. ** Ho ampliato questa risposta con i dettagli.
@Eliah Kagan -Quindi, per avere un'idea del grado di sicurezza che è stato mitigato con la patch, cosa può fare un attaccante mentre sfrutta il bug in 7169 che non potrebbe più fare su un sistema con patch 6271?
@user53029 Esattamente. Un albero è fisso. Ma la foresta è davvero in pericolo pratico?
Suggerimento per un piccolo miglioramento. Se anteponi il comando di prova con `env`, funzionerà anche da csh / tcsh.
Uso mac os x e risulta vulnerabile, ma per il momento non posso farci niente, giusto?
Con l'ultima patch (che evita `eval` su variabili di ambiente casuali) il test originale dovrebbe andare bene, stampando _nulla_ su un sistema completamente patchato.
Non ottengo nulla quando digito questo
#2
+12
BadSkillz
2014-09-25 16:34:03 UTC
view on stackexchange narkive permalink

Puoi verificare se sei vulnerabile eseguendo le seguenti righe nella tua shell predefinita, che su molti sistemi sarà Bash. Se vedi le parole "arrestato", sei a rischio. Se solo il secondo comando stampa "busted", la tua bash è vulnerabile, ma la vulnerabilità ha un impatto solo sulle parti del tuo sistema che invocano bash esplicitamente, non sulle parti che eseguono la shell predefinita ( sh ). Se nessuno dei due comandi visualizza "busted", il tuo sistema è patchato.

  env X = "() {:;}; echo busted" / bin / sh -c "echo completed" env X = "() {:;}; echo busted" bash -c "echo completed"  

Source

Dopo l'applicazione delle patch, il tuo sistema potrebbe essere ancora vulnerabile:

  env X = '() {(a) = > \' bash -c "echo echo vuln"; [["$ (cat echo)" == "vuln"]] && echo "ancora vulnerabile :("  

Fonte e un'altra fonte

Non sono sicuro di cosa dovrebbe fare `\` quale bash \ `` che `bash` non farebbe: entrambi vengono eseguiti a seconda di quale` bash` appare per primo in `PATH`, e non è come se` env` abbia bisogno di una qualifica completa nomi. (Inoltre, non hai affatto bisogno di "env" per questo.)
@BadSkillz, puoi aggiungere qualche chiarimento a `env X = '() {(a) => \' sh -c" echo date "; gatto echo`? Cosa dovrebbe fare o mostrarmi?
@Eliah, sarebbe fantastico se riuscissi a trovare una risposta migliore.
`which bash` potrebbe farti superare un input disinfettato che limita i letterali del percorso del comando della shell.
@KasperSouren, Penso che dimostri solo un bug nell'analisi della funzione bash come menzionato [qui] (https://twitter.com/taviso/status/514910129557610496) ... quindi questa non è una sintassi bash valida.
X rimane per sempre nel mio ambiente? cosa succede se ho già una variabile d'ambiente chiamata X?
@NateKerkhofs No, non rimarrà e, se lo desideri, puoi utilizzare un'altra variabile
Le variabili di ambiente @NateKerkhofs sono per processo. `VAR = value some-command` (o` env VAR = value some-command`) esegue `some-command` con` VAR` impostato su `value` nel * suo * ambiente. La `x` appartenente alla shell in cui esegui quel comando [non viene influenzata] (http://paste.ubuntu.com/8425978/), anche se [la variabile è impostata nell'ambiente del processo figlio] (http: //paste.ubuntu.com/8425989/). Ad ogni modo, anche se l'avessi impostato per l'ambiente della shell corrente, come dice BadSkillz, sarebbe non persistente e non causerebbe danni, e puoi scegliere un nome di variabile diverso se lo desideri.
"Quale" è sicuro? Cosa fermare: `export which = '() {echo / bin / bash;}`? (Uno completo testerebbe l'argomento). Bash esegue le funzioni prima dei built-in. Puoi anche usare il medico `declare -f` e` env` in modo simile per nascondere le funzioni.
#3
+11
Nzall
2014-09-25 19:47:04 UTC
view on stackexchange narkive permalink

Se hai bisogno di un metodo per controllare più server contemporaneamente che si trovano sulla stessa sottorete, puoi utilizzare Masscan per inviare una richiesta a tutti loro: https://github.com/robertdavidgraham/masscan

Un file di configurazione di esempio può essere trovato su http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html:

  target = 0.0.0.0/0 // CAMBIA QUESTO NEL SUBNET CORRETTOport = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/ 09 / bash-shellshock-scan-of-internet.html) http-header [Cookie] = () {:; }; ping -c 3 209.126.230.74http-header [Host] = () {:; }; ping -c 3 209.126.230.74http-header [Referer] = () {:; }; ping -c 3 209.126.230.74//modifica i 3 indirizzi IP sopra indicati con l'IP della macchina da cui lo invii.  

Le macchine vulnerabili ti invieranno un ping. Secondo il post sul blog di follow-up dell'autore, potrebbe essere necessaria una configurazione.

Come posso controllare un solo server?
@CharlesB si connette da remoto al server ed esegue uno degli oneliner in questa pagina. oppure inserisci l'IP completo del server con subnetmask / 32.
Grazie; non è stato possibile modificarlo, ma deve essere "target-ip" invece di "target". Se provo il mio router, il comando ping non è rilevabile ... C'è un altro comando per dimostrare quell'exploit
SSH nel router e fai ciò che Eliah Khan consiglia nella sua risposta. Devi farlo direttamente tramite il terminale del router.
Non ho accesso SSH ad esso, è una scatola chiusa dal tuo ISP. Quindi non c'è modo di controllarlo?
Se si tratta di una scatola chiusa, cosa farai quando scoprirai che l'exploit è attivo? Dubito che sarai in grado di risolverlo, dal momento che non puoi aggiornare Bash.
Certo non sarò in grado di risolverlo, ma è solo per sapere e chiederlo al mio ISP.
#4
  0
Liam Marshall
2014-09-26 23:12:10 UTC
view on stackexchange narkive permalink

Puoi provare ShellShocker, un'utilità CLI che può controllare uno script CGI in questo modo:

  python shellshocker.py http://example.com /cgi-bin/possibly-vulnerable-cgi.cgi  
#5
  0
Roger
2014-09-27 04:27:13 UTC
view on stackexchange narkive permalink

Puoi controllare il tuo server inviando un URL CGI al seguente test online:

http://shellshock.iecra.org

#6
  0
colevk
2014-09-27 05:10:59 UTC
view on stackexchange narkive permalink

Ho scritto un rapido test che stampa "vulnerabile" o "non vulnerabile":

  env x = '() {:;}; eco vulnerabile; Uscita;' bash -c 'echo non vulnerabile' 2> / dev / null  

Restituisce anche un codice di uscita 2 se la tua versione di bash è vulnerabile, se vuoi usarla come parte di uno script.

Testato con le versioni `3.2.51 (1) -release (x86_64-apple-darwin13)` e `3.2.53 (1) -release (x86_64-apple-darwin13)`.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...