CTF Morpheus: 1 – Parte 2: Fuzzing Web y Análisis del Vector de Entrada

Introducción: En esta segunda entrega del writeup ctf sobre la máquina Matrix BreakOut (Morpheus: 1), profundizamos en la auditoría web analizando rutas ocultas, metadatos multimedia y la detección de parámetros vulnerables en el aplicativo.

📺 Serie completa en YouTube: Playlist CTF – Matrix BreakOut

🔗 Videos de esta entrega:
– Matrix07 – Lanzamiento y configuración de DirBuster
– Matrix08 – Inspección de recursos multimedia y metadatos
– Matrix09 – Navegación de rutas descubiertas y prueba de muro graffiti
– Matrix10 – Documentación en CherryTree e inspección del código fuente
– Matrix11 – Escaneo de vulnerabilidades con scripts NSE de Nmap

ALT-TEXT: Máquina Matrix BreakOut – Parte 02.

Por qué es importante

El escaneo de puertos inicial solo entrega la periferia del sistema. En el plano de las aplicaciones web, los administradores y programadores incurren con frecuencia en dos errores fundamentales:
1. Dejar archivos de texto plano, notas operativas o copias de respaldo accesibles directamente a través del navegador.
2. Delegar la lógica de negocio al cliente mediante campos ocultos de formulario (<input type="hidden">), asumiendo erróneamente que el usuario no tiene la capacidad de modificarlos.

Enseñar a los estudiantes a correlacionar los hallazgos de un fuzzer con la lectura manual del código fuente HTML permite reconocer vectores de entrada críticos sin recurrir a escáneres automáticos a ciegas.

Desarrollo

Módulo 1: Fuzzing Automatizado de Directorios y Archivos (Video 07)

Video de referencia: Matrix07 (02:20)

1. Configuración del escaneo de rutas en DirBuster

Qué se hizo: Se configuró y lanzó OWASP DirBuster contra el servidor web Apache en el puerto 80 (http://192.168.111.250:80/), cargando el diccionario directory-list-2.3-medium.txt y parametrizando extensiones de archivo específicas: php, txt, html.
Por qué se hizo: Las páginas web en entornos de evaluación no suelen contener enlaces explícitos a sus paneles o utilidades internas. El objetivo táctico fue encontrar endpoints y scripts que permanecen invisibles durante la navegación normal.
De qué sirvió la herramienta (OWASP DirBuster): Gestiona múltiples peticiones concurrentes y clasifica las respuestas por su código HTTP (200 OK, 301 Redirect, 403 Forbidden), mapeando en pocos minutos el árbol interno de carpetas y archivos del servidor.

ALT-TEXT: Configuración de OWASP DirBuster con diccionario medium y extensiones php, txt y html.

Módulo 2: Inspección Forense de Recursos Multimedia (Video 08)

Video de referencia: Matrix08 (02:18)

2. Extracción y análisis de metadatos con ExifTool

Qué se hizo: Se descargó a la máquina atacante la imagen expuesta en la página web principal (trinity.jpg) y se ejecutó un análisis de metadatos en consola con la utilidad exiftool trinity.jpg.
Por qué se hizo: En ejercicios de estilo CTF y en auditorías forenses, los archivos multimedia pueden alojar comentarios del desarrollador, hashes, pistas esteganográficas o coordenadas en los campos EXIF/IPTC.
De qué sirvió la herramienta (ExifTool): Permite leer y desglosar todos los metadatos incrustados en archivos binarios e imágenes sin alterar su firma original, confirmando si el autor del reto dejó vectores o credenciales ocultas en el recurso.

Módulo 3: Validación Funcional de Rutas Descubiertas (Video 09)

Video de referencia: Matrix09 (04:22)

3. Interacción con los endpoints y el aplicativo Graffiti

Qué se hizo: Conforme DirBuster arrojó resultados, se probaron las URLs directamente en el navegador:
/robots.txt: arrojó un mensaje temático de señuelo (“There’s no white rabbit here. Keep searching!”).
/notes.txt: contenía notas internas dejadas por los supuestos usuarios.
/graffiti.php: aplicación interactiva titulada “Nebuchadnezzar Graffiti Wall”. Se envió un mensaje de prueba (“Test writeup”) y se verificó que el contenido quedaba persistido y legible en /graffiti.txt.
Por qué se hizo: Para auditar una aplicación web es indispensable entender su flujo de trabajo: qué parámetros recibe, qué operaciones de lectura/escritura ejecuta en disco y bajo qué formato refleja la información.
De qué sirvió la técnica (Prueba de funcionalidad web): Evidenció que existe una rutina en el backend que toma texto del usuario y lo guarda en un archivo plano en el servidor.

Módulo 4: Auditoría del Código Fuente y Hallazgo Crítico (Video 10)

Video de referencia: Matrix10 (01:58)

4. Detección del campo oculto de archivo de destino

Qué se hizo: Se consolidaron las rutas en el árbol de CherryTree y se analizó el código fuente (Ctrl + U) del formulario en /graffiti.php. Se detectó la siguiente estructura:
“`html

`` * **Por qué se hizo:** El código reveló que el archivo donde se guardan los mensajes no está fijado de forma rígida en el backend, sino que viaja como un parámetro POST manipulable por el usuario (file=graffiti.txt). * **De qué sirvió la metodología (Inspección del lado del cliente):** Permite identificar de inmediato un vector de **escritura arbitraria de archivos** (*Arbitrary File Write*). Si el backend no sanitiza este parámetro, un atacante puede cambiargraffiti.txtpor un archivo.php` y escribir código ejecutable en el servidor.

ALT-TEXT: Código fuente HTML del formulario graffiti.php mostrando el parámetro oculto file.

Módulo 5: Verificación de Vulnerabilidades con Nmap NSE (Video 11)

Video de referencia: Matrix11 (00:40)

5. Escaneo no invasivo de vulnerabilidades conocidas

Qué se hizo: Se ejecutó un escaneo de scripts de Nmap enfocado en la categoría de fallos conocidos: sudo nmap --script vuln -Pn 192.168.111.250.
Por qué se hizo: Es una buena práctica formativa contrastar la auditoría manual con la detección automatizada de CVEs conocidos sobre los servicios de red (SSH, Apache, Nginx) para descartar o confirmar fallos a nivel de software base.
De qué sirvió la herramienta (Nmap Vuln Engine): Ejecuta scripts Lua dirigidos para comprobar debilidades conocidas sin necesidad de instalar escáneres de vulnerabilidades pesados, confirmando que el vector de compromiso principal radica en la aplicación web y no en un fallo nativo de los demonios de red.

Conclusión

El uso sistemático de DirBuster y el análisis minucioso del código fuente demostraron que el punto crítico de la máquina no proviene de un exploit prefabricado, sino de una falla de diseño web: confiar en un campo oculto (<input type="hidden" name="file">) para gestionar la escritura de archivos en el servidor.

💡 Próximos pasos: En la Parte 3 aprenderemos a interceptar y modificar esta petición HTTP utilizando un proxy local (Burp Suite) para inyectar código PHP malicioso y obtener la shell inicial del sistema.

Recursos útiles

Enlaces del curso y laboratorio:
– Playlist completa en YouTube
– Parte 1: Reconocimiento y Fuzzing
– Video Matrix07: OWASP DirBuster
– Video Matrix10: Análisis de Código Fuente

Documentación complementaria:
– OWASP: Arbitrary File Write Vulnerabilities
– Documentación de ExifTool por Phil Harvey
– Guía de Scripts NSE en Nmap