Dorking as a ninja with Robots.txt, Google & Archive.org

Ya he hablado muchas veces de cómo los ficheros robots.txt pueden ser un verdadero problema para los sitios web que no han contado con ellos como arma del enemigo, debido a que pueden convertirse en una fuente de información para un posible atacante. El hacking driven by robots.txt no es más que ir a por los documentos que un sitio web no quiere que encuentres a través del buscador pero que manualmente puedes localizar, pero es que esto puede ser mucho peor si combinas algunos trucos en serie.

Después de jugar con las opciones de indexing y caching en sitios como Facebook y ver sus problemas de privacidad o como en el sitio web de WhatsApp, he pasado un par de días dorkeando como un ninja en grandes sitios de Internet, y me ha llevado al convencimiento de que esto es insostenible incluso para la propia Google. Aquí os dejo unos trucos combinando el hacking con buscadores que he estado utilizando.

Usando el Robots.txt de un sitio y la indexación de URLs de Google

La idea es tan sencilla como llegar a un sitio, analizar su contenido y buscar las URLs indexadas en el buscador que precisamente el fichero robots.txt dice que no deben estar indexadas. Como ya hemos visto en varios posts anteriores, el fichero robots.txt dice que no se indexe el contenido en esa URL, pero no que no se indexe la URL o se guarde una copia de la misma en la caché del buscador.

Figura 1: Google indexado cosas en plus.google.com que filtra su robots.txt.
No se acalaran ellos tampoco con las opciones de indexing & caching.

Esto afecta a casi todos los sitios, por poner algunos ejemplos. El robots.txt de Google.com dice que no se indexe el contenido de la ruta /profiles/me y si buscas esas URLs con un site:google.com/profiles/me encontrarás un montón de rutas con info de acciones indexada.

Figura 2: Sección del robots.txt de IBM

Esto también pasa con IBM y su robots.txt, donde se pide que no se indexe la ruta /contact/employees/servlets y sin embargo buscando URLs con esas rutas en Google es posible encontrar una buena cantidad de ellas, incluso algunas que usan el servicio Lookout de búsqueda de empleados con las respuestas cacheadas en Google.

Figura 3: Algunas búsquedas de empleados de IBM indexadas en Google

En el caso de IBM me llamó también la atención la posibilidad de encontrar algunos de los surveys que se envían a clientes - sin ningún dato, eso sí - pero con las preguntas que se hacen.

Usando el robots.txt, la indexación de URLs de Google y la caché de Archive.org

En algunas ocasiones la URL que descubres indexada en Google ya no devuelve los datos originales, y hace un redirect a otra página o a un error 404 bien bonito. En esos casos, esa URL que no ha sido eliminado utilizando las Herramientas del Webmaster puede seguir siendo útil, sólo hay que ir y buscarla en Archive.org para localizar qué contenido había allí.

Figura 4: URL indexada en path prohibido por robots.txt encontrada en Archive.org

Yo lo he hecho en algún sitio grande, grande, y han salido documentos curiosos con información útil para organizar un posible ataque dirigido que venga desde el pasado.

Usando la búsqueda de robots.txt y los ficheros comprometedores

Como robots.txt está indexado por Google - algo que sigo pensando que no debería ser así - se pueden hacer dorks para buscar ficheros curiosos que aparecen directamente en ellos. Se pueden buscar cosas como backup.zip, backup.tar, .bash_history, db.mdb, clientes.mdb, etc... que aunque pocos de cada uno aparecen muchos de ellos.

Figura 5: Ficheros .bash_history filtrados por robots.txt

Algunos directamente pueden ser utilizados para meter shells en ellos, ya que si buscas uploap.php, uploadfile.php, uploaddoc.php, etc... dentro de los ficheros robots.txt acaban saliendo muchos sin control de sesión.

Usando búsqueda en robots.txt, directorios clave y el bug de IIS 8:3

Una de las cosas que se puede hacer para acabar de comprometer un sitio es buscar a través de Google en los robots.txt un directorio llamativo, tipo intranet, private, database, o cualquier otro. Después probar el bug de IIS que permite listar los ficheros en formato 8:3, que aunque ya empieza a no estar tan extendido como estaba antes, sigue siendo relativamente sencillo de encontrar en los IIS y acaba saliendo el listado de archivos con los datos privados de los sitios, como ya hicimos con Apple.com.

Figura 6: Plugin de FOCA Pro para extraer ficheros con el bug de IIS Short Name

Usando búsqueda en robots.txt y los repositorios de código fuente

Otro de los trucos que se puede automatizar es la búsqueda de los repositorios de código. Estos pueden ser la mayor fuente de información para acabar con la seguridad de un servidor, por lo que hay que proteger los Subversion para que no aparezcan los ficheros .SVN/Entries o las bases de datos de ficheros pristine o wc.db - que se pueden analizar después con Recover Messages -.

Figura 7: Robots.txt "protegiendo" un repositorio de código

Pero no solo eso, hay muchos más repositorios de código que pueden utilizarse para sacar información sensible de un sitio, y todos ellos pueden localizarse con dorks lanzadas sobre los ficheros robots.txt.

Evita la indexación de los robots.txt

A día de hoy nadie se aclara con las opciones de indexing & caching en los buscadores, por lo que el hacking con buscadores sigue siendo una fuente inagotable de información. Yo os dejo algunas ideas para evitarlo:

1) Que los buscadores indexen los robots.txt me parece un error, así que creo que, por si lo respetan, el primer fichero que debería aparecer en todo fichero robots.txt es el mismo robots.txt, para que no se indexe.

2) Organiza el sitio para que el fichero robots.txt de la mínima información posible.

3) Elimina con las herramientas de los webmasters todas las URLs de carpetas que están filtradas por el robots.txt. Para ello, establece una alerta dentro de tu servicio de ciberseguridad y que no haya absolutamente nada fuera de lo que tu deseas.

4) Usa bien las opciones Meta y X-Robots-tags para evitar al máximo la fuga de información, que una vez que la tienes, permanece para siempre.

5) Revisa la construcción de URLs de tus webs para que la información sensible que va en ellas sea la menor posible.

Y lo último... ¿no os parece que estas opciones de indexación y caché que tienen los buscadores no están demasiado bien pensadas desde el punto de vista de la seguridad en Internet?