AguaDeMayo

Introducción

Este documento presenta la resolución completa de la máquina AguaDeMayo, diseñada por The Hackers Labs para la plataforma DockerLabs y clasificada como fácil.

El objetivo es ofrecer un análisis claro, ordenado y técnicamente fundamentado, que incluya:

• Identificación de vectores de entrada.
• Explotación basada en credenciales expuestas y técnicas de enumeración.
• Recuperación de información oculta por medio de esteganografía y análisis de contenido.
• Escalada de privilegios mediante abuso de binarios con sudo.

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

1. Reconocimiento: detección de puertos y análisis del contenido web.
2. Explotación: obtención de credenciales y acceso inicial mediante SSH.
3. Escalada de privilegios: interacción entre usuarios hasta la obtención de root.

Todas las pruebas se realizaron en el entorno aislado proporcionado por DockerLabs.

---

Información General

Atributo	Valor
Nombre	AguaDeMayo
Autor	The Hackers Labs
Dificultad	Fácil
Fecha	14/05/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Descomprimir la máquina:

unzip AguaDeMayo.zip

Arrancar el contenedor:

sudo bash auto_deploy.sh AguaDeMayo.tar

El script de despliegue devuelve la IP interna que utilizaremos durante el análisis:

---

Paso 1 — Reconocimiento

1.1 Organización del entorno de trabajo

Mantener un árbol de trabajo ordenado facilita documentar y reproducir cada fase:

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

1.2 Escaneo de puertos

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

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

Puertos detectados:

• 22/tcp — SSH
• 80/tcp — HTTP

La combinación de SSH y un servidor web sugiere que la aplicación web podría contener pistas (credenciales, archivos ocultos o recursos descargables) que permitan acceso al servicio SSH.

1.3 Enumeración web (puerto 80)

Se empleó un escaneo de directorios con ffuf para localizar recursos y rutas interesantes:

ffuf -u "http://172.17.0.2/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt \
  -t 200 -e js,php,txt,html -c -fs 0

Resultados relevantes:

• Página principal (index).
• Directorio /Images.

Al inspeccionar el contenido de la página principal se encontró un bloque de código que, a primera vista, no era legible:

++++++++++[>++++++++++>++++++++++>++++++++++>++++++++++>++++++++++>++++++++++>++++++++++++>++++++++++>+++++++++++>++++++++++++>++++++++++>++++++++++++>++++++++++>+++++++++++>+++++++++++>+>+<<<<<<<<<<<<<<<<<-]>--.>+.>--.>+.>---.>+++.>---.>---.>+++.>---.>+..>-----..>---.>.>+.>+++.>.

Ese fragmento coincide con código en el lenguaje Brainfuck. Se procedió a decodificarlo (con una herramienta de traducción a texto) y se obtuvo una pista significativa para el siguiente paso. (La imagen con la traducción se conserva en el repositorio de evidencia.)

Paralelamente, se descargó y analizó la imagen agua_ssh.jpg ubicada en /Images. Para buscar información oculta se aplicaron técnicas habituales de esteganografía y análisis de metadatos:

• exiftool agua_ssh.jpg — para inspeccionar metadatos.
• steghide y otras herramientas de esteganografía — intento de extracción con posibles contraseñas derivadas del contexto.

No se encontró información utilizable directamente en los metadatos ni mediante steghide con contraseñas comunes.

---

Paso 2 — Explotación (acceso inicial)

La combinación de pistas (nombre de la imagen agua_ssh.jpg y la salida de la decodificación Brainfuck) indicaba la posible existencia de credenciales relacionadas con el servicio SSH.

Con los datos obtenidos, se inició sesión SSH desde la máquina atacante:

ssh agua@172.18.0.2

(La captura de pantalla muestra el acceso correcto al sistema con el usuario Agua.)

Comentario técnico: antes de intentar contraseñas, es buena práctica correlacionar cualquier pista textual encontrada en la web (incluido el resultado del Brainfuck) con nombres de usuario, rutas y nombres de archivos en la aplicación web. En este caso, las pistas permitieron identificar un par usuario/contraseña válido para SSH.

---

Paso 3 — Escalada de privilegios

Una vez dentro como el usuario Agua, el siguiente objetivo es evaluar opciones de escalada de privilegios. Empezamos por listar los privilegios sudo otorgados al usuario:

sudo -l

La salida mostró que Agua puede ejecutar /usr/bin/bettercap como root sin contraseña:

3.1 Abuso de mejorcap (bettercap) para elevar privilegios

Razonamiento: cualquier binario ejecutable con sudo sin contraseña y que acepte comandos o cargue módulos dinámicos puede usarse como vector para ejecutar código arbitrario como root. En este caso bettercap es una utilidad que, al ejecutarse con privilegios, permite interacción con el sistema y la ejecución de subcomandos; por tanto, puede explotarse para escalar privilegios.

Ejecución (como Agua):

sudo /usr/bin/bettercap

Una vez dentro del contexto con privilegios, se aprovechó la capacidad de ejecutar comandos para establecer el bit SUID sobre /bin/bash:

chmod +s /bin/bash

Con el bit SUID establecido en /bin/bash, fue posible lanzar una shell privilegiada preservando los privilegios de root:

/bin/bash -p

Resultado: se obtuvo una shell con UID 0 (root).

Nota de seguridad: el paso chmod +s /bin/bash demuestra claramente un fallo de control de acceso — permitir que un usuario ejecute una utilidad poderosa como bettercap con sudo sin restricciones es una mala práctica. Exponer utilidades administrativas sin restringir subcomandos o sin dejar un sudoers controlado facilita la escalada de privilegios.

---

Fallos de Seguridad Identificados

1. Exposición de utilidades privilegiadas en sudoers: permitir la ejecución de bettercap como root sin controles ni restricciones posibilita la ejecución de comandos arbitrarios con privilegios elevados.
2. Pistas sensibles en contenido web: información útil para el acceso (codificada en Brainfuck y nombres de archivos relacionados con SSH) estaba disponible públicamente en la web. Esto facilita el acceso no autorizado si no se controla el contenido o no se protege con mecanismos de autenticación.
3. Ausencia de análisis y filtrado de información en la aplicación web: archivos y nombres que hacen referencia a credenciales no deberían publicarse en entornos accesibles sin autenticación.

---

Recomendaciones

1. Revisar y endurecer sudoers

   • Evitar conceder permisos NOPASSWD para utilidades que permiten ejecución de subcomandos o carga de módulos.
   • Si es necesario otorgar privilegios, especificar explícitamente los subcomandos permitidos y validar la invocación mediante Cmnd_Alias.

2. Minimizar la información sensible publicada

   • No exponer nombres de archivos, rutas o cadenas que puedan relacionarse con credenciales o con servicios críticos.
   • Revisar el contenido público antes del despliegue y remover pistas/archivos innecesarios.

3. Hardenización de servicios SSH

   • Forzar autenticación por claves públicas cuando sea posible y deshabilitar la autenticación por contraseña para cuentas que no la necesiten.
   • Limitar el acceso SSH mediante listas de control de acceso (firewall) y/o autenticación adicional.

4. Control de artefactos multimedia

   • Evitar subir imágenes con nombres que contengan referencias sensibles (*_ssh, *_pass, etc.).
   • Si se suben recursos multimedia, procesarlos para eliminar metadatos y comprobar que no contienen contenido oculto.

5. Auditoría y monitorización

   • Implementar registros (logging) y alertas ante el uso de privilegios sudo inusuales.
   • Revisar periódicamente el sudoers y las cuentas con privilegios no estándar.