Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: avanzada

Sobre este CTF

Scape Room la diseñé como un laboratorio orientado a una idea concreta: enseñar cómo una cadena de fallos aparentemente heterogénea puede mantener coherencia técnica cuando cada fase empuja a la siguiente. No me interesaba construir una máquina basada en obstáculos aislados ni en giros arbitrarios, sino en una progresión donde la enumeración, la lectura de pistas, el abuso de un servicio legítimo y una mala gestión de bibliotecas compartidas terminen formando una única historia técnica.

El nombre no es casual. Quise trasladar parte de la lógica de un escape room al diseño del reto: presión, necesidad de interpretar señales pequeñas y obligación de distinguir entre ruido y pista útil. Ese componente no busca dramatizar la experiencia, sino obligar a leer mejor la superficie de exposición. En entornos reales, muchas intrusiones no avanzan por una sola vulnerabilidad crítica, sino por una sucesión de decisiones pobres: información filtrada en una capa, credenciales mal expuestas en otra, automatismos inseguros y mecanismos de carga que terminan rompiendo el modelo de confianza del sistema.

El valor de esta máquina no está solo en llegar a root. Está en entender por qué cada fase existe, qué error representa y qué quise forzar como aprendizaje al construirla.

Información técnica

Descubrimiento de la máquina

La superficie inicial es reducida y reconocible: SSH, web y MySQL. Eso ya orienta el laboratorio hacia una cadena mixta entre exposición de aplicación y abuso de servicios internos.

sudo nmap -sSCV -p- -Pn -n --min-rate 5000 192.168.1.41

El resultado relevante fue:

• 22/tcp - OpenSSH 8.2p1
• 80/tcp - Apache/2.4.41
• 3306/tcp - MySQL 8.0.39

Desde el diseño, aquí quería evitar dos errores comunes en algunos CTF: esconder la máquina detrás de una enumeración interminable o inflarla con servicios irrelevantes. La exposición es mínima a propósito. El aprendizaje no está en encontrar veinte puertos, sino en interpretar bien tres.

Reconocimiento web y lectura de señales

La primera interacción útil aparece en HTTP. La página expuesta no entrega contenido funcional claro, pero sí introduce un detalle deliberado: un timestamp dinámico que añade sensación de actividad sin regalar contexto. A simple vista no resuelve nada, pero obliga a no asumir que una web sencilla es una web vacía.

whatweb --verbose http://192.168.1.41

El punto importante no era el fingerprinting del servidor, sino las cabeceras no habituales:

• X-Hint
• X-Contact

La pista de X-Hint conducía a un subdominio que había que resolver manualmente:

echo "192.168.1.41 info.sensores.thl" | sudo tee -a /etc/hosts

Al acceder a http://info.sensores.thl, el código fuente incluía un comentario en Base64:

<!-- QSB2ZWNlcywgbG8gbcOhcyBvYnZpbyBlcyBsbyBxdWUgc2UgcGFzYSBwb3IgYWx0by4gVHUgw7puaWNhIHNhbGlkYSBlcyB2ZXIgbG8gcXVlIG90cm9zIG5vIHZlbi4gRWwgdGllbXBvIGNvcnJlIHkgY2FkYSBwaXN0YSBlcyB1bmEgcGllemEgY2xhdmUgZGVsIHJvbXBlY2FiZXphcy4K -->

echo "QSB2ZWNlcy..." | base64 -d

La salida era una pista narrativa:

“A veces, lo más obvio es lo que se pasa por alto. Tu única salida es ver lo que otros no ven.”

Esta fase la construí para enseñar algo básico pero muy vigente: mucha información útil no aparece en la funcionalidad visible, sino en metadatos, comentarios, cabeceras o decisiones de despliegue que el equipo asume inofensivas. No es una vulnerabilidad espectacular. Es una filtración de contexto. Y en ataques reales, ese contexto vale mucho.

Metadatos como canal de fuga

En esa segunda superficie web aparecía una imagen con información embebida. La extracción de metadatos permitía recuperar una cadena codificada.

exiftool sensor_overview.png

Entre los metadatos destacaba un comentario con contenido Base64:

echo "YWN1dGU6SVM0..." | base64 -d

De ahí se obtenían credenciales válidas:

• Usuario: acute
• Contraseña: IS4yBvfwxpXUZsBxhCXr5muv3dXdQg!

Aquí la intención de diseño era clara: representar el error de tratar archivos auxiliares como si no formaran parte de la superficie de ataque. En muchos entornos, imágenes, documentos y artefactos de despliegue terminan transportando datos operativos, comentarios internos o secretos que nadie revisa porque no forman parte de la aplicación. Esa frontera es ficticia. Todo lo que se publica cuenta.

Acceso a MySQL y abuso de automatismos

Con esas credenciales, la siguiente fase permitía entrar en MySQL.

mysql -u acute -p -h 192.168.1.41

La enumeración de la base de datos llevaba a un evento programado deshabilitado. Activarlo alteraba el comportamiento esperado del sistema:

ALTER EVENT insert_login_data ENABLE;

A partir de ese momento, la tabla login generaba credenciales periódicamente. Después era posible recuperar la contraseña del usuario administrador desde la propia base de datos:

