// 01
Reconocimiento
Caving es una máquina Linux de dificultad Very Easy que gira en torno a un Splunk mal configurado. Credenciales por defecto y una vulnerabilidad de autorización (CVE-2023-32707) se combinan para llevarnos de invitado anónimo a root en menos de diez comandos:
// LAS IPs CAMBIAN EN CADA DESPLIEGUE
La IP del objetivo (aquí 10.129.5.241) y tu IP de VPN / LHOST
(aquí 10.10.16.7, interfaz tun0) cambian en cada sesión. Compruébalas
con ip a y en el panel de HTB, y reemplázalas antes de copiar cualquier comando —
un LHOST incorrecto significa que la reverse shell nunca llega.
Empezamos por saber qué corre en el objetivo. Con -sV pedimos también la versión de cada servicio, clave para buscar vulnerabilidades conocidas.
El 22 es SSH (inútil sin credenciales). Los 8000 (interfaz web)
y 8089 (API REST de administración, splunkd) son de
Splunk, software empresarial de análisis de logs con mucho historial
de malas configuraciones y escaladas de privilegios. Verlo expuesto es una señal de alerta.
// 02
Login: por qué Hydra falla y usamos Metasploit
El instinto es probar credenciales por defecto a mano y, si fallan, automatizar con
Hydra. Pero el login de Splunk usa un token anti-CSRF
(cval) que cambia en cada sesión y debe coincidir con una cookie: hay que
pedir primero la página de login para obtener el token y enviarlo junto a la cookie en cada
intento. Además, Hydra v9.6 tiene un bug conocido al combinar la condición de fallo con headers
personalizados. En vez de pelear con eso, usamos la herramienta hecha para el trabajo.
El módulo auxiliary/scanner/http/splunk_web_login ya sabe manejar el token CSRF y las cookies automáticamente en cada intento. Le damos listas de usuarios y contraseñas comunes de SecLists y que pare al primer acierto:
// PRIMERA PUERTA: guest:password
Usuario guest, contraseña password. En el mundo real, las contraseñas débiles siguen siendo la causa número uno de brechas. A veces la herramienta «obvia» (Hydra) no es la correcta: reconocer cuándo cambiar ahorra mucho tiempo de debugging.
// 03
Enumeración de usuarios
Con guest:password entramos a la interfaz web
(http://10.129.5.241:8000) y vamos a Settings → Users. Hay tres
cuentas:
| USUARIO | NOMBRE COMPLETO | ROL |
|---|---|---|
| guest | — | user |
| whisssssp3r | Aura Katikus | user |
| woodenk | Administrator | admin |
woodenk es la cuenta con privilegios de administrador — nuestro siguiente objetivo. Normalmente necesitaríamos su contraseña… salvo por la CVE que viene a continuación.
// 04
La vulnerabilidad: CVE-2023-32707
Splunk (versiones anteriores a 9.0.5) tiene un fallo de control de acceso:
// EN CRIOLLO
Es como si un empleado de soporte, que solo debería resetear contraseñas de usuarios normales,
pudiera también resetear la del dueño de la empresa — por un descuido en el sistema de permisos.
El usuario guest de esta máquina tenía el permiso edit_user mal
asignado. Por eso funciona.
// 05
Explotación · De guest a root
El módulo exploit/multi/http/splunk_privilege_escalation_cve_2023_32707
hace todo de una vez: cambia la contraseña de admin abusando de edit_user, inicia
sesión con la nueva, sube una app maliciosa a Splunk (las apps admiten scripts
que se ejecutan en el servidor — justo lo que se abusa) y entrega una shell.
// DOS IPs QUE AMBAS CAMBIAN
RHOSTS (10.129.5.241) es el objetivo del panel de HTB; LHOST
(10.10.16.7) es TU IP de VPN (tun0, mírala con ip a). Un LHOST
incorrecto = reverse shell que nunca llega. TARGET_USER woodenk es a quién le
cambiamos la contraseña sin saberla.
En orden: se logueó como guest, confirmó el permiso edit_user, le
cambió la contraseña a woodenk por una aleatoria, inició sesión como él (ya con
rol admin), empaquetó y subió una app maliciosa, y esa app se ejecutó devolviendo una shell a
nuestro listener.
¿Con qué privilegios quedamos? Splunk corría directamente como root — un error grave de configuración. Apenas conseguimos RCE, ya teníamos las llaves del reino:
// FLAG · ROOT
whoami → root: máquina comprometida por completo. La flag de root
se obtiene leyendo /root/root.txt. Como Splunk corría como
root, el RCE equivalió directamente a control total, sin necesidad de escalada
adicional.
// LECCIONES Y MITIGACIÓN
Cuatro descuidos encadenados: credenciales débiles (guest:password nunca debería existir), el permiso edit_user mal asignado a una cuenta de bajo nivel (principio de mínimo privilegio), Splunk sin parchear (< 9.0.5, afectado por CVE-2023-32707) y, sobre todo, el servicio corriendo como root. Si Splunk hubiera corrido como un usuario de servicio dedicado, el RCE no habría sido compromiso total inmediato — habría hecho falta una escalada adicional.
// 06
Referencia de Comandos
- -sV — versión de cada servicio
- -p- — todos los puertos si quieres ir más allá de los comunes
- RHOSTS / RPORT — IP y puerto (8000)
- USER_FILE / PASS_FILE — wordlists de SecLists
- STOP_ON_SUCCESS — parar al primer acierto
- USERNAME / PASSWORD — guest:password (bajo privilegio)
- TARGET_USER — el admin a secuestrar (woodenk)
- LHOST — tu IP de VPN (tun0) para la reverse shell
- whoami — usuario actual
- find / -name root.txt 2>/dev/null — localiza la flag silenciando errores
- ip a — ver tu LHOST (interfaz tun0) antes del exploit
// 07
Glosario
splunkd, 8089). Permite instalar apps con scripts que corren en
el servidor, lo que la convierte en objetivo habitual de RCE.
edit_user puede cambiar la contraseña de cualquier otro usuario
(incluido admin) sin conocer la actual, porque no se valida bien grantableRoles.
Permite account takeover del administrador.
guest aquí) y combinado con la CVE,
se convierte en la llave para secuestrar la cuenta admin.
cval) ligado a una cookie: por eso Hydra
«genérica» falla y hay que pedir la página antes de cada intento — lo que el módulo de
Metasploit hace solo.
auxiliary hacen tareas sin payload
(escaneo, fuerza bruta de login) y los exploit aprovechan una vulnerabilidad para
ejecutar código y abrir una sesión. Aquí usamos uno de cada: brute-force y, luego, RCE.
tun0), a donde llega la conexión. Un LHOST mal puesto = shell que nunca
llega.
edit_user, y luego se inicia sesión con la
nueva. El resultado es el mismo — control de la cuenta privilegiada.