JarJar
Difficulty: Medium
La IP de la máquina JarJar es la 106:
Recon
Empezaremos realizando un escaneo completo de nmap sobre el objetivo:
Puertos identificados:
22/tcp → Servicio SSH
80/tcp → Servicio web
Accederemos a través del navegador web a la IP:
Accederemos a una página web que aparentemente muestra un texto animado a lo Star Wars.
Inspeccionamos el código en busca de rutas o archivos que puedan ser interesantes para seguir profundizando en la máquina:
Localizamos en el texto de la página el dominio jarjar.nyx.
Vamos a añadir el dominio a nuestro archivo /etc/hosts:
Al acceder al dominio nos lleva a una nueva web.
En los links de la barra superior de la página, hay un Admin Panel. Clicaremos para acceder:
Nos llevará a login.php.
Inspeccionamos el código, pero no sacamos nada relevante.
Vamos a interceptar la request con Burp a ver si podemos ver algo en la respuesta del server:
Enviamos la request al Repeater para trabajar con ella.
Authentication Bypass
Al hacer click en Admin Panel, nos ha llevado a login.php. Desde la request en el Repeater vamos a probar si hay un admin.php y nos han redirigido. Cambiaremos el GET /login.php por GET /admin.php:
Conseguimos que nos responda el servidor con el contenido de admin.php, aquí hay varios puntos que analizar:
Función de logout: Vemos una función de cerrar sesión que te envía a la página login.php. Seguramente, en el back-end hay una función para redirigir a los usuarios a login.php en el caso de que no estén logueados, ya que Admin Panel en la página principal está apuntando a admin.php:
Se pueden identificar rutas a los siguientes archivos:
secure_files_admin/docs.php
secure_files_admin/files.php?logs=error.log
secure_files_admin/users.php
Estas rutas tienen en común que el directorio secure_files_admin, y hay uno de ellos que puede resultar muy interesante: users.php
Volvemos a modificar la request en el Repeater, esta vez para intentar mostrar el archivo secure_files_admin/users.php:
El servidor nos responde con un 200 OK, por lo que hemos podido acceder sin ningún problema.
Analizaremos la respuesta del servidor:
Por la estructura y campos que se muestran, es un panel en el que se permiten crear y gestionar usuarios.
Accedemos desde el navegador a la ruta secure_files_admin/users.php:
Confirmamos que no hay ningún tipo de restricción para acceder a esta ruta.
LFI
Ahora que tenemos acceso al panel del admin, vamos a intentar buscar como podríamos avanzar. Cuando hemos hecho la request con Burp, una de las rutas era la de los logs y parecía que cargaba un archivo a través de un parámetro, vamos a probar si podemos cargar otro archivo en ese parámetro:
Está cargando el archivo error.log a través de un parámetro de URL.
Intentaremos cargar un archivo de sistema a través del parámetro, manipulando la ruta:
Parece que no le ha gustado...no será tan simple, tendremos que combinar otras técnicas, cómo hacer un path traversal.
Parece que la web tiene sanitizado o filtrado de alguna forma, cuando el parámetro intenta salirse del path definido. Cómo el archivo anterior es un .log, damos por hecho que estamos en el directorio logs y es lo que tiene definido la función que nos ha dado el error "Illegal path specified!". Vamos a intentar jugar con diferentes payloads:
No hemos llegado al archivo /etc/passwd, pero ya no nos sale el mensaje de aviso. Esto quiere decir que definiendo la ruta desde el directorio logs, podemos hacer uso de estos payloads. Ahora sólo nos queda encontrar la ruta correcta.
A base de probar, añadiendo saltos hacía atrás en los directorios, encontramos la ruta y se muestra el archivo /etc/passwd:
Usuarios encontrados:
jarjar
obiwan
quigon
El otro servicio en ejecución en la máquina es SSH, por lo que alguno de estos 3 usuarios, tiene que tener clave RSA para realizar la conexión. Haremos un curl de cada uno de ellos, sobre la carpeta donde debería estar su clave RSA:
Les concedemos permisos:
Cómo la máquina va de jarjar, utilizaremos la clave de este usuario para realizar la conexión ssh:
Me estaba dando el error que se muestra en la captura anterior y no sabía porque hasta que revisé el contenido de id_jarjar:
Limpiamos el contenido HTML del archivo y dejamos únicamente la key con un salto de línea al final:
Volvemos a ejecutar el comando de ssh:
Ya estamos dentro de la máquina con el usuario jarjar, vamos a probar si hay algo que podamos ejecutar como root:
Privilege Escalation
Hay que escalar privilegios ya que el usuario jarjar no es root. Para ello buscamos por binarios SUID, este tipo de archivos ejecutables se ejecutan con los privilegios de su propietario, en lugar de los del usuario que los ejecuta, si su propietario es el root, pues nos permitirán escalar privilegios:
El archivo /usr/bin/ab es el que nos interesaría.
Listado de binarios para bypassear restricciones de seguridad: https://gtfobins.github.io/
Vemos como funciona y primero tendremos que poner una consola netcat a la escucha:
Enviamos el archivo a nuestra máquina atacante:
Recibimos el archivo con los hashes de los usuarios.
Nos guardamos el hash del root en un archivo txt, limpiándolo de todo lo innecesario, para poder crackearlo:
Ejecutamos John The Ripper para crackear el hash, en este caso, al ser un hash de /etc/passwd hay que especificar el formato crypt:
Conseguimos crackear la contraseña.
Iniciamos sesión por ssh con el usuario root y la contraseña que acabamos de crackear:
No sé porque, pero no me aceptaba la contraseña por ssh. Miré otros writeups para salir de dudas porque no sabía en que me estaba equivocando, pero es la misma que estaba saliéndome después de crackear el hash.
Pero a problemas, soluciones. Como por ssh no me quería aceptar la contraseña, me conecté a la máquina jarjar directamente, entonces si me aceptó la contraseña crackeada y saqué la flag de root:
La flag del user la saqué en cuanto me conecté con el usuario jarjar por ssh:
Última actualización