Day 11: Merry XXS-Mas - Advent of Cyber 2025

Este writeup pertenece al evento Advent of Cyber 2025 de TryHackMe. Si quieres seguir toda la serie, consulta nuestra colección completa del Advent of Cyber 2025.

Hoy nos enfrentamos a una aplicación web que parece haber sido desarrollada con prisas para la temporada navideña. Los conejos traviesos han dejado vulnerabilidades críticas que permiten la ejecución de código malicioso en el navegador de los usuarios.

Para abordar este reto, vamos a cambiar un poco la dinámica. En lugar de simplemente resolver el puzzle, vamos a estructurar nuestro análisis siguiendo las fases de una metodología de pentesting profesional.

Room: XSS - Merry XSSMas
Dificultad: Easy
Objetivo: Identificar y explotar vulnerabilidades de Cross-Site Scripting (XSS) Reflejado y Almacenado.

🕵️ Fase 1: Reconocimiento

Lo primero que hacemos al enfrentarnos a un objetivo web es mapear la superficie de ataque. Accedemos a la aplicación y observamos su funcionalidad.

Identificamos dos puntos de entrada de datos principales:

1. Barra de búsqueda: Permite buscar mensajes existentes.
2. Formulario de mensajes: Permite enviar nuevos mensajes que (presumiblemente) se guardan en el servidor.

Además, vemos un panel de logs del sistema en la parte inferior, lo cual nos puede dar pistas sobre cómo el backend procesa nuestras peticiones.

🔍 Fase 2: Análisis y Escaneo

En esta fase, buscamos vulnerabilidades potenciales. Dado que tenemos campos de entrada que reflejan su contenido en la pantalla (la búsqueda muestra lo que buscaste, y los mensajes se muestran en un feed), la vulnerabilidad más probable es Cross-Site Scripting (XSS).

El XSS ocurre cuando una aplicación incluye datos no confiables en una página web sin validarlos o escaparlos adecuadamente. Esto permite que el navegador ejecute esos datos como código (generalmente JavaScript).

Nuestra hipótesis es doble:

• Reflected XSS: En la barra de búsqueda. Si el input se refleja inmediatamente sin saneamiento, podemos ejecutar scripts.
• Stored XSS: En el formulario de mensajes. Si el mensaje se guarda en la base de datos sin saneamiento, el script se ejecutará cada vez que alguien cargue la página.

💥 Fase 3: Explotación

Vamos a validar nuestras hipótesis inyectando "payloads" (cargas útiles) de prueba.

Explotando Reflected XSS

Probamos inyectando un script básico en la barra de búsqueda. Si la aplicación es vulnerable, el navegador interpretará las etiquetas <script> y ejecutará el código.

Payload utilizado:

<script>alert('Reflected XSS')</script>

Al enviar la búsqueda, la aplicación no solo ejecuta el script, sino que, como parte del reto, nos revela la primera flag en el pop-up o en la interfaz.

Click para ver imagen

Explotando Stored XSS

Ahora vamos a por el premio mayor: la persistencia. Si logramos guardar un script en el servidor, afectaremos a cualquier usuario que visite la página, no solo a nosotros mismos.

Introducimos el siguiente payload en el cuerpo del mensaje:

<script>alert('Stored XSS')</script>

Al enviar el mensaje, este se guarda. Ahora, cada vez que recargamos la página o navegamos por la sección de mensajes, el script se ejecuta automáticamente.

Click para ver imagen

💀 Fase 4: Post-Explotación

En este entorno de laboratorio (CTF), el objetivo era conseguir las flags. Sin embargo, en un escenario real, un atacante no se limitaría a mostrar una alerta. Con un XSS confirmado, un atacante podría:

1. Robo de Sesiones (Session Hijacking): Enviar las cookies de sesión del usuario (document.cookie) a un servidor controlado por el atacante, permitiéndole suplantar la identidad de la víctima sin necesitar su contraseña.
2. Keylogging: Inyectar un script que registre cada tecla pulsada por el usuario y la envíe al atacante.
3. Phishing Interno: Modificar el DOM de la página para mostrar un formulario de login falso y robar credenciales.
4. Acciones en nombre del usuario: Forzar al navegador del usuario a realizar acciones (como cambiar la contraseña o realizar transferencias) sin su consentimiento.

📝 Fase 5: Reporte y Remedición

Para finalizar, documentamos los hallazgos y proponemos soluciones.

Hallazgos (Q&A)

1. Which type of XSS attack requires payloads to be persisted on the backend? -> stored

2. What's the reflected XSS flag? -> THM{Evil_Bunny}

3. What's the stored XSS flag? -> THM{XSS_4_Ever}

Remedición

Para corregir estas vulnerabilidades, recomendamos:

1. Sanitización de Entrada: Limpiar todos los datos recibidos de los usuarios, eliminando caracteres peligrosos.
2. Codificación de Salida (Output Encoding): Convertir caracteres especiales en sus equivalentes HTML (por ejemplo, < se convierte en <) antes de renderizarlos en el navegador.
3. Content Security Policy (CSP): Implementar cabeceras HTTP que restrinjan los orígenes desde los cuales se pueden cargar y ejecutar scripts.

Mañana publicaré el writeup del Día 12.

Si te perdiste la entrada del Día 9 sobre Cracking de contraseñas, puedes leer el Día 9: A Cracking Christmas aquí.

También puedes consultar todos los días del Advent of Cyber directamente en la colección completa del Advent of Cyber 2025.

¡Nos vemos mañana! 🎄

~ Xhetic