Shadow Gate: señales ocultas, activación remota y una consola local ejecutándose como root
Cómo una serie de decisiones aparentemente inconexas termina abriendo una cadena completa de acceso, activación y escalada.
Avanzado · Linux
URL del reto: labs.thehackerslabs.com/machines/97
Por qué la diseñé
Shadow Gate es una cadena menos evidente que otras, montada sobre errores que se ven fuera del laboratorio, servicios opacos expuestos, pistas repartidas entre protocolos distintos, una lógica de validación mal conectada y una superficie local privilegiada que nunca debió existir. La monté para que la clave estuviera en correlacionar señales entre capas más que en la fuerza bruta.
El fallo está repartido entre varias piezas, un servicio que responde con ruido cifrado, un login web con cabeceras de más, una verificación escondida que activa algo y, al final, una consola interna ejecutando Python como root. Ninguna es crítica por sí sola. Cada una cobra sentido cuando se lee junto a la siguiente.
La máquina de un vistazo
Expone SSH, una web en el puerto 8080 servida por Werkzeug y un servicio propio en el 56789 que Nmap no sabe identificar. La cadena arranca en ese servicio opaco, que suelta un usuario si se le habla bien, pasa por un login web que filtra un token MFA en una cabecera, sigue por un endpoint de verificación que en realidad activa un backend y termina en una consola local que ejecuta como root.
Cómo la monté, paso a paso
El servicio opaco que responde a una palabra
En el puerto 56789 puse un servicio que Nmap no identifica y que recibe con un banner lleno de pistas, entre ellas la palabra n0cturne. Al enviársela, suelta una tanda de bloques cifrados. El primero es una clave base fija y el resto va en AES sin IV, o sea ECB, de modo que la primera letra de cada bloque descifrado, la única posición estable entre conexiones, compone un nombre de usuario. Quería enseñar que no toda pista sirve donde se obtiene, que un servicio puede entregar solo una credencial parcial que cobra sentido en otra capa. El error de fondo es repartir secretos operativos entre servicios que deberían estar aislados.
El login web que filtra el MFA por cabecera
Ese usuario se prueba en el /login de la web del 8080. La respuesta trae la información de lado, en las cabeceras, no en el cuerpo. Con un usuario válido, la aplicación devuelve un X-Shadow-MFA con un token, y además deja claro por la respuesta cuándo un usuario existe y cuándo no. Son dos errores en uno, exponer un flujo de MFA por cabecera y confirmar qué usuarios son válidos. Quería representar lo fácil que se filtra un paso de autenticación cuando se implementa sin cuidado.
El endpoint que no valida, activa
La gracia está en dónde se usa ese token. Escondí un endpoint, /verify, que acepta el usuario y el token, y en lugar de limitarse a validar un acceso, enciende un servicio adicional del sistema. Eso es bastante más grave que un MFA mal hecho, porque un flujo web termina cambiando el estado del backend. Al volver al servicio del 56789, ahora responde con unas credenciales de SSH en claro, y con ellas se entra al host.
La consola local que ejecuta como root
Ya dentro como usuario normal, dejé un helper escuchando solo en loopback, en 127.0.0.1:4444. Es una consola de Python sin restricciones que corre como root, así que un os.system desde ahí ejecuta lo que sea con privilegios totales, y de ahí a root es directo. Este es el fallo que más se minusvalora, el servicio privilegiado que se da por seguro porque solo escucha en localhost. En cuanto alguien entra al sistema como usuario normal, ese helper se convierte en un camino directo a control total.
Qué quería enseñar
Shadow Gate gira alrededor de la relación entre varios fallos de diseño que, juntos, abren la puerta, más que alrededor de una única vulnerabilidad.
| Fase | Qué enseña | Error que representa |
|---|---|---|
| Puerto 56789 con pistas cifradas | La lógica sensible no debería vivir expuesta | Servicios internos convertidos en acertijos inseguros |
| Usuario reutilizado en la web | Las capas se correlacionan | Secretos operativos compartidos entre servicios |
| Token MFA en cabecera | Un paso de validación se filtra fácil | MFA implementado sin cuidado |
| Endpoint /verify | Un flujo web no debería activar backends | Lógica de negocio mal conectada |
| Credenciales SSH tras la activación | Los backends auxiliares filtran secretos | Información crítica en claro |
| Helper en 127.0.0.1:4444 | Escuchar en loopback no lo hace seguro | Servicio privilegiado sin aislamiento |
Lo que importa es ver cómo una serie de decisiones aparentemente inconexas termina formando una cadena completa de acceso, activación y escalada. Llegar a root es solo el final.