Fuzzing encontrando cosas olvidadas, hace unos días en DragonJAR publicábamos un artículo sobre Dirb, para hacer fuzzing sobre servidores web, en el artículo explicábamos que con el fuzzing llegábamos a descubrir directorios ocultos entre otros cosas.
Fuzzing encontrando cosas olvidadas con Wfuzz
Vamos a ver un ejemplo práctico, pero hoy no usaremos Dirb, pasaremos a usar Wfuzz.
Tabla de Contenido
Página de acceso
Tenemos la típica página de acceso a un recurso interno de una corporación.
La página de acceso es algo así como:
https://paginadeacceso.acceso.dragonjar.org
Cuando los clientes o proveedores externos entran a esa páginas son redireccionados hacia otra página donde han de introducir su usuario y password para acceder al recurso interno.
La URL a donde redireccionaba era algo así como:
https://acceso.dragonjar.org/acceso_1/index.php
El usuario era redirigido con un código 302.
Lo primero que haremos con curl, es ver como se comporta, así que lo hacemos.
darkmac:~ marc$ curl -I https://paginadeacceso.acceso.dragonjar.org
HTTP/1.1 302 Found
Location: https://acceso.dragonjar.org/acceso_1/index.php
Vi que siempre hacía el mismo 302 a el mismo sitio, así que lo más sencillo es lanzar un fuzzer para ver si hay más páginas.
¿Donde colocar el Fuzzer?
El fuzzer lo podemos colocar en múltiples sitios, pero en este caso en concreto, lo colocaremos donde tenemos marcado el texto con negrita.
https://acceso.dragonjar.org/acceso_1/index.php
Vamos a generar un diccionario para que el fuzzer pruebe distintas posibilidades.
Para generar el diccionario podemos tirar de bash, algo tan sencillo como:
for (( i=0; i<1000; i++ ))
do
echo $i
done
Una vez generada la lista que vamos a probar la lanzamos con Wfuzz, algo así como:
python wfuzz.py -c -z file,lista.txt –hc 404 -o html https://acceso.dragonjar.org/acceso_FUZZ/index.php 2> report.html
Ya hemos lanzado el fuzzer, una vez acabe guardará los resultados en un report que tendrá el siguiente aspecto:
A la izquierda tendremos el código de respuesta, como veis hemos encontrado varios códigos 200, por lo que hay más de una página de acceso.
¿Estarán securizadas?
El fuzzing más allá de los directorios
El artículo que acabas de leer muestra una de las aplicaciones más directas del fuzzing: descubrir recursos ocultos en un servidor web probando miles de entradas de forma automática. Esa técnica —fuzzing de contenido web— sigue siendo pan de cada día en un pentest.
Pero el fuzzing moderno va mucho más allá. Cuando el objetivo no es una URL sino un binario, una librería o un protocolo de red, se usa el fuzzing guiado por cobertura: el programa objetivo se instrumenta para registrar qué rutas de código recorre cada entrada; las entradas que descubren rutas nuevas se mutan y se reinyectan, expandiendo iterativamente la cobertura del código probado. Es una búsqueda dirigida, no un bombardeo ciego: cada iteración aprende de la anterior.
Ese enfoque lo sostienen hoy herramientas de referencia como AFL++ —el fork mantenido de AFL—, libFuzzer —la librería de fuzzing integrada en LLVM—, honggfuzz —con énfasis en seguridad y multiproceso— y servicios como OSS-Fuzz, el programa de Google que ofrece fuzzing continuo gratuito para proyectos de código abierto. Si auditas binarios o software propio, este es el fuzzing que te interesa conocer: documentación de libFuzzer, AFL++, honggfuzz, OSS-Fuzz.
Dónde encaja el fuzzing en tu flujo
En un pentest, el fuzzing es una fase de descubrimiento, no un veredicto. Que un fuzzer encuentre un directorio con código 200 no significa que sea vulnerable: significa que existe y merece revisión manual. La disciplina es la misma que en el ejemplo del artículo —lanzar, filtrar el ruido, investigar cada hallazgo— aplicada a cualquier superficie: parámetros, cabeceras, endpoints de API o formatos de archivo.
Dos prácticas que pagan: primero, versiona tus diccionarios y semillas. Un hallazgo que no puedes reproducir es un hallazgo que no puedes reportar con rigor. Segundo, combina el fuzzing de caja negra —como el del artículo— con revisión del código cuando lo tengas disponible; el fuzzing guiado por cobertura rinde mucho más cuando entiendes qué partes del programa estás ejercitando.
Y la regla de siempre: fuzzing solo contra objetivos autorizados. Automatizar miles de peticiones contra un sistema ajeno no es reconocimiento pasivo; es actividad que deja huella y que, sin permiso, te mete en problemas.
