Mejorando los resultados sobre descubrimiento de recursos web ocultos

Una de las fases dentro de la auditoría web es la exploración de recursos. Esto es un proceso iterativo: Exploración, detección, pruebas, análisis de resultados y si encuentras nuevos puntos de ataque otra vez de vuelta al principio. Existen multitud de herramientas para hacerlo: Golismero, BurpSuite, o el venerable DirBuster, sin actualizar desde 2009, lo hacen entre otras muchas funcionalidades.

El funcionamiento de este tipo de herramientas es simple. Recorren el sitio web como una araña web, recolectan enlaces a recursos y generan un bucle hasta que terminan en algún punto. Lo ideal es que recorran toda la jerarquía de directorios y páginas que formarán un árbol jerárquico. Con esto tienes una foto de todos los recursos públicos de una aplicación web y ya puedes comenzar con la siguiente fase, pero...eso solo es el comienzo.

Casi la gran mayoría de aplicaciones web tienen ciertos recursos ocultos o más bien no publicados, recursos que no están ni indexados por el todopoderoso GoogleBot, sencillamente porque ninguna de las rutas lleva hacia allí.

¿Cómo encuentras algo que se supone no debería estar ahí?

Existen multitud de técnicas. La más ingenua es mirar en el robots.txt, donde se supone que no quieres que indexen cierto contenido. Curiosamente, a los ojos humanos o de un bot que no respete el estándar de facto, el robots.txt termina ofreciendo la funcionalidad inversa a la supuesta. Anunciar recursos.

La técnica más común es tener un diccionario de recursos comunes y emplearlo a base de peticiones contra la aplicación. En teoría si el recurso está obtendrás un código 200 Ok de lo contrario un 404 Not Found, si el recurso se encuentra en otra dirección un 30x y si su acceso está restringido un 403 Forbidden. 

Esto naturalmente se da en un mundo ideal. Vamos a hablar de un caso particular.

En determinadas ocasiones, sabes que un recurso se encuentra en un lugar porque recibes un código 200:

carpeta1/carpeta2/recurso.php

Pero en "carpeta1" y en "carpeta2" pueden existir algunos más que no estén publicados. El problema para las herramientas viene al pedir, por ejemplo:

carpeta1/carpeta2/

Dará un 404 aunque sepamos que "carpeta2" es un recurso que existe. Así, si intentamos efectuar un descubrimiento de carpetas comunes por diccionario para posteriormente explorarlo con nombre.extensión nos dará una ristra interminable (tan larga como el diccionario) de respuestas 404 donde seremos incapaces de distinguir cuales existen y cuales no.

Sin embargo, gracias a ciertas configuraciones, pidiendo ciertos tipos de archivos nos dará un código diferente al 404, revelando así la existencia de nuevos recursos procedente de nuestro diccionario.

Uno de los ejemplos es la regla que impide el acceso al archivo .htaccess de Apache:

<Files ~"^\.ht">

     Order allow,deny

     Deny from all

     Satisfy all

</Files>

Esto genera un código de respuesta 403 al pedir un archivo .ht****

Lo curioso es que si la ruta es la adecuada recibiremos el 403 y nos indicará que hemos dado con algo que existe. Por contra si obtenemos un 404 ya podemos descartar esa entrada.

Esto no nos va a valer en todos los casos. Al igual que en una inyección ciega de código SQL tienes que estudiar como responde el servidor ante un grupo de peticiones estrategicamente construidas para observar las respuestas.

Haciendo una prueba con una pequeña herramienta que estamos desarrollando de manera informal para probar nuevas técnicas y que nos complementa las que ya tenemos nos da resultados interesantes:

El primer pase es sin la terminación '.ht' donde cualquier recurso, aun existente, dará un 404:

 Solo dos resultados y estos son debido a que piden autenticación, código 401.

El siguiente pase es adaptando las peticiones a la técnica descrita:

Hemos triplicado los resultados. Esto es sobre un directorio previo donde se supone no debería haber muchos recursos y usando un diccionario con un número de entradas relativamente pequeño.

Sobre la herramienta: Hispasec no da soporte oficial ni es responsable de un uso inadecuado. No la podemos considerar preparada para su uso profesional, al menos en ese ámbito, se recomienda usar alternativas, como las ya comentadas arriba, que van a proporcionarnos un mejor resultado.