Páginas

sexta-feira, 26 de setembro de 2014

O recente bug no bash não foi totalmente corrigido, melhor puxar o servidor da tomada


Chamado de ShellShock, o recente bug no bash é tão grave quanto o conhecido do openssl( heartbleed ), mas não é necessariamente alarmante para todos. A mídia em geral está dando a impressão que qualquer sistema com linux poderá ser invadido por causa desse bug, o que não é real, apesar de factível que muitos dos servidores linux web sejam, por causa do mod_cgi e outros mods.

Quem ainda não leu sobre, seguem alguns links da notícia:

http://www.techtudo.com.br/noticias/noticia/2014/09/falha-em-componente-bash-pode-afetar-computadores-linux-e-mac-os-x.html
https://tecnoblog.net/166271/shellshock-falha-grave-bash/
http://br-linux.org/2014/01/shellshock-saiba-tudo-sobre-o-bug-que-afeta-todas-as-versoes-do-bash.html

O fato é que o bug não foi devidamente corrigido, sendo possível explorá-lo ainda de outra forma. O novo CVE indicando como um novo bug, na realidade trata da mesma via de exploração, ainda que diferente.

É provável que os mantenedores do bash tenham feito um patch rápido para mitigar o problema e irão soltar um patch com o bug completamente arrumado em um futuro próximo.

Após aplicar o patch, em um dos novos exemplos é possível a criação de arquivos:

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

Caso o teste funcione no seu sistema, no primeiro exemplo um arquivo com a data do sistema será criado e no segundo um arquivo em branco.

Alguns podem pensar "a é só um arquivo...". As pessoas ficariam assustadas se soubessem o que um byte ou até mesmo um bit modificado pode fazer.

No caso dos servidores web, o vetor de entrada é nas informações enviadas via http, que viram variáveis de ambiente e são interpretadas posteriormente pelo bash erroneamente.

Voltando ao bug de modo geral, vamos esclarecer algumas coisas:

O bug é explorável pelo openssh mas com ressalvas, é necessário uma conta limitada pelo menos para que seja possível.

É explorável via dhcp, mas para lidar com o dhcp é necessário já ter acesso a rede local.

Outras formas de exploração podem ser possíveis.

Existem diversas variáveis para se explorar algo assim, entretanto, o vetor mais grave é realmente os servidores web. Administradores fiquem atentos para novas correções das suas distribuições.

Atualização: No Redhat, parece que já resolveram o bug para a variante também.

Atualização: O pessoal da Unixwork resolveu desmistificar a falha, mas acabou também caindo em alguns erros, que acabam dando uma falsa sensação de segurança.

"Além do mais, o SCRIPT BASH via CGI-BIN teria que ser mal construído à ponto de deixar um atacante injetar código de alguma forma sobre ele. E cá para nós, CGI-BIN com SCRIPT BASH?!"

Não é realmente necessário o CGI ser script bash, não tem a ver a má construção do script no caso do shellscript, só o fato dele ser chamado o código malicioso já é executado!

Nos meus testes com o lighttpd isso é bem visível. No caso de um cgi em C comum com hello world, nada é retornado, mas no caso de cgis que chamam comandos externos com system( o que já não é lá uma boa idéia em termos gerais ) o comando malicioso é executado. Esse exemplo também funciona com scripts em python que chamem system.

" Para a falha ser grave, O CGI e o servidor web tem que estar setados para rodar com UID/GID do root, e nenhum administrador sensato deixaria um CGI rodar sem as devidas permissões apenas do usuário WEB ( www-data ou similar )."

Em minha concepção só o fato de alguem ter shell remota( mesmo que com www-data, nobody, etc ) no servidor, o bug já é grave. Em muitos casos, seja em servidores atualizados ou não ( o que é pior ), o acesso à uma shell desse modo já é caminho andado para se ter root. Além dos diversos bugs que são divulgados( para o caso de servidores desatualizados ) ainda há uma série de bugs localroot ainda não divulgados.

Já existe muita gente explorando o CPANEL, que é largamente utilizado. A mídia traz sim exageros, mas não podemos tratar o bug como se não fosse nada, ele é grave.

Referências: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

Nenhum comentário:

Postar um comentário