ash-authentication-oauth2-oidc-account-takeover-cve-2026-49757-email-based-user-matching

Exploit de preuve de concept pour CVE-2026-49757 démontrant une prise de contrôle de compte OAuth2/OIDC via la correspondance des utilisateurs par e-mail dans AshAuthentication, avec des simulations de gestionnaires vulnérable et corrigé.

Résumé de l'attaque

1. La victime s'inscrit sur une application cible utilisant AshAuthentication
2. L'attaquant s'inscrit auprès de n'importe quel fournisseur OAuth accepté en utilisant l'e-mail de la victime
3. L'attaquant se connecte via OAuth — l'application fait correspondre l'e-mail et crée une session pour le compte de la victime

Aucun identifiant de la victime n'est nécessaire. L'attaquant n'a besoin que de l'adresse e-mail de la victime et d'un compte sur n'importe quel fournisseur OAuth accepté par la cible.

Prérequis

• Python 3.8+
• Bibliothèque standard uniquement (aucune installation pip requise)

Utilisation

Ce que démontre le PoC

Phase 1 : Gestionnaire vulnérable (correspondance par e-mail)

Simule le IdentityChange.change/3 d'AshAuthentication avec upsert_identity: :unique_email :

• La victime s'inscrit avec [email protected] (role: admin)
• La victime lie son compte Google OAuth (sub: google-victim-real-12345)
• L'attaquant s'inscrit sur Keycloak avec [email protected] (email_verified: false)
• L'attaquant initie la connexion OAuth → l'application fait correspondre l'e-mail → l'attaquant obtient la session de la victime

Phase 2 : Gestionnaire corrigé — politique :reject (par défaut)

Simule le UserResolver corrigé avec la recherche (strategy, sub) :

• Le sub de l'attaquant (keycloak-attacker-fake-789) n'est pas trouvé dans user_identities
• on_untrusted_email_match: :reject bloque la connexion
• Attaque empêchée

Phase 3 : Gestionnaire corrigé — politique :confirm

• L'attaquant tente une connexion OAuth avec l'e-mail de la victime
• Le système envoie un jeton de confirmation à l'e-mail de la victime
• L'identité n'est liée que si la victime confirme
• Attaque empêchée (l'attaquant ne contrôle pas la boîte de réception e-mail)

Phase 4 : Gestionnaire corrigé — trust_email_verified? = true

• Un utilisateur légitime se connecte via Google avec email_verified: true → la liaison automatique réussit
• L'attaquant se connecte via Keycloak avec email_verified: false → bloqué
• La commodité est préservée pour les fournisseurs de confiance, la sécurité pour les fournisseurs non fiables

Fichiers

Le correctif (ash_authentication >= 4.14.0)

1. Module UserResolver — résout les utilisateurs par identité (strategy, sub) au lieu de l'e-mail
2. Option on_untrusted_email_match — :reject (par défaut), :confirm ou :warn pour les sub inconnus
3. Option trust_email_verified? — indicateur par fournisseur, défini par défaut à true pour GitHub/Google/Auth0/Slack/Apple
4. Clé unique d'identité — modifiée de (strategy, uid, user_id) à (strategy, uid)
5. Restrictions upsert — user_id n'est jamais mis à jour en cas de conflit
6. Avertissements à la compilation — pour les stratégies sans identity_resource

Références

• NVD — CVE-2026-49757
• GHSA-777c-2fxx-qr28
• OpenID Connect Core §5.7 — Stabilité des revendications
• AshAuthentication sur Hex.pm

Avertissement

Ce PoC est destiné uniquement à des fins éducatives et de tests défensifs. Testez uniquement sur des systèmes dont vous êtes propriétaire ou pour lesquels vous disposez d'une autorisation explicite.