Técnicas para descubrir los ficheros de un sitio web 1 de 2

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. Por supuesto, encontrar objetivos rápidos se puede hacer con el truco de la barra en Google.

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 & DWSync.XML

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

Un caso similar a este es el del fichero DWSync.xml que crea DreamWeaver para hacer más o menos lo mismo, la comprobación de la sincronización de ficheros.

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

Hasta aquí los 10 primeros sitios a mirar, en la segunda parte tienes otra buena tanda de sitios y formas para encontrar las URLs que nos lleven a los nombres de los ficheros, para así poder encontrar los que sean juicy files.

Saludos Malignos!

FOCA Intruder: Usando FOCA + Burp Intruder

En este post se pretende explicar cómo obtener un informe inicial de las vulnerabilidades más genéricas que son detectadas de manera eficiente tanto por FOCA como por Burp Suite. Es decir, cómo comenzar la auditoría de seguridad de las webs de una empresa utilizando la fuerza combinada de descubrimiento de objetivos y vulnerabilidades más comunes de FOCA, junto con el módulo Intruder de Burp. Lo que nosotros en Informática64 llamamos FOCA Intruder.

En esta ocasión, a diferencia de cómo so contamos que podía ser utilizado el Spider de Burp para alimentar FOCA en los trucos de Hacking FOCA,  ahora vamos a utilizar FOCA para alimentar el módulo de Burp Intruder.  Estos son los requisitos mínimos de hardware y software para montar este escenario:

- FOCA: en cualquiera de sus versiones Free o Profesional, pero si vas a hacer una auditoría de seguridad profesional, FOCA PRO va a descubrir más vulnerabilidades y de forma más rápida. 

- Burp Suite: preferentemente la versión profesional debido a las penalizaciones de rendimiento existentes en la versión Free. Si vas a hacerlo profesional, cómprate esta herramienta.

- Memoria RAM: Al menos entre 4 y 8 GB, en función del tamaño del dominio, sería lo óptimo. FOCA tiende a requerir grandes cantidades de memoria en función de los resultados obtenidos y Burp Suite se vuelve inestable cuando el historial de navegación crece demasiado si no se le ha preasignado al menos 2 GB al arrancar (en línea de comandos utilizar el parámetro -Xmx2g). 

- Conexión de red: Un buen ancho de banda para las pruebas, que de lo contrario te vas a eternizar si el dominio es grande.

Una vez se dispone de los recursos necesarios llega el momento de configurar FOCA y Burp. Para ello nuestra querida FOCA debe ser configurada para que realice todas las pruebas de manera automática y, más importante aún, para que redireccione todas las pruebas a través de la dirección IP de escucha del proxy local de Burp. También es conveniente usar el USER-Agent de un bot de Google, por aquello de encontrar cosas especiales en las web si el administrador del sitio ha hecho cloaking.

Figura 1: Configuración de Proxy y User-Agent en FOCA

Una vez configurada FOCA, llega el turno de meterle mano a Burp, que en primer lugar debe estar en modo agresivo con el objetivo de obtener los mejores resultados, para ello hay que configurar 4 aspectos principalmente:

1. Especificar en el Scope el dominio auditar de la manera más genérica posible, es decir, añadiendo el elemento especificando solamente el dominio de la web con o sin extensión.

Figura 2: Configuración del dominio objetivo en Burp

2. En las opciones de Proxy Listeners, debe estar correctamente configurada la dirección IP y el puerto de escucha.

Figura 3: Configuración del listener del Proxy en Burp

3. En las opciones del Spider hay que configurarlo para que realice el proceso de manera automática sobre los elementos definidos en el Scope.

Figura 4: Configuración del Spider

4. Por último, en las opciones de Live Active Scanning hay que configurar tanto el modo pasivo como el activo de manera automática en los elementos definidos en el Scope.

Figura 5: Configuración del escáner en vivo

Tras configurar ambos programas llega el momento de empezar la pre-auditoría. Para ello basta con pulsar los botones “Start”, en Network, y “Search All”, en Metadata, de la FOCA o lanzar el Network Discovery en FOCA. Después hay que esperar los resultados para pasar a realizar la auditoría manual de lo que vaya siendo sospechoso.

De manera adicional, y como fase de mantenimiento, se recomienda limpiar con cierta frecuencia el Historial del Proxy y revisar que el escáner activo está funcionando con normalidad. En caso contrario será necesario indicarle a Burp que analice de manera activa cada uno de los subdominios detectados por FOCA, que aparecerán listados en “Site Map”, en la pestaña de Target.

Por supuesto, para hacer una auditoría de seguridad de una empresa hay que hacer mucho más trabajo, pero usar FOCA Intruder de principio hace que haya mucho trabajo automatizado de inicio, y nos va a ayudar a enfocar - nunca mejor dicho - el resto de la auditoría.

Autor:  José Miguel "Binario", consultor de Informática64