Evitando RCE por Shellshock
RCE (Remote Code Execution) – que na tradução significa
execução de código remota — é a ação de um atacante ao executar códigos remotos
utilizando de vulnerabilidades do sistema. Uma dessas milhares de
vulnerabilidades detectadas é o Shellshock,
que afetou diversas versões de
sistemas baseados em linux/unix em 2014, como você pode ver no CVE.
Neste artigo, iremos discorrer como funciona o ataque na
prática.
O que
é shellshock?
Shellshock é uma vulnerabilidade que ocorre no bash, que
permite executar comandos de uma forma arbitraria, já que o ele é inserido
depois que uma determinada função é definida.
Errata: No
post antigo, Nova
Vulnerabilidade: Shellshock, informamos que, ao executar o comando
para saber se há a vulnerável, retornaria uma mensagem de erro. Na realidade
não há retorno de erro, a aplicação estará vulnerável caso os dois comandos
sejam executados, ou seja, ao executar:
env x='() { :;}; echo vulneravel' bash -c
"echo teste"
Se
for apresentado apenas “teste”, não há vulnerabilidade. Caso seja apresentado a
mensagem “vulnerável” antes de “teste” e também o “teste”, neste caso estará vulnerável.
Então
como ocorre o ataque?
Vamos supor que um atacante queira explorar um
servidor web e executar um comando especifico, como fazer o driver de DVD
abrir. Para tal, um usuário com permissão, apenas digita /bin/eject. Mas, supondo
que o servidor esteja vulnerável ao Shellshock, o atacante pode adicionar uma
string () {
:; }; para o /bin/bash e enviar o comando para o
servidor web via HTTP. O servidor deveria receber o comando identificado pelo User-Agent. Entretanto,
no caso do servidor vulnerável ao Shellshock, nada é informado.
Por exemplo, se o domínio “domínio.com.br” está
vulnerável, utilizando o Curl, o ataque funcionaria assim:
curl -H
"User-Agent: () { :; }; /bin/eject" http://dominio.com.br
É o suficiente para que o comando seja executado, fazendo
com que o driver de DVD abra.
Isso ocorre pois o atacante modifica a origem do HTTP
request e insere a string ()
{ :; };.
Neste cenário, o User-Agent ficaria deste modo:
HTTP_USER_AGENT=() {
:; }; /bin/eject
Se a
variável passar pelo bash do servidor web, o Shellshock ocorre.
Qual a solução?
A solução
é atualizar a versão do Bash para que o mesmo não interprete a string () { :; }; de
uma maneira especial.
Depende de outros fatores...
Para que
a vulnerabilidade seja explorada neste cenário, o servidor web precisa estar
como root. Entretanto, basta utilizar o Shellshock com outra vulnerabilidade
para consegui-la. Por exemplo, a falha da má configuração do CGI.
Mas o que é CGI?
CGI
(Common Gateway Interface) é um modulo do Apache, que permite que scripts e
programas sejam executados no servidor web. Além disso, o modulo pode dar
detalhes da comunicação entre o servidor web e o browser.
Alguns exemplos de suas funções são:
·
auxiliar no processamento de dados submetidos por
forms;
·
fazer as conversões de HTML para SQL;
·
converter os dados do sistema em HTML;
·
retornar o response para o cliente;
·
gerenciar contadores de acesso.
Portanto, um atacante pode usar o CGI para enviar uma
determinada variável para o servidor web vulnerável por má configuração do CGI,
pois o servidor utiliza o bash para interpretar a variável, que irá executar
qualquer comando malicioso contido.
Sendo assim, utilizando ShellShock com o CGI mal configurado,
é possível fazer interpretação de comandos no servidor alvo.
Solução?
Para mitigação, nas configurações do apache em
/etc/httpd.conf, altere o ServerTokens de FULL para PRODUCTONLY. Altere o ServerSignature
de ON para OFF. Assim, irá mitigar o footprint
do sistema utilizado, não deixar o diretório CGI aberto e permitir que apenas
um determinado IP seja capaz de executar comandos.
Conclusão
O intuito deste artigo é mostrar, mesmo que de forma
superficial, como funciona um ataque e como mitigar um ataque. Pois é possível
utilizar de diversas vulnerabilidades em uma aplicação, ou mesmo em diferentes
aplicações que se comunicam, para conseguir explorar um determinado alvo.
Referencias:
0 comentários: