Rebind: una cadena diseñada para enseñar cómo pequeños fallos terminan en compromiso total
Una cadena en dos fases donde el contexto de red manda, con esteganografía, una SQLi que se reconstruye a trozos y un debug que ejecuta como root.
Avanzado · Linux
URL del reto: labs.thehackerslabs.com/machines/74
Por qué la diseñé
Rebind es una cadena en dos fases, no una máquina aislada ni una colección de trucos sueltos. Quería obligar a leer el contexto completo, primero entender cómo una pista aparentemente decorativa en el primer servidor termina siendo la llave, y después usar ese acceso para desbloquear un segundo sistema que, en condiciones normales, no expone nada útil.
El valor está en entender por qué cada fase existe, más que en llegar al final. Quise dejar claro que muchos compromisos nacen de varias decisiones pequeñas que, combinadas, abren una ruta entera hasta root, y no de una única vulnerabilidad crítica.
La máquina de un vistazo
Son dos servidores encadenados. El primero expone una web con una pista escondida en la imagen de fondo, una inyección SQL y un acceso SSH con truco. El segundo no abre superficie hasta que el primero se resuelve, y cuando lo hace aparece un servicio con un endpoint de depuración que ejecuta como root. Entre medias, el acceso depende de estar en la red correcta.
Cómo la monté, paso a paso
Un segundo servidor que no abre hasta resolver el primero
Rebind arranca en apariencia por servidor2, pero ese host no expone puertos útiles hasta que se resuelve antes servidor1. Ese bloqueo está puesto a propósito, para que se vea que no todo servicio tiene que ser atacable de inmediato, y que a veces la exposición depende de acciones previas, autenticaciones o cambios de estado. La enumeración útil empieza en servidor1.
La pista escondida en la imagen de fondo
La web de servidor1 parece pobre, y ahí está la trampa. En el CSS, la imagen de fondo lleva datos ocultos con steghide, y la contraseña para sacarlos es esa referencia a thehackerslabs.com que en la página parece pura decoración. Dentro aparece el nombre de un vhost, thl.rebind. Quería enseñar que el frontend es superficie de ataque, que no solo el HTML sino los recursos estáticos, los nombres de fichero y las imágenes pueden llevar información útil. Cuando una app parece demasiado pobre para el escenario, casi siempre hay que revisar lo accesorio en lugar de insistir contra el mismo endpoint.
La SQLi que entrega la contraseña a trozos
El vhost lleva a una funcionalidad con una inyección SQL. No quería que la SQLi fuera un fin en sí misma, así que lo que se extrae son cuatro fragmentos en Base64 que hay que reconstruir. Y hay una trampa, uno de los bloques trae un carácter corrupto que rompe el patrón alfabético y numérico. Ajustando esa anomalía sale la contraseña buena. En una intrusión el problema muchas veces está en reconocer cuál de los datos extraídos es el operativo y cuál trae ruido o está manipulado, más que en exfiltrar el dato.
El acceso condicionado por la red
Con la contraseña reconstruida se entra por SSH y el sistema entrega las credenciales de servidor2 junto a una pista de red. Y aquí viene la otra vuelta, tener credenciales válidas no basta si no se llega desde la dirección correcta. Ajustando la interfaz del atacante a la IP que pedía la pista, el segundo servidor cambia de comportamiento. Quería enseñar que disponer de credenciales no siempre equivale a acceso útil, que el contexto de red manda, y que hay servicios que solo aparecen tras una autenticación, un disparador o una condición operativa.
El servicio que solo aparece tras el disparador
Cuando servidor2 reacciona, expone un servicio en el puerto 5000 con una interfaz web. Le puse una defensa a base de lista negra, si ciertas palabras (os, eval, subprocess, sudo...) se repetían cuatro veces, el servicio se apagaba. Esa defensa está ahí para representar un error muy común, confiar en bloqueos por palabras prohibidas en vez de quitar de verdad la capacidad peligrosa. Una lista negra sobre un mecanismo de ejecución mal aislado aguanta poco.
El endpoint /debug que ejecuta como root
Durante la enumeración de ese servicio aparece un /debug que no acepta GET, señal de que espera otro método. Esperaba un POST con JSON, y enviando {"code": "..."} con un comando dentro se obtiene ejecución. La conexión vuelve con contexto de root, así que ahí se cierra toda la cadena sin una escalada aparte. Esa era la lección, muchas brechas llegan por herramientas internas, paneles de test o modos debug que terminan accesibles desde donde no deberían, no por una vulnerabilidad sofisticada. El privilegio ya venía implícito en el servicio.
Qué quería enseñar
Rebind es una cadena coherente donde cada paso tiene sentido por sí mismo y como preparación del siguiente. Una pista en una imagen, una inyección que devuelve datos parciales, una credencial condicionada por la red y un endpoint de depuración aparentemente menor terminan formando una ruta completa hasta root.
| Fase | Qué enseña | Error que representa |
|---|---|---|
| Web inicial y stego | La superficie visible rara vez es toda la superficie | Recursos estáticos publicados sin revisar |
| SQLi a trozos | Sacar los datos es solo el paso intermedio | Entrada vulnerable y protección insuficiente |
| Reconstrucción de la clave | El análisis lógico acompaña a la técnica | Secretos fragmentados o contaminados |
| Acceso a servidor2 | Las credenciales dependen del contexto de red | Segmentación y servicios condicionados |
| Servicio en 5000 | Un filtro de lista negra aguanta poco | Bloqueos por palabras sobre ejecución mal aislada |
| Endpoint /debug | Una función de depuración puede ser RCE directa | Debug inseguro accesible desde fuera |
Un compromiso serio puede salir de piezas que por separado parecen menores. Rebind las encadena a propósito, para que se vea cómo una tras otra abren la ruta entera hasta root.