Como testar se meu servidor está vulnerável ao bug do ShellShock?


80

Como garantir que minha instalação do Bash não fique mais vulnerável ao bug do ShellShock após as atualizações?



Observe que há outras duas vulnerabilidades no bash ainda sem patch (CVE-2014-7186 e CVE-2014-7187).
Deer Hunter

Os patches que corrigem CVE-2014-7186 e CVE-2014-7187 estão disponíveis desde pouco tempo depois que Deer Hunter postou seu comentário. Se você possui um patch fornecido pela distro para CVE-2014-7169, já pode ter o suficiente para bloquear 7186/7187, teste seu sistema com os comandos abaixo e veja. Verifique também se há mais atualizações de segurança para sua distribuição.
precisa saber é o seguinte

Respostas:


83

Para verificar a vulnerabilidade CVE-2014-6271

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

NÃO deve repetir a palavra vulnerável.


Para verificar a vulnerabilidade CVE-2014-7169
(aviso: se o seu falhar, ele criará ou substituirá um arquivo chamado /tmp/echoque você pode excluir depois e precisa excluir antes de testar novamente)

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

deve dizer a palavra data e depois reclamar com uma mensagem como cat: echo: No such file or directory. Se, em vez disso, indicar qual é a data e hora atual, seu sistema estará vulnerável.


Para verificar o 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"

NÃO deve repetir o texto CVE-2014-7186 vulnerable, redir_stack.


Para verificar o 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"

NÃO deve repetir o texto CVE-2014-7187 vulnerable, word_lineno.


Para verificar o CVE-2014-6277. Não tenho 100% de certeza neste, pois parece depender de um sistema parcialmente corrigido ao qual não tenho mais acesso.

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

Um resultado de aprovação neste é apenas o eco de volta ao texto testing CVE-2014-6277. Se ele executa perl ou se ele reclama que o perl não está instalado, isso é definitivamente uma falha. Não tenho certeza de outras características de falha, pois não tenho mais nenhum sistema sem patch.


Para verificar o CVE-2014-6278. Mais uma vez, não tenho 100% de certeza se esse teste já não possui sistemas sem patch.

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

Uma aprovação para este teste é que ele deve apenas repetir o texto testing CVE-2014-6278. Se o seu eco voltar para hi momqualquer lugar, isso é definitivamente um fracasso.


1
Podemos adicionar o teste geral foo='() { echo not patched; }' bash -c fooa isso? Até que as exportações de funções sejam colocadas em um espaço para nome separado, não deixaremos de executar um bug do analisador para o próximo.
precisa saber é

Esse teste tem um CVE? Você tem alguma referência para descrever esse problema? Além disso, esse tipo de informação pode pertencer a uma das outras perguntas sobre o shellshock, devido a este Q ser sobre como testar o sucesso ou a falha dos patches existentes.
precisa saber é o seguinte

Isso é do post de Michal Zalewski no blog de alguns Shellshock CVE ( lcamtuf.blogspot.com/2014/09/… ). É o teste sugerido para o CVE-2014-6278, que ainda não é público. Parece que eu estava errado sobre a generalidade do teste; Eu já encontrei um caso em que o teste de Zalewski passou, mas o teste CVE-2014-7187 falhou.
precisa saber é

E aqui é a divulgação completa em CVE-2014-6277 e CVE-2014-6278, junto com comandos para verificar se eles: seclists.org/fulldisclosure/2014/Oct/9
billyw

Um ponto a ser observado: mesmo que a versão do BASH seja vulnerável, se nada a usar (ou seja, todas as contas usadas por daemons, como "www" ou "cups" ou qualquer outra coisa), são configuradas com o BASH como seu shell padrão e nenhuma seus códigos chamam system () ou similares, ter a versão vulnerável pode ser menos arriscada, mas ainda assim, atualize o BASH o mais rápido possível.
DTK

32

Exporte uma variável de ambiente especialmente criada que será avaliada automaticamente por versões vulneráveis ​​do Bash:

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

