Entenda o bug shellshock

1. ShellShock ou Bash Bug?

Eu estava PuppetConf'2014 quando esse bug foi noticiado no dia 24 de Setembro, havia um grande número de especialistas no evento e teve muita gente preocupada, lendo e acessando seus servidores para tentar entender, checar e mitigar o problema.

O shellshock, bashdoor ou bashbug é um bug gravíssimo que foi encontrado no shell bash pelo especialista Stephane Schazelas, o bug está presente em diversos sistemas operacionais Linux e Unix.

2. Shell?

O shell é um interpretador de comandos que permite que nós usuários e também que programas acessem serviços e recursos do sistema operacional Unix/Linux.

O bash é apenas um dos diversos tipos de shell (interpretadores de comandos) existentes, porém, ele é o mais comum e está presente em praticamente todo sistema operacional Unix e Linux.

3. Impacto

O bug foi encontrado desde a versão 1.14 até a versão 4.3, em resumo todas as releases dos últimos 22 anos são afetadas já que a versão 1.14 foi lançada em 1992.

O alcance desse bug está na casa dos milhões de servidores (*NIX) no planeta, incluindo ai nessa lista, computadores pessoais MACS (OSX) e até os seguros sistemas *BSD.

Ok, mas onde o bash é utilizado em meu sistema operacional? em que momento ele é carregado?

4. Entendendo o problema

Sempre que criamos um usuário no UNIX ou LINUX normalmente o shell bash é associado a essa conta, com isto, é possível se conectar ao sistema operacional utilizando ssh e telnet, por exemplo.

Quando instalamos algum sistema ou serviço, este também pode utilizar o bash para executar algo ou para definir alguma variável de ambiente necessária para seu funcionamento.

É possível inclusive rodar comandos remotamente no bash utilizando ssh.

5. Como exploram a falha?

A vulnerabilidade permite que atacantes executem código arbitrário em determinadas situações e condições, normalmente via rede.

Utilizando algumas strings e variáveis de ambiente eles conseguem escalar privilégios de um usuário normal e acessar recursos protegidos.

5.1 Exploits

Alguns posts sobre exploits criados para explorar o shellshock

Já existe inclusive um malware/botnet chamado WOPBOT explorando sites vulneráveis.

6. Quais os principais serviços afetados?

Por hora são esses, mas qualquer serviço que dependa do bash está potencialmente afetado.

7. Bugs conhecidos

O primeiro bug relatado foi o CVE-2014-6271, este teve um fix publicado que não foi completo e mais problemas foram detectados, com isso, foram registradas novas falhas, são elas: CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 e CVE-2014-7187.

O CVE é uma das maiores e mais respeitadas base de dados de segurança que contém dados do tipo vulnerability (erros de implementação em softwares) e exposure (falhas de configuração ou de uso de software), quando um bug é encontrado normalmente é registrado no CVE primeiro.

7.1 CVE-2014-6271

Este foi o primeiro bug encontrado, para verificar se seu bash está exposto a este bug, rode o comando abaixo em uma sessão sem privilégios

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

Se aparecer a mensagem “vulnerable” você precisa atualizar seu bash.

7.2 CVE-2014-7169

Esse bug permite que o atacante crie ou modifique arquivos além de ler arquivos que ele não teria privilégios, e também pode acessar partes protegidas do sistema, esse bug existe por correções incompletas no CVE-2014-(6271, 6277 e 6278).

Para testar se seu bash está vulnerável a este bug rode o comando abaixo em um sessão comum:

env X='() { (a)=>\' sh -c "echo date"; cat echo

Se a data e hora - saída do comando date - retornar após a execução, seu sistema está vulnerável.

7.3 Outros relacionados

Já corrigidos

Ainda sem correções até o momento (2014-10-01)

8. Testando meu servidor

8.1 HTTP Check

Você pode acessar essa URL e testar se seu site está vulnerável, ele usa alguns exploits HTTP para fazer a verificação

O gutocarvalho.net está limpo ;)

8.2 RedHat HTTP Check

Se você tem conta na RHN pode fazer o teste pela ferramenta da fabricante

