CVE-2026-49757 — Acquisizione account OAuth2/OIDC AshAuthentication

Proof of Concept per CVE-2026-49757 — una vulnerabilità critica in AshAuthentication in cui i callback OAuth2/OIDC risolvevano gli account utente locali tramite indirizzo email invece della coppia identità (strategy, sub), consentendo l'acquisizione di account senza autenticazione.

Riepilogo dell'attacco

1. La vittima si registra su un'applicazione target usando AshAuthentication
2. L'attaccante si registra su qualsiasi provider OAuth accettato usando l'email della vittima
3. L'attaccante accede tramite OAuth — l'app abbina per email e crea una sessione per l'account della vittima

Non sono necessarie le credenziali della vittima. L'attaccante ha bisogno solo dell'indirizzo email della vittima e di un account su qualsiasi provider OAuth accettato dal target.

Requisiti

• Python 3.8+
• Solo libreria standard (nessun pip install necessario)

Utilizzo

# Modalità interattiva (consigliata)
python3 exploit.py

# Modalità non interattiva (input tramite pipe)
echo | python3 exploit.py

Cosa dimostra il PoC

Fase 1: Gestore vulnerabile (Abbinamento email)

Simula il IdentityChange.change/3 di AshAuthentication con upsert_identity: :unique_email:

• La vittima si registra con [email protected] (ruolo: admin)
• La vittima collega un account Google OAuth (sub: google-victim-real-12345)
• L'attaccante si registra su Keycloak con [email protected] (email_verified: false)
• L'attaccante avvia il login OAuth → l'app abbina per email → l'attaccante ottiene la sessione della vittima

Fase 2: Gestore corretto — Politica :reject (predefinita)

Simula il UserResolver corretto con ricerca per (strategy, sub):

• Il sub dell'attaccante (keycloak-attacker-fake-789) non viene trovato in user_identities
• on_untrusted_email_match: :reject blocca il login
• Attacco prevenuto

Fase 3: Gestore corretto — Politica :confirm

• L'attaccante tenta il login OAuth con l'email della vittima
• Il sistema invia un token di conferma all'email della vittima
• L'identità viene collegata solo se la vittima conferma
• Attacco prevenuto (l'attaccante non controlla la casella di posta elettronica)

Fase 4: Gestore corretto — trust_email_verified? = true

• Un utente legittimo accede tramite Google con email_verified: true → il collegamento automatico riesce
• L'attaccante accede tramite Keycloak con email_verified: false → bloccato
• Comodità preservata per provider fidati, sicurezza per quelli non fidati

File

La correzione (ash_authentication >= 4.14.0)

1. Modulo UserResolver — risolve gli utenti per identità (strategy, sub) invece che per email
2. Opzione on_untrusted_email_match — :reject (predefinita), :confirm o :warn per sub sconosciuti
3. Opzione trust_email_verified? — flag per provider, predefinito true per GitHub/Google/Auth0/Slack/Apple
4. Chiave unica identità — cambiata da (strategy, uid, user_id) a (strategy, uid)
5. Restrizioni upsert — user_id non viene mai aggiornato in caso di conflitto
6. Avvisi in fase di compilazione — per strategie senza identity_resource

Riferimenti

• NVD — CVE-2026-49757
• GHSA-777c-2fxx-qr28
• OpenID Connect Core §5.7 — Stabilità delle rivendicazioni
• AshAuthentication su Hex.pm

Dichiarazione di non responsabilità

Questo PoC è solo a scopo educativo e di test difensivo. Esegui test solo su sistemi di tua proprietà o per i quali hai esplicita autorizzazione.