Tutorial Usando Google como ferramenta de hacker

Hoje vou iniciar a uma série de artigos sobre técnicas de ataque e defesa de sistemas, vou começar com um excelente artigo do GRIS ( Grupo de Resposta a Incidentes de Segurança ) da UFRJ que fala sobre Técnicas de Ataque e Defesa de Sistemas usando o Google. Vou dividi-lo em partes para um melhor entendimento.

Boa leitura!

A utilização de agentes buscadores para catalogar páginas, ao mesmo tempo em que aumenta consideravelmente o número de respostas da ferramenta, traz o problema de muitas vezes catalogar mais do que os administradores de páginas gostariam. Isso porque muitos servidores conectados a Internet – e, portanto, passíveis de serem catalogados por agentes buscadores – não foram configurados de forma segura, contando apenas com o fato de não serem conhecidos para se protegerem. Assim, se os agentes do Google encontrarem, por exemplo, arquivos sigilosos ao fazerem uma varredura nos servidores de sua empresa, eles irão adicionar tais arquivos e páginas à base de dados do Google na primeira oportunidade, já que não são capazes de diferenciar o que é público do que é confidencial.

Dessa forma, muita informação “sensível” pode ser encontrada, bastando que se saiba o que procurar. Não bastasse isso, o Google armazena no “cache” uma versão da sua página ou arquivo, de modo que mesmo corrigindo o problema do seu servidor, seus dados podem ainda estar expostos. Vejamos alguns tipos de ataques que podem ser feitos através do Google.

Nota: é importante observar que a maioria dos ataques e técnicas aqui exemplificados não são nenhuma novidade. Existem registros sobre alguns destes que datam de 2001, o que indica que usuários maliciosos vêm explorando tais características de sistemas de busca a mais tempo ainda.

Ataque #1 – Identificação de servidores

Para identificar todas as páginas da Google que o próprio Google já catalogou, por exemplo, basta

digitar:

* inurl:google.com

Para encontrar servidores extras dentro do mesmo domínio, subtraia o domínio principal da busca anterior. No exemplo, podemos entrar com inurl:google.com –inurl:Google para listar diversos subdomínios dentro de “google.com” (como, por exemplo, “images.google.com”, “gmail.google.com”, “desktop.google.com”, etc).

É possível ainda encontrar serviços remotos em execução. Veja os exemplos à seguir:

* intitle:”VNC Desktop ” inurl:5800 # procura por servidores “VNC” em execução

* intitle:”remote desktop web connection” # refere-se à Área de Trabalho Remota (“Windows Remote Desktop”)

* intitle:”Terminal Services Web Connection” # refere-se ao serviço de terminal (“terminal services”) da Microsoft

* allintitle:”microsoft outlook web access” logon # busca por páginas de acesso remoto ao webmail Microsoft

Outlook

Ataque #2 – Servidores negligenciados

Muitos servidores de páginas web, como o Apache, exibem páginas padrão ao serem instalados. Isso é feito essencialmente para mostrar ao administrador que o serviço está sendo executado sem problemas, e oferecer dicas sobre como proceder em seguida. Acontece que muitas pessoas acabam instalando servidores sem saber, e embora a existência da página padrão não indique especificamente uma vulnerabilidade, costuma mostrar que o servidor em questão foi negligenciado pelos administradores, e possivelmente está com suas configurações padrão.

Afinal, se o administrador não se deu ao trabalho de sequer modificar a página principal do servidor, é muito provável que ele também não tenha se preocupado em atualizar o mesmo, ou em tornar o próprio sistema mais seguro.

Buscar por:

* intitle:”test page for Apache”

* intitle:“Página teste para a instalação do Apache”

retorna uma lista de servidores que estão exibindo a página padrão do Apache.

Para procurar por páginas padrão do IIS, poderíamos buscar por:

* intitle:welcome.to.IIS.4.0

* intitle:”welcome to windows 2000 internet services”

