:::..Brecha_hacKER..:::

Usando o Google como ferramenta hacker

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.