shellshock

ShellShock – Vulnerabilidade critica na Bash

ShellShock é como está sendo chamada uma vulnerabilidade critica da Bash que foi descoberta por Stephane Chazelas.

A vulnerabilidade (CVE-2014-6271) afeta as versões 1.14 até 4.3 do GNU Bash e foi nomeado como Bash Bug, e Shellshock pelos pesquisadores de segurança nas discussões na Internet.

De acordo com os detalhes técnicos, um atacante poderia explorar este bash bug para executar comandos shell remotamente em um computador de destino usando variáveis ​​especificamente criados para tal finalidade. Em muitas configurações, esta vulnerabilidade pode ser explorada através da rede.

Se você achava que o heartbleed ficou tempo demais despercebido, imagina só o shellshock, que tem mais de 20 anos de idade. Para conferir acesse “https://ftp.gnu.org/gnu/bash/” e veja a data de lançamento da versão 1.14

Esta vulnerabilidade decorre da forma como lida as variáveis ​​de ambiente especialmente formatadas, ou seja, funções de shell exportadas.

Você possui um ambiente *unix, parabéns, você está vulnerável.

Quer testar, é muito fácil, basta executar o código abaixo:

Se aparecer a mensagem “Vulneravel”, não perca mais tempo, atualize o pacote bash

shellshock-update

Note que após o update, a mensagem “Vulneravel” não aparece mais.

Informações de suporte:

Agradecimentos especiais ao meu amigo Gustavo Borges (GB), que passou o dia atualizando bash de mais de 60 servidores e me deu a dica da vulnerabilidade em primeira mão!

 

PS: Como meu amigo Michel teve problemas com o patch, deixei um pacote já com os patches aplicados, para caso mais alguém tenha problemas com o patch apesar do GB ter feito um script ninja e compartilhado com todos…

The following two tabs change content below.
Atua como Analista de Segurança da Informação Sênior em uma empresa de consultoria de Segurança da Informação e Tecnologia do interior de São Paulo. Trabalha com computação desde 1998 e iniciou suas atividades como Analista de Segurança da Informação em 2002 prestando consultoria e participando de projetos voltados a Segurança da Informação. Também é sócio de uma empresa de soluções de Alta Disponibilidade.
  1. Pessoal,

    Algumas versões antigas não estão recebendo o update da bash

    Segue tutorial:

    Se for uma versão de Linux antiga e não houver update favor seguir os passos abaixo:

    Como root execute.
    mkdir src
    cd src
    wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
    for i in $(seq -f “%03g” 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
    tar zxvf bash-4.3.tar.gz
    cd bash-4.3
    for i in $(seq -f “%03g” 0 25);do patch -p0 < ../bash43-$i; done
    ./configure && make && make install

    • Mestre GB e suas compilações… kkk
      Só uma observação do ultimo comando, o Gustavo passou 3 comandos apendados, com condição de rodar o seguinte só no caso de sucesso do anterior. para quem não tem experiência em compilar aplicações *unix, recomendo subistituir o
      ./configure && make && make install
      por:
      ./configure
      make
      make install

      isso faz com que no caso de erro você detecte mais facilmente onde foi. Mas como o configure não contem parâmetros, a probabilidade de ocorrer problemas é quase nula, visto que o bash não possui dependencias.

    • Realmente, utilizar um repositório local é uma boa alternativa…, contanto que o pacote disponibilizado nele esteja atualizado. Normalmente próximo do “Zero Day” não existe esta opção, então parte para a compilação mesmo. Agora utilizar sistemas operacionais em EOL é um pouco arriscado demais. Mais legal que deu tudo certo, um host a menos para ser explorado!

  2. Concordo plenamente…. no caso exposto anteriormente, a estacão era utilizada para fins de laboratório. Compilar é processo que muitos acham antiquado, mas torna-se extremamente útil em situações diversas, inclusive esta exposta. Lembro-me da época que utilizava comecei a utilizar Slackware 7 e algum tempo depois também Gentoo, este processo era encarado com naturalidade, e permitia aprender desde cedo, que não apenas falhas pontuais podiam ser corrigidas rapidamente, falhas essas ainda não corrigidas diretamente no repositório de pacotes, mas permitia ativar e desativar recursos desnecessário, seja para hardening ou tuning tornando o binário livre de recursos desnecessários.

Deixe uma resposta