* intitle:”welcome to windows xp server internet services”

* “under construction” “does not currently have” para servidores mais novos.

Ataque #3 – Listagem de diretórios

Configurar servidores adequadamente pode ser uma tarefa bastante confusa, e de fato muitos administradores cometem erros na hora de determinar que diretórios do sistema podem ou não ser acessados via Internet. Além disso, servidores costumam permitir a listagem dos arquivos e subdiretórios dentro de um diretório que possa ser acessado mas não tenha a página de nome padrão

(geralmente “index.html”, embora isso possa ser modificado nas configurações do servidor). Isso permite que usuários maliciosos procurem por listagem de diretórios sensíveis em seu servidor, ou ainda por arquivos específicos dentro de seu sistema, que podem ser acessados pelo nome mesmo que seu servidor esteja configurado para não listar o conteúdo de diretórios (desde que, é claro, o servidor tenha permitido acesso ao arquivo devido a má configuração do servidor).

É possível, por exemplo, buscar por:

* intitle:index of/admin

retorna listagem de diretórios chamados “admin”, comumente utilizados por administradores de sistemas para guardar arquivos e dados – possivelmente sensíveis.

Buscar por arquivos e subdiretórios específicos dentro de listagens diretórios também é possível, como por exemplo:

* intitle:”index of” .htpasswd

* intitle:”index of” backup

Ataque #4 – Senhas

Muitos servidores mal configurados tornam públicos seus arquivos de registro (“logs”), permitindo assim que usuários maliciosos obtenham senhas de sistemas (muitas vezes com privilégios de administrador) sem trabalho algum, bastando buscar por:

* filetype:log inurl:”password.log”

Ataque #5 – Explorando bancos de dados

Grande parte dos servidores web precisa de serviços de banco de dados instalados, mas muitos não são bem configurados e acabam fornecendo informações sigilosas, como tabelas inteiras, que podem conter até mesmo campos com nome de usuários e senhas válidas dentro do sistema.

A seguinte busca procura por tais tabelas:

* “# dumping data for table” (username|user|users) password

Conhecendo um pouco da estrutura de arquivos de uma base de dados SQL, é possível ir diretamente atrás de arquivos que contenham senhas, como por exemplo através da busca:

* filetype:properties inurl:db intext:password

É possível ainda identificar bancos de dados vulneráveis a ataques de “injeção de SQL”, ao pesquisarmos por mensagens de erro que tipicamente denunciam esse problema:

* “ORA-00921: unexpected end of SQL command”

* “ORA-00933: SQL command not properly ended”

* “unclosed quotation mark before the character string”

Ataque #6 – Explorando relatórios de segurança

Administradores preocupados com a segurança de seus sistemas costumam executar programas específicos que realizam varreduras de segurança e identificam vulnerabilidades em seus servidores.

Procurar por:

* “This file was generated by Nessus”

* “This report lists” “identified by Internet Scanner”

retorna desde páginas exemplo até relatórios reais, que indicam as vulnerabilidades encontradas em determinados servidores, que colocaram os relatórios das ferramentas (como o “nessus” ou o “ISS”, do exemplo acima) em uma área pública.

Ataque #7 – Usando o Google como um web proxy

A possibilidade de se traduzir páginas é um dos grandes atrativos do Google. Através da página Google Translate podemos digitar uma URL qualquer e o Google fará a tradução da página de acordo com o idioma desejado. O procedimento é simples: O Google acessa a página, traduz, e retorna ela para você. Na prática, você não fez nenhuma conexão direta à página desejada, e o Google atuou como um web proxy para você. O único problema desse procedimento é que você precisaria traduzir a página desejada de algum idioma para outro, e visualizá-la somente no idioma destino. No entanto, isso pode ser facilmente contornado.

A sintaxe retornada pelo Google para as traduções é no seguinte formato:

* Google Translate

