Bola

Introducción

Este documento detalla la resolución completa de la máquina Bola, desarrollada por El Pingüino de Mario para la plataforma DockerLabs y clasificada con una dificultad Media.

El objetivo es describir el proceso completo de compromiso del sistema, desde la fase de enumeración inicial hasta la obtención de privilegios de root, analizando cada vector de ataque y destacando las vulnerabilidades explotadas.

La metodología empleada se divide en tres fases principales:

1. Reconocimiento: identificación de servicios expuestos y análisis inicial del sistema.
2. Explotación: obtención de acceso inicial mediante vulnerabilidades lógicas en la API (IDOR).
3. Escalada de privilegios: abuso de credenciales reutilizadas y configuraciones inseguras para obtener acceso root.

Todas las acciones descritas se realizaron dentro del entorno aislado proporcionado por DockerLabs, con fines exclusivamente educativos.

---

Información General

Atributo	Valor
Nombre	Bola
Autor	El Pingüino de Mario
Dificultad	Medio
Fecha	30/06/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Se descomprime y despliega la máquina virtual proporcionada:

unzip "Bola.zip"
sudo bash auto_deploy.sh "Bola.tar"

Una vez finalizado el despliegue, se obtiene la dirección IP asignada al contenedor:

---

Paso 1 — Reconocimiento

1.1 Organización del entorno

Se crea una estructura de directorios para mantener el trabajo ordenado:

mkdir -p Bola/{content,exploits,nmap,scripts}
cd Bola

1.2 Escaneo de puertos

Se realiza un escaneo completo de puertos TCP para identificar servicios expuestos:

nmap -p- --open -sS --min-rate 5000 -vvv -n 172.17.0.2 -oG allPorts
extractPorts allPorts

Puertos abiertos identificados:

• 22/tcp – SSH
• 12345/tcp – HTTP

---

1.3 Enumeración HTTP

Se procede a realizar un escaneo de directorios y extensiones web:

feroxbuster -u http://172.17.0.2/ \
  -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt \
  -x php,html,txt,js,json -t 100 -C 404

Rutas relevantes encontradas

• /index — Devuelve un JSON indicando user not found, lo que sugiere la presencia de una API REST.

• /login — Indica método incorrecto.

• /user — Solicita un usuario válido.

• /console — Devuelve un error de servidor o proxy.

Con la información recopilada hasta este punto, se determina que el servicio web corresponde a una API REST. Para interactuar de forma más cómoda con los endpoints se utiliza la herramienta Bruno.

Primero se prueba el endpoint /login, cambiando el método GET a POST. Este solicita un usuario y, al ingresar uno válido, responde con login correcto, aunque no proporciona información adicional relevante.

El endpoint /console no resulta explotable, por lo que se continúa con el endpoint /user/1, el cual devuelve la siguiente respuesta:

La respuesta incluye email, id y username, lo que permite identificar una vulnerabilidad de tipo IDOR (Insecure Direct Object Reference), la cual será explotada a continuación.

---

Paso 2 — Explotación (Acceso Inicial)

Al confirmar que el endpoint /user/{id} es vulnerable a IDOR, se procede a enumerar todos los usuarios válidos del sistema. Se sabe que existen únicamente 20 usuarios, por lo que se desarrolla el siguiente script en Python:

import requests

with open('usernames.txt', 'w', encoding='utf-8') as file:
    for i in range(1, 21):
        try:
            url = f"http://172.17.0.2:12345/user/{i}"
            response = requests.get(url, timeout=3)

            if response.status_code == 200:
                data = response.json()
                username = data.get('username')
                if username:
                    file.write(f"{username}\n")
                else:
                    print(f"[-] Usuario {i}: Sin username")
            else:
                print(f"[!] Usuario {i}: Error {response.status_code}")

        except Exception:
            print(f"[!] Usuario {i}: Error de conexión")

print(f"\nUsernames guardados en 'usernames.txt'")

Este script guarda todos los nombres de usuario válidos en el archivo usernames.txt, el cual se utiliza posteriormente para un ataque de fuerza bruta contra el servicio SSH mediante Hydra:

hydra -L usernames.txt -P usernames.txt ssh://172.17.0.2 -t 64 -I

El ataque devuelve credenciales válidas para el acceso por SSH:

Con estas credenciales, se accede al sistema:

ssh steven@172.17.0.2

Acceso inicial conseguido:

---

3 Escalada de privilegios

3.1 De Steven → Baluadmin

Al revisar el contenido del directorio home del usuario steven, se encuentra información interesante en el archivo .bash_history. En este se observa la reutilización de credenciales para MySQL, así como la referencia a un archivo llamado /secretitosecretazo.zip, el cual solo es accesible por usuarios con mayores privilegios.

![content of bash_history]

Se accede a la consola de MySQL utilizando las credenciales encontradas:

mysql -u steven -p steven

Dentro del gestor de bases de datos se localiza la base de datos secretito, la cual contiene una tabla llamada usuarios:

Esta tabla almacena usuarios junto con hashes de contraseñas, aparentemente en formato MD5. Al comparar estos usuarios con los existentes en el sistema, el único que coincide es baluadmin.

Se guarda el hash correspondiente en un archivo llamado baluadmin.hash y se procede a crackearlo utilizando Hashcat:

hashcat -m 0 -a 0 baluadmin.hash rockyou.txt

El hash se crackea rápidamente:

Con la contraseña obtenida, se cambia de usuario:

su baluadmin

Acceso conseguido:

---

3.2 De Baluadmin → Root

Se revisan los privilegios sudo del usuario baluadmin:

sudo -l

Se observa que puede ejecutar el comando unzip como root, lo cual permite descomprimir el archivo secretitosecretazo.zip.

Al descomprimirlo, se obtiene el archivo sorpresitajiji.txt, cuyo contenido es el siguiente:

Este archivo contiene las credenciales del usuario root, por lo que basta con ejecutar:

su root

Acceso root conseguido:

---

Fallos de Seguridad Identificados

• Vulnerabilidad IDOR en la API /user/{id}.
• Falta de autenticación y autorización adecuada en endpoints sensibles.
• Reutilización de credenciales entre servicios (SSH y MySQL).
• Almacenamiento de contraseñas con hash MD5 inseguro.
• Permisos sudo mal configurados (unzip ejecutable como root).
• Exposición de credenciales sensibles en archivos accesibles.

---

Recomendaciones

• Implementar controles de autorización adecuados en la API.
• Evitar el uso de ID secuenciales accesibles sin validación.
• Utilizar algoritmos de hashing seguros como bcrypt o argon2.
• No reutilizar credenciales entre distintos servicios.
• Restringir permisos sudo al mínimo necesario.
• Evitar almacenar información sensible en texto plano.