Máquina Linux nivel medio. Fuzzeo al máximo, fuerza bruta al máximo y claro, lectura de archivos en el sistema al máximo.

TL;DR (Spanish writeup)

Creada por: ch4rm.

Atacarse a la fuerza, bruta.

Pelearemos un rato con virtual-hosting y fuzzing para tener acceso al servicio FileBrowser, realizaremos ataques de fuerza bruta contra el servicio, logrando así la adivinación de unas credenciales (:

Ya dentro jugaremos con una vulnerabilidad que le permite a un usuario administrador, crear usuarios (también administradores) que cuenten con permisos para acceder a cualquier directorio del sistema, tanto para lectura como para modificación de este.

Apoyados en esta vuln, tendremos control total sobre los archivos del sistema ¿Qué modificarías para obtener una Shell como root? 🔥

…

La idea inicial de esta locura es tener mis “notas” por si algun día se me olvida todo (lo que es muuuy probable), leer esto y reencontrarme (o talvez no) 😄 La segunda idea surgio con el tiempo, ya que me di cuenta que esta es una puerta para personitas que como yo al inicio (o simplemente a veces) nos estancamos en este mundo de la seguridad, por lo que si tengo la oportunidad de ayudarlos ¿por qué no hacerlo?

Un detalle es que si ves mucho texto, es por que me gusta mostrar tanto errores como exitos y tambien plasmar todo desde una perspectiva más de enseñanza que de solo pasos a seguir. Sin menos, muchas gracias <3

…

Más o menos bien.

1. Reconocimiento.
2. Enumeración.
3. Explotación.
   • FileBrowser Directory Traversal/RCE.
4. Escalada de privilegios.
5. Post-Explotación.

…

Reconocimiento #

Necesitamos inicialmente conocer la IP de la máquina a atacar. En la construcción del lab, la máquina fue asignada al segmento 172.144.3.0/24, por lo que dentro de ese rango debe estar nuestro objetivo, usaremos arp-scan para -escanear- la red y validar que host encuentra:

❯ arp-scan -l
Interface: eth0, type: EN10MB, MAC: 08:00:27:a8:aa:31, IPv4: 172.144.3.7
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
172.144.3.1     52:54:00:12:35:00       QEMU
172.144.3.2     52:54:00:12:35:00       QEMU
172.144.3.3     08:00:27:09:ba:02       PCS Systemtechnik GmbH
172.144.3.10    08:00:27:19:3f:b7       PCS Systemtechnik GmbH

Bien, la distinta y nueva claramente es la .10, nos quedamos con ella por el momento.

Jugamos con nmap para ver puertos (servicios) expuestos del host:

nmap -p- --open -v 172.144.3.10 -oA TCP_initScan_Narcos

Del escaneo extraemos los siguientes servicios:

_____(Usando la función extractPorts (referenciada antes) podemos copiar rápidamente los puertos en la clipboard, en este caso no es necesario (ya que tenemos pocos puertos), pero si tuviéramos varios puertos evitamos tener que escribirlos uno a uno

 extractPorts TCP_initScan_Narcos.gnmap
[*] Extracting information...

    [*] IP Address: 172.144.3.10
    [*] Open ports: 22,80

[*] Ports copied to clipboard

)_____

Y ahora, con los puertos copiados, usamos de nuevo nmap para probar mediante scripts (propios de la herramienta) algunas vulns conocidas, así mismo le pedimos que nos intente extraer la versión del software usado en el servicio:

nmap -sCV -p 22,80 172.144.3.10 -oA TCP_portScan_Narcos

Finalmente encontramos:

Pero nada muy profundo, así que metámonos de cabeza contra el laboratorio.

Enumeración #

Recorriendo el servidor web 📌

La web es una simple tienda, de la que no obtenemos mucho, simplemente un apellido interesante Escobar (Pablo Escobar, si lo relacionamos con el nombre de la máquina), lo guardamos por sí algo.

Realizando un descubrimiento de objetos alojados en el servidor (fuzzing), encontramos un directorio interesante:

ffuf -c -w /opt/seclists/Discovery/Web-Content/common.txt -u http://172.144.3.10/FUZZ

Si nos dirigimos a ese recurso, nos encontramos con Squirrelmail, un servicio web para gestionar correos.

Recorriendo el servicio web Squirrelmail 📌

De primeritas vemos una versión: SquirrelMail 1.4.23 [SVN]. Para ella descubrimos algunas vulnerabilidades, pero ninguna funcional (o no por el momento):

• Squirrelmail 1.4.x - ‘Redirect.php’ Local File Inclusion.
• SquirrelMail <= 1.4.23 Remote Code Execution.

En este punto estuve jugando con bruteforce buscando archivos, buscando posibles credenciales contra el login, esto mediante wordlists por default, así creándolas con el nombre Pablo Escobar (por el apellido que vimos en “la tienda”) y sus posibles “usernames” (pescobar, p.escobar, pablo.escobar…, creadas con username-anarchy y otras herramientas), otros nombres de narcos, pero nada, nada de nada.

Te dejo un comando pa que juegues con bruteforce, así si no lo tienes, te lo guardas en tu arsenal.

hydra -L pablo_escobar_usernames.txt -P /usr/share/wordlists/rockyou.txt 172.144.3.10 http-post-form "/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^&js_autodetect_results=1&just_logged_in=1:F=Unknown user or password incorrect." -V -F -u

Entre pruebas y demás cosas (acordémonos que es un CTF), noté un dominio al iniciar la máquina Narcos con el virtualizador:

Personalmente no me gustó, creo que el creador lo hubiera podido haber puesto simplemente como parte del footer o haber realizado una redirección y listo, quedaba más relacionado con el laboratorio, pero no pasa nada :P

Claro, habíamos visto el apellido Escobar en su tienda, pero no era lógico llegar a esa prueba de dominio, lo más obvio hubiera sido narcos.hmv.

Bueno, agregamos ese dominio al archivo /etc/hosts, en una validación iniciar contra el contenido de los dos recursos que ya tenemos (la tienda y el de correos) notamos que no hay cambios, así que procedemos a validar posibles subdominios dentro de ese dominio (virtual hosting):

ffuf -c -w /opt/seclists/Discovery/DNS/subdomains-top1million-110000.txt -u http://172.144.3.10/ -H 'Host: FUZZ.escobar.hmv' -fs 11550

Hay una cadena de texto que concatenada al dominio nos responde con un contenido distinto al alojado dentro de escobar.hmv, si lo validamos llegamos a un nuevo servicio:

FileBrowser es algo muy chevere, basicamente es una interfaz web que nos permite, ojito, interactuar con archivos y directorios de un servidor, moverlos, copiarlos, leerlos, borrarlos, en fin, basicamente ejecutar los comandos mv, cp, cat, rm, pero todo graficamente. Brutal brutal, linda herramienta.

Siguiendo con la exploración, en el código fuente vemos la versión con la que contamos de esta belleza:

Probando credenciales por default e inyecciones random no vemos nada distinto y con respecto a vulnerabilidades tenemos una llamativa, pero necesitamos estar autenticados (igual que con Squirrelmail, lo que me da a entender (y después de explorar mucho tiempo varias cosas) que si o sí, debemos enfocarnos en el bruteforce de las dos aplicaciones):

• Filebrowser < 2.18.0 - Cross-Site Request Forgery to RCE (and Directory Traversal).

Explotación #

Bruteforceando el login tanto de Squirrelmail como el de FileBrowser hemos podido encontrar credenciales válidas en FileBrowser, el proceso fue el siguiente:

Abrimos BurpSuite, colocamos credenciales en el login de FileBrowser e interceptamos:

Guardamos esa petición en un archivo de nuestro sistema y acá viene lo interesante, modificamos el valor de username por USER (o lo que quieras, pero tenlo presente) y el valor de password por PASS:

POST /api/login HTTP/1.1
Host: management.escobar.hmv
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: */*
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: http://management.escobar.hmv/login?redirect=%2Ffiles%2F
Content-Type: application/json
Content-Length: 55
Origin: http://management.escobar.hmv
Connection: close

{"username":"USER","password":"PASS","recaptcha":""}

¿Y pa qué? Acá entra en juego ffuf, ya que haremos que tome el contenido del archivo, lo procese e interprete que queremos hacer fuzzing sobre esos dos campos.

Esto es útil cuando contamos con cookies largas, con variables o simplemente para cuando queremos hacer el proceso más didáctico…

Como usuarios a probar (pablo_escobar_usernames.txt), le pasaremos una lista con valores por default y otros que creamos con username-anarchy:

admin
demo
administrator
administrador
test
pablo
pabloescobar
pablo.escobar
pabloesc
pablesco
pabloe
p.escobar
pescobar
epablo
e.pablo
escobarp
escobar
escobar.p
escobar.pablo
pe

Y como contraseñas las que están en el objeto rey: rockyou.txt.

ffuf -c -w pablo_escobar_usernames.txt:USER -w /usr/share/wordlists/rockyou.txt:PASS -request-proto http -request post_management_api_login.txt -x http://127.0.0.1:8080 -fs 14

• Con -w le indicamos el wordlist, solo que como estamos fuzzeando dos parámetros, pasamos dos -w y al final de cada uno, indicamos cuál será su “id”, por un lado, USER y por otro PASS.
• Con -request-proto le indicamos que la petición viaja por HTTP, no por HTTPS.
• Usando -request le pasamos el archivo donde está el raw de la petición.
• (opcional) -x lo usamos para pasarle un proxy, esto es más para validar si la petición viaja bien.

Ejecutamos y después de un rato:

EJELEEEEEEE! Tenemos credenciales al parecer válidas. Si las probamos…

Tamos dentrooooooooooo (:

Revisando los archivos y las cositas a las que tenemos acceso, encontramos uno llamado logins.xlsx:

El cual al descargar, te darás cuenta de que está protegido por contraseña, pero desde ya te digo, después de todo el proceso de crackeo y juego con las creds que hay dentro, no llegué a ningún lado (o quizas no supe llegar).

Así que para hacer la resolución de la máquina más directa, vamos a saltarnos ese paso, peeeero, aun así pondré ese proceso en la post-explotación.

FileBrowser - Directory Traversal / RCE 📌

Si recuerdas, antes encontramos una vuln para FileBrowser que involucraba un Directory Traversal que puede convertirse en ejecución remota de comandos:

• Filebrowser < 2.18.0 - Cross-Site Request Forgery to RCE (and Directory Traversal).

La vuln es bien locochona, mediante el usuario administrador del sitio, podemos crear más usuarios, incluso más admins, la cosa es que en la creación podemos darle permiso de acceso hacia cualquier directorio que ese usuario quiera. Ya huele feito…

El problema está en una validación que NO hace el endpoint /api/users, ya que válida cositas cuando la cabecera HTTP Content-Type es igual a “application/json”, pero también recibe “plain/text”, ahí, justo ahí, es cuando se genera el bypass y se activa la vulnerabilidad.

La vuelta es cuando como atacantes, creamos un usuario admin con acceso a por ejemplo el directorio /root o incluso a tooodo el sistema con la ruta /, una vez el usuario (el atacante) se logee en esa nueva cuenta, debería ver el contenido al cual tiene acceso 💥

Brutaaal, veamos si la logramos explotar…

…

Empezamos creando el usuario, vamos a la configuración y añadimos uno nuevo:

Antes de, nos preparamos para interceptar la siguiente petición con BurpSuite:

• En scope aprovechamos un Directory Traversal para salirnos del directorio permitido e indicarle (en este ejemplo) que el usuario pwned tenga acceso a TODA la raíz del sistema (/).

Enviamos y al ver la petición cruda con BurpSuite encontramos el objeto commands, ese es el usado para llegar al RCE del que habla la vuln, agregamos un comando para ejecutar una reverse Shell:

• Nos ponemos en escucha.
• Procedemos a enviar la petición, nos direccionará a un GET donde nos muestra el id del usuario creado (/api/users/n).

Y ya tendríamos al usuario creado:

Procedemos a iniciar sesión con las credenciales pwned:pwned en FileBrowser:

EPALEEEEEEEE! Efectivamente, tenemos visión de toda la raíz del sistemaaaaaaaaaaaaaaaaa.

¿Pero podemos ver (¿solo ver?) cualquier archivo??? Según lo que te dije sobre FileBrowser, ¿qué crees?

PUES CLAROOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! Tenemos accesos totales contra cualquier archivo, básicamente somos root, pero sin Shell ):

Escalada de privilegios #

Lo dicho, somos root, pero no se siente como tal, así que “escalemos” a una Shell.

Ya con permisos de escritura contra cualquier archivo, hay muuuuchas maneras de conseguir una Shell, en esta ocasión vamos a jugar con llaves SSH para meter en el archivo authorized_keys de root nuestra llave pública, logrando así que el sistema entienda que root nos dio permiso para iniciar una Shell SSH como él (:

Si no tienes las llaves, las generas rapidamente con ssh-keygen.

Copiamos el objeto local ~/.ssh/id_rsa.pub (llave pública) y lo pegamos en el archivo remoto authorized_keys:

Guardamos cambios e intentamos establecer la Shell:

Liiiistones, tamos en el sistema como el usuario root, que linda vuln :P hemos terminado la resolución de la máquina…

Post-Explotación #

Cracking logins.xlsx 📌

Lo prometido es deuda, veamos el jugueteo con el archivo logins.xlsx. Al descargarlo y abrirlo nos pide una contraseña:

Probando credenciales por default nadita de nada. Buscando en internet llegamos a un post donde indican que con John The Ripper podemos generar un hash crackeable de ese archivo para intentar encontrar la clave que está por detrás:

office2john logins.xlsx > logins.xlsx.hash

Y ahora con John procedemos al la fase del crackeo:

Perfecto, la tenemos. Reintentamos abrir el archivo, colocamos esa contraseña y tada, tenemos acceso al objeto:

Hay varias cositas:

• Un subdominio (elcorreo), que si relacionamos lo que ya tenemos, posiblemente sea una redirección a Squirrelmail.
• Direcciones de correo con posibles nombres de usuario.
• Contraseñas en texto claro.
• Los roles de cada uno.
• Y un mensaje sobre un “código secreto”.

Teniendo en cuenta que las credenciales y el dominio hacen relación con el servicio webmail que ya obtuvimos, procedimos a probar las combinaciones en el login-panel de Squirrelmail, dando las de color verde, acceso correcto y la última incorrecto (: Por ejemplo con pablo vemos:

Hay algunos correos con curiosidades, pero nada más que eso, diría que de lo que intente (los exploits que vimos también con Squirrelmail) es un gran rabbit-hole.

Pero voy a seguir probando, cualquier actualización vuelvo por acá y modifico.

Credenciales en el sistema usuario pablo, leaked 📌

Algo que noté en el sistema es que al ingresar al /home del usuario pablo vemos un script llamado 2fa.py, en su contenido tiene dos cadenas con formado de contraseña:

• Supongo que la primera es la cadena de la que hablan en el logins.xlsx, la clave secreta.
• Y la segunda es confirmado que se trata de la contraseña de sistema para pablo.

No sé si esto sirve (en caso de que esta máquina haya tenido una continuación o algo así), pero pues todo sirve, la post-explotación es importante siempre.

Razón de no poder ejecutar RCE con FileBrowser 📌

Si nos fijamos del cómo está ejecutando el usuario encargado de FileBrowser (root en este caso) el comando, notamos un argumento crucial para entender el porqué nuestra reverse Shell no sirvió:

filebrowser -h
...

No está activado el “poder” para ejecutar comandos :P

Flags 📌

…

Bueno, espero te haya gustado la máquina y me haya hecho entender con el procedimiento.

Una liiinda herramienta llamada FileBrowser qué cayó en nuestras manos para ser explotada.

Bonita escalada. El tema del bruteforce inicial me mató, pero bueno, mejorando y aprendiendo siempre.

Nos leemos luego, abrazos! AAAAA ROMPEEEEER DEEEE TODOOOOOOOOOOOOOO!!