SELECT CONVERT(AES_DECRYPT(UNHEX(password), 'encryption_key') USING utf8)
AS decrypted_password FROM login WHERE usuario = 'administrador';

Esta parte no estaba pensada como un simple pivot para extraer datos. Quería enseñar dos ideas.

La primera: exponer un servicio como MySQL no siempre implica una explotación directa del motor; a veces basta con encontrar automatismos inseguros ya presentes en el diseño operativo. La segunda: los mecanismos programados, cuando se combinan con permisos excesivos o con claves accesibles desde el propio entorno, convierten la base de datos en un punto de control y no solo en un almacén.

Ese patrón sí tiene equivalente real. Tareas, eventos, jobs y procesos recurrentes suelen darse por confiables porque ya existen dentro de la operación. Pero si un atacante puede activarlos, reconfigurarlos o leer los materiales criptográficos relacionados, dejan de ser automatización y pasan a ser mecanismo de abuso.

Del acceso inicial a una pista útil

En el contexto obtenido aparecía un fichero cifrado llamado leeme.txt.gpg. La máquina no contaba con John the Ripper, así que la resolución obligaba a mover la muestra a un entorno propio para trabajarla con más comodidad.

Una forma sencilla de exfiltrarlo era levantar un servidor HTTP temporal:

python3 -m http.server

Y descargar el archivo desde el equipo atacante:

wget http://10.0.2.15:8000/leeme.txt.gpg

Después, el flujo habitual con gpg2john y john permitía recuperar la clave:

gpg2john leeme.txt.gpg > leeme_hash.txt
sudo john --wordlist=/usr/share/wordlists/rockyou.txt leeme_hash.txt

La contraseña encontrada era:

superman1

Con ella, ya era posible descifrar el archivo:

gpg --decrypt leeme.txt.gpg

El contenido no daba una instrucción literal, sino una pista técnica:

“No todas las funciones tienen el control que parecen tener. Algunas veces, quien controla lo que se carga primero tiene la ventaja. Recuerda: la pre-carga puede ser tu mejor aliada… o tu perdición.”

En esta fase me interesaba introducir una transición importante: pasar de la lógica de enumeración y recuperación de secretos a una lectura más cercana al comportamiento del sistema. No todo privilegio se gana explotando un binario SUID o una mala regla de sudoers. A veces se gana entendiendo cómo resuelve dependencias el sistema y quién controla ese proceso.

Preloading como frontera rota de confianza

La pista sobre pre-carga obligaba a mirar el comportamiento del enlazado dinámico. La comprobación de dependencias en /bin/ls dejaba ver una biblioteca inesperada:

ldd /bin/ls

La validación definitiva estaba en:

cat /etc/ld.so.preload

La salida mostraba:

/lib/libscaperoom.so

Ese era el corazón conceptual del laboratorio. Quise representar un fallo muy concreto: cuando el sistema introduce una biblioteca precargada en la ejecución de procesos, está ampliando de forma radical la superficie de confianza. Si esa biblioteca incorpora lógica sensible, credenciales embebidas o efectos laterales inseguros, el impacto deja de estar acotado a una aplicación concreta y contamina el comportamiento general del host.

No es un truco de CTF por sí mismo. Es una exageración pedagógica de un problema real: la dependencia excesiva de mecanismos globales de carga y la falsa sensación de seguridad que produce esconder lógica crítica en componentes compartidos.

Inspección de la biblioteca y escalada de privilegios

La inspección de la sección .rodata de la biblioteca exponía cadenas relevantes:

readelf -p .rodata /lib/libscaperoom.so

Entre ellas aparecían:

• referencia a read
• una contraseña: rT8hQ9VcYb5kLmXo
• el mensaje: [+] Acceso root concedido!

Con esa credencial, la transición a root era directa:

su
Password: rT8hQ9VcYb5kLmXo

Esta escalada no pretendía enseñar una primitiva exótica, sino una mala práctica de diseño: incrustar información sensible en un componente de bajo nivel que el sistema carga de forma global. Cuando una biblioteca participa en un mecanismo tan transversal como ld.so.preload, cualquier secreto o lógica de control que viva dentro de ella merece el mismo nivel de revisión que una pieza crítica del sistema. Si no se trata así, el problema no es la biblioteca: es el modelo de confianza completo.

Qué quería enseñar al diseñar Scape Room

Scape Room está construida para que la resolución no dependa de una vulnerabilidad aislada, sino de una lectura encadenada de errores pequeños y medianos que, juntos, rompen el sistema. La máquina no busca premiar fuerza bruta ni intuición arbitraria. Busca que el jugador entienda cómo se conectan filtración de contexto, secretos expuestos, automatismos inseguros y abuso de mecanismos globales de carga.

El aprendizaje reutilizable que quería dejar con esta máquina es sencillo: una intrusión madura rara vez depende de una bala de plata. Normalmente avanza porque varias capas del sistema comparten el mismo problema de fondo: decisiones de diseño tomadas sin pensar cómo se comportan cuando el adversario observa, correlaciona y reutiliza información entre contextos distintos.

Recursos y referencias

• Documentación de nmap
• Documentación de whatweb
• Manual de exiftool
• Documentación de MySQL sobre eventos programados
• Manual de ld.so y ld.so.preload
• Manual de readelf
• gpg2john y John the Ripper para extracción y crackeo de hashes GPG