onde PAGINA é a URL completa desejada, LANG1 é o código para o idioma original da página, e LANG2 é o código para o idioma destino. Manipulando esses valores, podemos colocar o mesmo idioma como origem e destino, e assim ver a página em seu idioma original, utilizando o Google como web proxy.

Para ver o conteúdo da página do GRIS (em português) através do Google, basta digitar:

* Google Translate

Idiomas identificados pelo Google até a data de publicação deste documento são:

* de (alemão)

* es (espanhol)

* fr (francês)

* it (italiano)

* pt (português)

* us (inglês)

Ataque #8 – Fazendo o “googlebot” lançar ataques por você

Como visto no início deste documento, o “googlebot” é o agente responsável pela busca e classificação das páginas dentro de servidores. Pedir ao agente para visitar sua página é um procedimento fácil, e que pode ser feito de muitas maneiras diferentes. Uma vez dentro de sua página, o “googlebot” (e qualquer outro agente de serviços de busca, na verdade) vai registrar e seguir cada um dos links que você incluir dentro da mesma, não importa quais sejam. Um usuário pode, portanto, adicionar links de natureza maliciosa em sua página e apenas esperar os agentes surgirem para fazer o “trabalho sujo” por ele. Os agentes buscadores se encarregarão de executar o ataque e, não bastasse isso, ainda podem colocar os resultados devolvidos pelas vítimas (caso existam) publicamente em suas páginas de busca, para que qualquer um (inclusive o atacante) possa ver. Exemplos links com ataques potenciais incluem:

* http://algumhost/cgi-bin/script.pl?p1=`ataque`

* http://algumhost:54321/ataque?`id`

* http://algumhost/AAAAAAAAAAAAAAAAAAAAAAAAAAAA…

Repare que é possível ainda manipular a sintaxe das URLs para mandar o agente acessar o servidor alvo em portas específicas (na segunda linha de exemplo, mandamos ele acessar a porta 54321).

Existem muitas outras formas de ataque possíveis através de mecanismos de busca. Sabendo o que procurar, é possível utilizar o Google para encontrar informações que vão de dados de um servidor até senhas de banco e números de cartão de crédito.

Como vimos anteriormente o Google pode ser uma poderosa ferramenta de enumeração e coleta de dados, porém ele ajuda os sysadmins na correção dos erros também.

Na útima parte deste artigo veremos como ele pode ajudar a defender nossas informações contra acessos não-autorizados.

Boa Leitura!

Usando o Google para se defender de ataques:

Da mesma forma que o Google pode ser usado por usuários maliciosos a fim de atacar seus servidores e clientes, você também pode utilizá-lo para proteger os mesmos através de algumas simples ações e constante vigilância. Essencialmente, não coloque informações sensíveis em seus servidores, ainda que temporariamente.

Configure seus servidores com atenção redobrada e verifique regularmente sua presença (e a presença de seu sistema) dentro do Google, utilizando o operador “site:” para fazer pesquisas em todos os seus servidores. Este operador também aceita números de IP como parâmetro, então é possível utilizá-lo em seu servidor de IP fixo mesmo que ele não tenha um nome de domínio válido.

O procedimento de verificação acima pode ser automatizado através da utilização de ferramentas gratuitas disponibilizadas na Internet, dentre elas o “sitedigger”, da Foundstone, que pode ser obtido em:

* http://www.foundstone.com/resources/…sitedigger.htm

e o Wikto, da Sensepost, que pode ser obtido em:

* http://www.sensepost.com/research/wikto/

Consertando o estrago que já foi feito:

Ainda que você tome as devidas atitudes ao identificar um problema em seus sistemas através do Google, este pode continuar exibindo sua página, dados ou arquivos indesejados através do sistema de armazenamento de páginas. Para resolver esse problema, basta avisar ao Google que você quer a referência anterior à sua página atualizada ou removida, acessando Google Webmaster Central e seguindo as indicações. Naturalmente, para remover a referência a um servidor, você precisará provar que é o administrador do mesmo