Técnicas para descubrir los ficheros de un sitio web

Buenos días,

Las siguientes entradas tratan de encontrar ficheros importantes sobre nuestro sitio web , esto ya lo hemos trabajado en el blog pero copio estas dos entradas del blog del chema las cuales me parecieron que sirve para entender muchos conceptos.

____________________________________________________________________________

Una de las cosas que es necesario realizar cuando se hace una auditoría es qué archivos hay en el servidor web, ya que en cualquiera de ellos puede estar la llave con que abrir la lata. Para ello existe una gran variedad de maneras de intentar encontrar todas las carpetas y ficheros que en el servidor web están "ocultos" a simple vista. Encontrarlos es un juego divertido similar a buscar las piezas de un puzzle que permitan ver la foto completa que se esconde tras el nombre de dominio original, y son diversas.

Muchas de estas técnicas están implementadas en FOCA, otras no, y como quiero que se implementen, este fin de semana pasado le dedique un tiempo a recopilarlas todas en una lista que me ha quedado un poco larga, por lo que os la voy a publicar en un par de posts. Estas son todas ellas:

1.- Crawling

La primera y más evidente es leer los códigos fuentes de las páginas web de un sitio y seguir todos los enlaces que de ellas se pueden extraer. Esto es algo que tradicionalmente hacemos con Burp Suite ya que podemos conectar la búsqueda de URLs con las pruebas de FOCA. El módulo de spidering es suficientemente bueno cómo para sacar un fichero con todas las rutas a archivos de un sitio.

Figura 1: Spidering con Burp

2.- Robots.txt

Estos archivos guardan rutas a documentos y carpetas, así que por si el crawling no hubiera encontrado todos, merece la pena darles una lectura a ver qué aparece por allí. Algunas veces pueden aparecer rutas sorprendentes como vimos con el robots.txt de RTVE o curiosas como el famoso robots.txt de la Casa Real.

3.- Sitemap.xml

Los archivos sitemap.xml también recogen ficheros y contenidos de un sito. Generalmente son URLs públicas con información para mejorar la indexación que de un sitio hacen los buscadores. Conviene sacar estas URLs y alimentar con ellas el motor de crawling, por si el sistema se hubiera parado antes de localizar una de esas direcciones.

Figura 2: El sitemap.xml de Casa Real a día de hoy

4.- Buscadores

Los buscadores pueden indexar URLs que hayan llegado a su base de datos por medio de un enlace directo que se haya puesto en alguna otra página - recordad el caso de los XSS-Google Persistentes - o porque alguna barra del navegador o el mismo Google Chrome, hayan reportado esa URL como el caso de Blogger y la predicción del futuro o el sofá del Bank of América. Hay que revisar los archivos indexados por los buscadores. Además, un fallo de configuración antiguo de un sitio puede haber sido utilizado para indexar los archivos, y están en la base de datos del buscador.

5.- Directory Listing

Por supuesto, hay que revisar todas las carpetas de todas las URLs para encontrar aquellas que puedan tener un directory listing abierto. Esta es la mejor de las opciones, pues permite ver todo lo que hay en una carpeta sin necesidad de buscar más.

6.- Ficheros .listing

Los ficheros .listing, que son creados por el wget son un ls -la de la carpeta donde se ha subido o de donde se han descargado determinados ficheros. Aunque no tienen porque ser lo que haya en ese directorio, si que salen muchas URLs que deben ser probadas.

Figura 3: Aspecto de un fichero .listing

7.- Ficheros .DS_Store

Los ficheros .DS_Store generados por el infame Finder de Mac OS X han demostrado ser una fuente jugosa de información para obtener archivos y carpetas de un directorio, tal y como vimos esta semana con el programa DS_Store.

8.- Ficheros Thumbs.db

Los ficheros Thumbs.db también guardan nombres de archivos - y miniaturas - de los thumbnails asociados a los archivos en Windows XP o Windows 2003. Para analizar los ficheros thumbs.db podéis utilizar el servicio online que está disponible hace mucho tiempo en Informática64 llamado Thumbando.

Figura 4: Salida de Thumbando cuando se le pasa un Thums.db

9.- Repositorios de código fuente de los sitios web

En ellos suelen quedar ficheros que registran los archivos subidos y/o actualizados en cada post de un desarrollador. Sistemas como subversion o BuildBot pueden ser auténticas fuentes de información para conocer qué hay en un sitio web escondido, donde el amigo .SVN/Entries y su base de datos wc.db junto con el directorio pristine son un autentico regalo en una auditoria. 

10.- Ficheros de error 404

Los mensajes de error también pueden tirar rutas internas o del sitio web. De ellos merece la pena recordar los mensajes de error 404 en aplicaciones ASP migradas a IIS 7, o los mensajes de error 404 en documentos TCL de WebDNA.

Figura 5: Rutas en un mensaje de error 404 de IIS con ASP

11.- Multiple Choices con Mod_negotiation

