JarJar
Last updated
Last updated
Muy buenas y bienvenidos a la resolución de la máquina JarJar de VulNyx, esta es otra de las máquinas que hago para la plataforma de VulNyx, en este caso es el inicio de una saga de máquinas basadas de la tan conocida saga de Star Wars, espero que os guste y empecemos ya con la resolución.
A continuación veremos las técnicas que nos encontraremos, vamos a poner todas las que hay, como si fuera un pentest:
Username Enumeration a través del login.php
Authentication Bypass via Direct Access
Local File Inclusion - Approved Path (EAR)
PrivEsc - /usr/bin/ab SUID
La propia máquina nos da la IP de la máquina que es la 192.168.93.130 en mi caso, se podría encontrar con arp-scan -I <tu interfaz> --localnet o con nmap -sn <tu red/24>
Una vez tenemos la IP de la máquina JarJar, hacemos un escaneo para ver que puertos abiertos hay:
De primera aparece una intro rechulona de Star Wars que me costo lo suyo encontrar una plantilla que quedase bien así que estoy muy orgulloso jeje. Si nos fijamos al final aparece lo que pareced un virtual hosting, lo añadimos al /etc/hostspara ver si la página al entrar, es diferente.
Al entrar a la página se ve una totalmente diferente:
Como todos sabéis Jar Jar Binks era un sith, vale? Hay una conspiración por ahí con muchas teorias que yo apoyo, porque sino que gracia tiene sino? Bueno... paro ya de desviarme del tema, vamos con la máquina.
Cuando inspeccionamos la página, pues es la típica normal con lore de la saga y poco más, revisamos bien las cabeceras de la página por si nos filtra algo:
Nos ponemos con las DevTools > Network y recargamos la página por si saca algun archivo que no tiene que cargar:
Otro check sería revisar bien el código en busca de archivos JavaScript o comentarios, pero la máquina no va por ahí. El path va por el Admin Panel y su funcionalidad que explicaremos más a delante.
Si le damos nos redirige a una web para hacer login, suponemos que para acceder al admin panel tenemos que estar logueados.
Aquí es donde viene el User Enumeration, anteriormente en la parte de Character, habían 3 usuarios:
JarJar
Obiwan
Quigon
Los probamos a ver si existen en el sistema o no, o si pones uno que no existe, cambia el mensaje de error, eso es una manera de enumerar si el usuario existe o no, también otra manera es ver el resultado que te devuelve en Length.
Cuando ponemos admin, nos aparece que Invalid Username or Password, esto nos demuestra que podemos enumerar usuarios.
Utilizando el mensaje de error diferente para cuando existe, y para cuando no, se podría utilizar para un ataque de fuerza bruta, pero en este caso no aplica ya que no es el path.
De acuerdo, cuando hay un redirect nosotros como pentesters tenemos que hacer SIEMPRE una comprobación de como se está gestioando la petición, porque a veces puede pasar que se ha configurado mal la petición y podemos abusar de ella si la analizamos de manera correcta, como justamente pasa en esta máquina, por detrás se ha cometido un en el código fuente el cual nos permitirá entrar al admin panel sin otorgar contraseña, vamos a ello.
Le damos a admin panel e Interceptamos la petición para ver como se gestiona.
A primera vista no vemos nada raro:
De acuerdo, pues para inspeccionar los redirects tenemos una manera de saber como se gestiona y si este se ha configurado correctamente, le damos a Do Intercept > Response to this request, lo que haremos aquí es interceptar la respuesta del redirect, le damos a Forward.
Como vemos en la imagen de abajo, tenemos acceso al código fuente de la página admin.php:
Podemos incluso ver directorios que no teníamos acceso antes (si hubiéramos hecho fuzzing tampoco lo hubiéramos encontrado), esta es una manera de entrar, coges el nuevo directorio y lo pones directamente en la URL -> http://jarjar.nyx/login.php/secure_files_admin/users.php.
Pero la manera correcta de hacerlo y que siempre funcionará, es cambiar el estado del redirect que es 302 a un 200, así cuando enviemos la respuesta en vez de hacer el redirect, será un 200 y tendremos acceso directo, esta es la manera correcta de entrar, porque a lo mejor no hay esos directorios siempre expuestos en el código fuente, pero lo que siempre funcionará será cambiar el estado del código.
Cambiamos de 301 a 200:
Le damos a Forward:
Y boom, tenemos acceso al admin panel:
Muchos os preguntaréis... ¿Qué acaba de pasar y porque esto ha funcionado? Vamos a entenderlo de una manera muy simple.
Para un redirect, normalmente se utiliza la cabecera Location: entonces, por detrás la aplicación web redirige a los usuarios que entren al /admin.php si están autenticados, al no estarlo y no tener una sesión activa, nos redirge al /login.php para autenticarnos con un usuario válido.
Cómo se vería en PHP? Aquí te muestro:
Al hacer la petición al admin.php tiene este pedacito de código, la cosa es que ese código es vulnerable a lo que acabamos de explotar, y dirás... por qué?
El script PHP de arriba no detiene la ejecución, lo que provoca que la información protegida de la página se envíe en el cuerpo de la respuesta como vimos anteriormente, permitiéndonos ver el contenido entero de la página en el cuerpo de la respuesta.
Pero si accedemos directamente desde el navegador sigue el redirect y nos lleva al login.php , por eso mismo enseñe arriba el como bypassearlo, cambiándole el código de 302 a 200.
Para evitar que la información protegida sea devuelta en el cuerpo de la respuesta de la redirección, el script PHP necesita salir después de emitir la redirección:
En el script vulnerable, en ningún momento se acaba el redirect y se queda en bucle, por eso podemos ver la información, simplemente con un exit; terminamos la petición y nunca pasaría esta vulnerabilidad.
Cuando accedemos al panel de administración de la web, en la parte de Logs, encontramos arriba un parámetro que se pone automáticamente:
Si no tuviéramos el parámetro, podríamos haber hecho un fuzzing con ffuf o wfuzz, pero este no es el caso.
Parece que está mostrando un archivo .log que debe estar alojado en alguna carpeta del servidor, si el parámetro se llamada logs, vamos a suponer que la carpeta es /logs.
Cuando ponemos un payload básico de LFI nos muestra el siguiente mensaje:
La web app revisa que cuando ponemos un input en el parámetro hay un path especifico que tiene puesto el servidor, siempre que veáis que restringe de esta manera, tenéis que pensar instantáneamente en la técnica Approved Path, muchas web apps utilizan esta técnica para evitar que se haya LFI + Path Traversal, obligan que pongas el path especifico para que te muestre el archivo indicado, pero que pasa... si ha sido mal gestionado y hay una sanitización un poco escasa?
Vamos a probar, con establecer al principio del input ./logs y después el Path traversal:
Parece que hemos bypasseado la regex que debe haber por detrás que valida si hay el /logs o no, ahora solo nos queda tirar para atrás los directorios para ir a la raíz / del sistema:
Y lo hemos bypasseado con éxito!
Pues teniamos 3 usuarios enumerados anteriormente junto con el User Enumeration, vamos a ver si existen también en el sistema o solo son usuarios del web server:
Buscamos por la id_rsa de JarJar que es el usuario que parece más indicado, por el nombre de la máquina.
Y obtenemos la id_rsa del usuario JarJar, ahora la copiamos a un archivo id_rsa y le ponemos los permisos indicados chmod 600 id_rsa y entramos con ssh.
Y entramos!
Cuando buscamos por permisos sudo, no está instalado, cuando buscamos por binarios SUID encontramos un binario llamado /usr/bin/ab:
Este está en gtfobins para explotar, así que fácil de escalar a root, quise poner una escalada más complicada... pero viendo atrás con las vulnerabilidades que tocan que no son tan "comunes" pense que sería mejor hacer una escalada muy fácil, aunque pienso que el ab está chula de explotar, por eso mismo la puse.
Viendo el como funciona, simplemente tenemos que crear un listener con netcat y enviarnos un archivo del sistema de la máquina, la vía es el /etc/shadow, este contendrá el hash de root y le haremos fuerza bruta con john.
Primero abrimos el listener:
Seguidamente nos enviamos el archivo:
Lo recibimos
Cogemos el hash de root y le quitamos todo lo innecesario:
Si lo hacemos sin especificar el tipo de hash que estamos intentando crackear saldrá así:
Cuando hagamos fuerza bruta a un hash del sistema como en el /etc/shadow es necesario especificar el formato, en este caso es crypt
Y conseguimos el root:
Espero que os haya gustado y hayáis aprendido que era mi objetivo, en un tiempo sacaré la 2nda máquina basada en la saga Star Wars.
Tenemos el típico puerto 22 y 80, que seguramente significa que será hacking web... siendo el creador de la máquina, os lo confirmo . Pues nos vamos directamente a la web, a ver que aparece:
Lo añadimos: (como podéis ver tengo varios virtual hosting, le estoy dando caña a HackTheBox )
Chao