9. Informações de fornecedores

Alguns links para sites de fornecedores e organizações.

9.1 Redhat

Artigos

Alertas

Sobre malwares que exploram o shellshock

9.2 Debian

9.3 Ubuntu

9.4 Suse

9.5 Apple

Leia e se informe, se tiver suporte comercial (RHEL/SLES) abra um ticket e peça apoio na verificação de seu parque.

Se preocupe principalmente com os seus servidores na DMZ.

10. Atualizando seu servidor manualmente

Aqui vão as dicas para você atualizar o bash no braço!

10.1 Redhat/Centos

yum install bash

10.2 Debian

aptitude install bash

10.3 Suse 12

zypper in -t patch SUSE-SLE-SERVER-12-2014-59

10.4 Apple MAC OSX

Aceite a atualização, apenas isto.

11. Atualizando o bash com ferramentas inteligentes

11.1 Puppet + Mcollective

Caso você tenha puppet em seu ambiente, você pode colocar o código abaixo em uma classe comum a todos os nodes

package { 'bash': ensure => latest }

Depois disto aguarde o agente pegar o novo catálogo e aplicar as mudanças.

Caso você tenha o mcollective em seu parque, após o ajuste na classe, acione o puppet em todos os nodes via plugin para não ter que esperar pelos agentes.

mco puppet agent runonce

11.2 Mcollective

Se você tem Mcollective mas não tem puppet, tudo bem, dá para rodar o seguinte comando

mco package update bash

Esse comando vai forçar a atualização do pacote bash em todos os nodes com o mcollective.

Mesmo que você tenha especificado e declarado no puppet que o bash deve ser estar sempre na última versão, esse comando é valido como uma outra garantia para que o pacote seja atualizado.

12. Recomendações

12.1 Devo reiniciar meus servidores afetados?

Olha se você tem janela e condições para isto, e principalmente se seu problema for relacionado a seu servidor de aplicações web, reiniciar vai descarregar completamente da memória as versões antigas do bash :)

Caso você não tenha janela, após atualizar, mate as sessões remotas para forçar os usuários a recarregarem o screen/tmux/afins e reinicie os serviços que dependem do bash, já vai resolver.

12.2 O SELINUX ajuda a diminuir o problema?

Um dos especialistas em SELINUX testou um exploit HTTP contra o SELINUX e fez um post explicando como o SELINUX se comportou e como diminui o estrago que o exploit poderia ter causado ao sistema que recebeu o teste.

12.3 Posso definir outro shell como padrão?

Pode, mas cada sistema operacional oferece uma forma diferente de fazer isto, recomendo por exemplo o ZSH, ele é um excelente shell, você definir o ZSH como shell padrão dos usuários até resolverem essa questão do bash.

Na parte de serviços é necessário fazer testes para ver se o serviço consegue utilizar um shell diferente do BASH, recomendo subir uma VM e testar antes de qualquer mudança.

Vale mencionar que no Debian o shell padrão é o dash, logo o problema para usuários debian é um pouco menor, mas o bash vem instalado no sistema, então é bom atualizar.

13. Amarrando as pontas

Há alguns meses abordamos aqui o terrível bug Heartbleed, mas tenho que dizer que dizer que o shellshock não fica atrás em importância e impacto, tem muita gente na web inclusive considerando o shellshock maior que o heartbleed devido a presença do bash em praticamente qualquer sistema operacional *NIX.

Eu ainda vou esperar, é muito cedo para comparar, nenhum estrago grande foi detectado ou divulgado até o momento.

Contudo, não perca tempo, pesquise e defina a melhor estratégia para atualizar o seu parque o quanto antes, mas não se afobe, faça com calma para fazer direito.

E não pare de estudar pois nem todos os bugs foram corrigidos até o final deste post (2014-10-01), continue acompanhando, lendo e checando o seu ambiente.

Converse com suas equipes de segurança para que eles verifiquem junto a fornecedores de appliances se tem novas ACLs ou RULES para bloquear as botnets e exploits HTTP e considere ativá-los como mais uma camada de segurança.

14. Referências

CVE

MISC