404-not-found
Reconocimiento y Enumeración Inicial
Iniciamos con un reconocimiento del host objetivo mediante un escaneo completo de puertos.
Dado que el host puede estar filtrando ICMP, utilizamos la opción -Pn:
nmap -Pn -vv -p- 172.17.0.2
El escaneo devuelve únicamente dos servicios abiertos:
22/tcp → SSH
80/tcp → HTTP
Como no contamos con usuarios válidos para probar autenticación en SSH, el foco pasa al servicio web.
Realizamos un escaneo más profundo sobre dichos puertos:
En el resultado del segundo escaneo muestra un nombre de dominio, lo que indica el uso de virtual hosting.
Para resolverlo correctamente, añadimos la entrada al archivo:
Tras esto, el sitio carga correctamente.
Análisis Web: Página Inicial y Pistas
La página de inicio muestra:
Una operación matemática
Una “clave secreta”
Un mensaje oculto como pista
La clave secreta tiene características típicas de Base64, por lo cual procedemos a decodificarla. El resultado es un mensaje que sugiere “mirar la URL”.
Esto apunta a la existencia de subdominios ocultos, muy común en retos web.
Y al parecer era un mensaje..
Descubrimiento de Subdominios
Lo que me llevó a buscar subdominios mediante fuzzing con wfuzz:
Las respuestas 301 y 400 son descartadas (--hc), pues habitualmente señalan subdominios inexistentes.
El fuzzing identifica un subdominio válido:
Lo añadimos nuevamente a /etc/hosts y al acceder aparece un panel de login.
Una vez recargada la pagina, me encontre con un pan de login, de moment no cuento con ningun "posible usuario", asique antes de probar ataque por fuerza bruta opte por revisar el codigo fuente
Análisis del Login: Indicio de LDAP
Dado que no disponemos de nombres de usuario para brute-force, analizamos el código fuente del login. En los últimos comentarios del HTML encontramos:
Este mensaje confirma que la autenticación se gestiona mediante LDAP, lo que abre la posibilidad de inyección.
La entrada del usuario es insertada directamente en una consulta LDAP sin sanitización. Probamos un payload clásico que fuerza la consulta a evaluar como verdadera:
El payload cierra la condición inicial e inserta un OR que coincide con cualquier usuario existente, generando un bypass total del sistema de autenticación.
Tras ejecutar la inyección, la página revela credenciales válidas.
Se pasar el panel de login y se logra ver lo que son una credenciales
Acceso Inicial al Sistema via SSH
Con las credenciales obtenidas del panel LDAP, intentamos autenticarnos mediante SSH, lo cual resulta exitoso.
A partir de aquí comenzamos la fase de post-explotación dentro del sistema como un usuario de bajo privilegio.
Escalada de Privilegios
Una vez dentro, toca buscar la forma de escalar privilegios
Solo puedo ejecutar un .py con el usuario 200-ok Intente leerlo no le encontre nada util y al ejecutarlo tampoco se ve nada que podamos aprovechar.
Toca ver si existe algun archivo txt que nos de algun otro mensaje
La nota dice "En la calculadora no sé para qué se usa el símbolo "!" seguido de algo más, sólo 200-ok lo sabe"
200-ok
Con el usuario 200-ok realice el intento de ejecutar con sudo -l pero pide contraseña asique lo descarto.
En el directorio de 200-ok encontré 2 archivos boss.txt y user.txt
Despues de un rato, sabiendo que nuestros a amigos de dockerlabs les gusta jugar con nuestras mentes, y no me decepciono, porque la contraseña del root? xD
Última actualización