Cuando se solicita un fichero que no existe en el servidor web este módulo de Apache devuelve la lista de ficheros que se llaman igual que el solicitado, pero que tienen distintas extensiones. Es perfecto para encontrar backups de ficheros, por lo que la idea es tan sencilla como solicitar todos los ficheros  que se conocen en el servidor y pedirlos sin extensión. A ver qué sale.

Figura 6: Ficheros de backup descubiertos con mod_negotiation

12.- Fuzzing estático

Las técnicas de fuzzing en web construyen a partir de palabras de un diccionario reglas de predicción de nombres de archivos y carpetas. Estas técnicas tuvieron su exponente hace tiempo ya en la herramienta Wikto de Sensepost, que hacía todo esto de manera eficiente y añadió lógicas de inspección de carpetas y parametrización por tipos de archivos.

Figura 7: Wikto

13.- Fuzzing dinámico

En este caso la idea es generar los nombres de fuzzing en tiempo real a media que el crawler, o el motor de spidering que se utilice descubra nuevos ficheros basandose en los nombres encontrados. En FOCA se añadió un pequeño módulo llamado Backups que realiza fuzzing dinámico buscando los posibles nombres de las copias de seguridad de los ficheros seleccionados. Si no recuerdo mal, esto solo estaba en la FOCA PRO.

Figura 8: Backups buscados con FOCA PRO

14.- Diccionario de software conocido

Por supuesto, puestos a hablar de fuzzing, hay que citar que otra manera es utilizar las herramientas que llevan cargadas las rutas donde se instalan los archivos de las aplicaciones web más comunes, como el caso de Moodle, Wordpress, Joomla, etcétera. El éxito es tener el diccionario de todas las rutas de todas las versiones de todo el software, así que sería fácil localizar una buena cantidad de archivos en el momento en que se detecte el software instalado. Una buena herramienta para hacer esto es SWAT (Swiss Web Attack Tool).

Figura 9: Módulos que se pueden probar en SWAT

15.- Metadatos de documentos ofimáticos

Por supuesto, si os digo que la FOCA hace esto, supongo que no os digo nada nuevo. La idea es que en muchos archivos, especialmente archivos PDF generados con impresoras virtuales que crean documentos desde un sitio web, en el mismo campo título queda la ruta de la aplicación que lo generó.

16.- Directorios de usuarios con Mod_user_dir en Apache

Este es otro ejemplo para descubrir URLs haciendo uso de la publicación de los $HOME de los usuarios del sistema en servidores web Apache. Si se detecta uno de ellos, es bueno hacer un poco de fuzzing a las rutas /~usuario para ver si existen. Para ello se puede usar un diccionario de nombres de usuarios a lo bestia o nombres de usuario extraídos de los metadatos de los archivos publicados en el sitio, o de alguna web que hayas podido "scrappear".

Además, si has descubierto el módulo mod_user_dir, deberías probar a lanzar un fuzzing de los archivos de perfil de los usuarios en *NIX*. Puede que aparezcan los .login, .bashrc, .profile, .bash_profile y compañía por allí.

17.- Bug de IIS Short name

Ya hemos hablado mucho de esto. Si hay un IIS 6 o un IIS 7, debes probar a ver si es posible enumerar los nombre 8:3 de los archivos mediante este bug. En FOCA hicimos un plugin, pero puedes hacerlo a manopla en el sistema.

18.- URLs de web históricas

A veces, cuando se migra la web, los archivos del sitio web anterior siguen en el servidor. Solo hay que tener las rutas y buscarlas. Para ello, usar un servicio como Archive.org puede darte una buena cantidad de URLs que utilizar. Para ello hay que hacer crawling con las copias, limpiar un poco las URLs que te salen y por último generar un fichero de diccionario que puedas lanzar con tu fuzzer favorito. Trabajosillo, pero salen cosas.

Figura 10: URLs de la web del FC Barcelona del año 1998

19.- Decompiladores

Otro sitio donde pueden salir muchas URLs es en los archivos compilados. Casos como los Applets Java o los archivos .swf pueden darte mucha información de nuevas URLs, y puede que localices hasta los códigos fuentes de estos mismos. Esto también pasa en los archivos binarios, ya que también salen rutas en ellos, aunque normalmente son del equipo donde se trabajó con ellos, como en el caso de la operación Aurora.

Figura 11: La ruta que dio nombre a la operación Aurora

20.- Peticiones de plugins

El último sitio que os voy a dejar en esta lista son los componentes que hacen peticiones al servidor. Casos como los ActiveX que son difíciles de decompilar - a pesar de que hay muchas y buenas alternativas para analizarlos - en el caso de que quieras hacer una lista de URLs, podrías analizar las peticiones que espera recibir del servidor y enchufárselas, a ver qué sale por ahí...

Al final, como se ve en estos casos, hay muchas formas de conseguir sacar un poquito más de información de una web.

FUENTES:

http://www.elladodelmal.com/2013/04/tecnicas-para-descubrir-los-fiheros-de.html

http://www.elladodelmal.com/2013/04/tecnicas-para-descubrir-los-ficheros-de.html