Explorando o BASH com o ataque ShellShock

Por: Igor Jardim

O Shellshock explora uma vulnerabilidade no componente BASH de sistemas UNIX, permitindo a execução remota de comandos.

O BASH é um interpretador de comandos em ambientes Unix. Um comando é uma ação ou um conjunto de ações que são enviadas para um interpretador (shell). O BASH (Bourne Again Shell), criado por S. R. Bourne, é o mais utilizado desses programas, apesar de existir outros tais como csh, tesh, sh. Em ambientes Microsoft o interpretador nativo é cmd.exe.

Outro ponto importante é que o shell também é um interpretador de scripts que pode ser invocado por aplicações em servidores web, como o Apache.

O Ataque

O BASH permite a criação de variáveis de ambiente que são invocadas pelo usuário quando necessário. Também é possível invocar uma variável de ambiente utilizando um script de forma automática. Um exemplo seria a criação de uma variável que receba uma string com um nome:

env Name=Nicolas

echo “Bem vindo $Name”

O Shellshock (Vulnerabilidades CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187) permite que essa string contida na variável de ambiente contenha comandos que possam ser executados sem ao menos a variável ser invocada.

As versões de BASH 1.14 (de 1994) até a versão 4.3 são vulneráveis a essa falha. Apesar de muito antiga, esta falha somente foi publicamente descoberta recentemente – não há assim garantias que esta falha não tenha sido (ou não continue) a ser utilizada para ataques.

Assim como no SQLInjection, essa falha permite que o adversário burle o interpretador utilizando alguns parâmetros, fazendo que o BASH execute comandos arbitrários, não pretendidos por um usuário legítimo. No exemplo a seguir, a única saída do comando deveria ser “normal script commands”, porém em um Bash comprometido, a variável é executada sem ao menos ser invocada em qualquer parte do script, imprimindo na tela a

palavra “Warning”.

# env NAME='() { :;}; echo Warning’ bash -c “echo normal script commands”

Warning

normal script commands

A variável NAME jamais foi invocada, porém, mesmo assim o comando echo presente dentro dela foi executado.

Essa falha pode ser explorada de diversas maneiras. A variável pode ser apenas declarada e qualquer outro comando dentro dela pode ser executado. Em outro exemplo, é possível abrir uma porta especifica utilizando uma ferramenta que muitas vezes está instalada por padrão em sistemas e não é removida pelos administradores, o Netcat.

No exemplo a seguir, ao ser executado, o script abre uma porta 7654 que permite o acesso direto ao BASH do host comprometido. Esse ataque permite o acesso ao BASH de forma automática e no background do sistema, sem o conhecimento do usuário.

# env NAME='() { :;}; nc -lp 7654 -e /bin/bash&’ bash -c “echo Normal”

Normal

A execução da função continua imprimindo a palavra “Normal” ao seu final, mas sem citar a chamada ao netcat. Para um usuário comum que só verifica a saída do comando, está tudo normal, porém se verificarmos as portas abertas do sistema com o netstat, notamos que a porta 7654 está aberta e aguardando conexões.

# netstat –tupan | grep 7654

tcp 0 0 0.0.0.0:7654 0.0.0.0:*

LISTEN 12846/nc

Isso torna o Shellshock um problema maior que o Heartbleed, visto que enquanto o segundo lê dados ocultos no servidor, o primeiro permite o controle total do host vulnerável. O Shellshock pode estar presente em duas frentes distintas e amplamente utilizadas como servidores Web e sistemas embarcados (roteadores wireless, por exemplo).

Algumas empresas confirmaram que tiveram seus servidores comprometidos pela falha, como no caso da Yahoo!, porém, segundo a própria companhia, nenhum dado de usuário foi violado.

Solução

Enquanto que para usuários comuns essa falha não é um problema tão ameaçador, para empresas ela se torna algo extremamente crítico. Os serviços de empresas geralmente estão nas mãos dos administradores de sistemas que são responsáveis por aplicar correções e updates de software. Nem sempre esses profissionais possuem o hábito de atualizar seus servidores, além de só perceberem que sofreram uma invasão muito tempo depois do ocorrido.

Praticamente todas as distribuições Linux já possuem uma correção disponível para a falha do Shellshock, bastando apenas atualizar o repositório padrão e atualizar o Bash.

Já no caso de equipamentos embarcados, tais como roteadores, impressoras, telefones VoIP, o problema é um pouco mais complicado. A atualização (e correção de bugs) em equipamentos embarcados depende de atualizações disponibilizadas pelos fabricantes. Essas atualizações nem sempre são disponíveis para todos os equipamentos, sendo que os modelos mais antigos podem continuar vulneráveis a esses tipos de ataques até o final de suas vidas úteis.

Resumo

As seguintes medidas devem ser tomadas para se proteger do Shellshock:

– Verificar imediatamente se o seu Bash está vulnerável com os comandos a seguir:

# env shock='() { :;}; echo VULNERAVEL’ bash -c “echo Kryptus.com”

Se a saída do comando for VULNERAVEL, você deve atualizar seu sistema.

# env shock='() { (kryptus.com)=>\’ bash -c “echo date”; cat echo; rm ./echo

Se a saída do comando for a data atual, mesmo com alguns erros exibidos seu sistema está vulnerável.

– Atualizar o sistema utilizando os comandos necessários dependendo da distribuição:

Sistemas baseados em Debian

# apt-get update; apt-get install –only-upgrade bash

Sistemas baseados em RedHat

# yum update bash -y

Sistemas baseados em Arch

# pacman -Syu

– Verificar os logs de acesso, a fim de procurar por eventuais acessos não esperados aos servidores.

– Ficar atento a correções de segurança tanto das distribuições de Sistemas Operacionais, como de equipamentos embarcados.

Referências
https://shellshocker.net/
http://www.businessweek.com/news/2014-10-06/yahoo-says-no-data-stolen-in-shellshock-hack
https://cve.mitre.org/
https://www.debian.org/security/2014/
http://www.ubuntu.com/usn/
http://lwn.net/Alerts/CentOS/
https://securityblog.redhat.com/