Agora execute um eco simples para ver se o Bash avaliará o código em $ testbug, mesmo que você não tenha usado essa variável:

$ bash -c "echo Hello"
VULNERABLE
Hello

Se mostrar a string "VULNERABLE", a resposta é óbvia. Caso contrário, você não precisa se preocupar e sua versão corrigida do Bash está OK.

Observe que vários patches foram lançados pelas principais distribuições Linux e, às vezes, eles não corrigem completamente a vulnerabilidade. Continue verificando os avisos de segurança e a entrada do CVE quanto a esse bug.


5
Além de CVE-2014-6271, a correção incompleta da Red Hat, em particular, tem uma que também vale a pena: CVE-2014-7169 .
DocMax 25/09

3
Uma linha que não polui o ambiente do seu shell e funciona mesmo que você esteja usando um shell de login alternativo (o que talvez você não saiba export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki 26/09/14

1
Há alguns detalhes específicos do Ubuntu aqui askubuntu.com/questions/528101/... - pessoalmente, eu tinha que atualizar a partir do Ubuntu 13,10 para 14,04 para corrigir o problema
dodgy_coder

2

O ShellShock é praticamente uma conjunção de mais de uma vulnerabilidade do bash e , neste momento, também existe um malware que explora essa vulnerabilidade ; portanto, o ShellShock pode ser um problema que ainda está aberto, há um encadeamento com atualizações do RedHat sobre esses problemas .

A Redhat recomenda o seguinte:

Comando de execução:

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

Se a saída for:

$ 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

você não tem nenhuma correção.

Se a saída for:

$ 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

você tem CVE-2014-6271conserto

Se sua saída for:

$ 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

você não é vulnerável.

A outra parte da verificação do ShellShock é a verificação de vulnerabilidade CVE-2014-7169, que garante a proteção do sistema contra o problema de criação de arquivo. Para testar se sua versão do Bash é vulnerável ao CVE-2014-7169, execute o seguinte comando:

$ 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 o seu sistema estiver vulnerável, a hora e a data serão exibidas e / tmp / echo será criado.

Se o seu sistema não estiver vulnerável, você verá resultados semelhantes 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

Eu escrevi um utilitário de CLI chamado ShellShocker para testar seu servidor da Web quanto a vulnerabilidades em scripts CGI. Para testar seu site, você deve executar:

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

ie

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

EDIT: este utilitário foi retirado, desculpe: '(


O seu link está morto
SSK

@SSK Desculpe;) Mistype.
Liam Marshall

Seu link ainda está morto.
Mxx

Sim, desculpe, eu anotei. Estava sendo explorado de maneiras que eu não gostava.
Liam Marshall

1

Você pode enviar seu URL CGI para este teste online:

http://shellshock.iecra.org


4
É educado fornecer razões para votos negativos.
David

4
"Registramos todas as verificações" ??? Arrepiante. Eu baixaria o python e executaria eu mesmo.
Brad Brad

1
@ Brad pelo menos eles estão lhe dizendo. Tenho certeza de que, se eu estivesse fornecendo um serviço de segurança whitehat que oferecia esse serviço, eu poderia manter um registro (mesmo que apenas um contador, sem detalhes individuais) de quantas pessoas digitaram cegamente os detalhes do site em um site que dizia que iria para tentar um teste de penetração, sem saber muito sobre a autenticidade do site que oferece o teste ... e eles gostariam de um registro de quem testou o que, caso alguém usasse seu serviço para encontrar sites vulneráveis ​​pertencentes a outros também ...
precisa saber é o seguinte

-1

tipo env x = '() {:;}; ech vulnerável 'bash -c "echo isto é um teste" e se isso retornar vulnerável e este for um teste, significa que sua máquina OSX / Linux será afetada. O remédio é atualizar para a versão mais recente do bash.


6
Por que como root? Completamente desnecessário.
Mat
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.