Le Pre-Account Takeover (ou vol de compte par anticipation) est un type d’attaque que nous réalisons très souvent lors de nos audits. Même si elle est possible uniquement dans des situations très spécifiques, les possibilités d’exploitations malveillantes sont de plus en plus courantes avec des conséquences qui peuvent être très graves sur la sécurité des données.
Dans cet article, nous présenterons les principe et le fonctionnement d’une attaque de type Pre-Account Takeover. Nous examinerons également ses spécificités via un exemple concret d’attaque ainsi que les bonnes pratiques pour contrer le risque.
Qu’est-ce qu’une attaque de type Pre-Account Takeover ?
Prérequis pour réaliser un Pre-Account Takeover
Une attaque de type Pre-Account Takeover cible spécifiquement un compte ou un utilisateur. Pour ce faire, les conditions suivantes doivent être réunies :
- La plateforme doit permettre la création de comptes, et cette création doit être effective en base de données avant toute validation de l’email, ou aucune validation d’email ne doit être requise.
- La plateforme doit autoriser l’authentification via SSO (Google, Microsoft, IDP du client, etc.), sans pour autant l’imposer.
- L’utilisateur doit pouvoir choisir entre l’authentification classique (couple identifiant et mot de passe) et l’authentification SSO.
Bien que ce prérequis puisse sembler rare, de plus en plus d’applications autorisent la création de comptes et l’authentification par SSO en complément du schéma classique identifiant et mot de passe.
Principes d’exploitation d’un Pre-Account Takeover
Un attaquant exploite un Pre-Account Takeover en ciblant un utilisateur dont il connait l’adresse email et qui va prochainement s’inscrire sur la plateforme via l’authentification SSO ; souvent en utilisant des techniques d’ingénierie sociale.
Il commence par créer un compte en utilisant l’adresse email de sa cible, via la procédure classique de création de compte, définissant ainsi l’email et un mot de passe. Comme l’attaquant n’a pas accès à la boite email de l’utilisateur, il ne pourra pas valider le compte si une vérification est requise, mais cela n’est pas essentiel pour l’attaque.
Le but est de pré-créer un compte qui sera associé à un futur utilisateur légitime. Lors de cette création, un email peut être envoyé à l’utilisateur légitime pour confirmer la création du compte, ce qui réduit la discrétion de l’attaque.
Ensuite, l’attaquant attend que l’utilisateur légitime se connecte via SSO. L’email de l’utilisateur correspondant à un compte déjà existant créé par l’attaquant, l’authentification SSO fonctionne et l’utilisateur est redirigé vers ce compte. L’utilisateur ne se rend compte de rien, pensant simplement avoir créé son propre compte.
De son côté, l’attaquant peut se connecter au compte à tout moment, utilisant l’authentification classique (email et mot de passe). Il peut ainsi consulter, modifier ou supprimer les données de l’utilisateur légitime.
Cette attaque repose sur de nombreuses conditions, ce qui limite sa probabilité de succès. Toutefois, si elle aboutit, l’impact peut être grave selon les données gérées par la plateforme, comme un vol de compte classique.
Exemple d’attaque de type Pre-Account Takeover réalisée sur une application web
Prenons l’exemple d’une application web permettant de gérer des documents personnels. Les utilisateurs peuvent y créer un compte et souscrire à un abonnement pour accéder à toutes les fonctionnalités, comme le stockage, le partage de documents, et les annotations.
Cette application permet aux utilisateurs de s’authentifier avec leur compte Gmail via le SSO Google. Elle permet également aux utilisateurs de créer directement un compte avec un couple identifiant, mot de passe.
Voici un exemple de ce à quoi cette page d’authentification ressemble :
L’attaquant sait, grâce à des techniques d’ingénierie sociale, que l’utilisateur John Brown envisage d’utiliser cette application. Il connait également l’adresse Gmail de John Brown : [email protected].
L’attaquant crée donc un compte avec cette adresse email en utilisant la méthode classique de création de compte (lien visible en bas de la capture ci-dessus), sans passer par le SSO Google ou Apple. Après avoir rempli le formulaire de création, la requête suivante est envoyée au serveur :
POST /register HTTP/2
Host: test.vaadata.com
User-Agent: Custom user agent
Content-Type: application/json
Content-Length: 104
{"email":"[email protected]", "firstname":"john", "lastname":"Brown", "password":"verystrongpassword"}Comme nous pouvons le voir, il définit un mot de passe pour le compte. Il ne peut cependant pas accéder à l’adresse email, car il n’en est pas propriétaire.
Le compte reste donc en attente de validation. L’attaquant n’a plus qu’à attendre que l’utilisateur légitime se connecte.
Voici ce que l’attaquant voit une fois authentifié :
Quelques jours plus tard, John Brown arrive sur l’application web. Il se rend sur la page principale et voit qu’il peut utiliser son compte Gmail.
Il s’authentifie via le SSO Google. Cependant, au lieu de créer un nouveau compte, il est redirigé vers celui créé par l’attaquant, son adresse Gmail étant déjà associée. John ne se rend pas compte qu’il ne s’agit pas d’un nouveau compte.
Comme l’authentification a eu lieu via Gmail, l’email est considéré comme validé et le tooltip visible dans la capture précédente n’est plus visible :
Il utilise donc la plateforme et upload un document confidentiel. Ci-dessous la requête http d’upload :
POST /documents HTTP/2
Host: test.vaadata.com
Cookie: session=***
User-Agent: Custom user agent
Accept: */*
Accept-Encoding: gzip, deflate, br
Content-Type: multipart/form-data; boundary=---------------------------41902792651389033399194766463
Content-Length: 1188
-----------------------------41902792651389033399194766463
Content-Disposition: form-data; name="doc"; filename="internal_network_doc.pdf"
Content-Type: application/pdf
[…TRUNCATED DATA…]
De son côté, l’attaquant n’a qu’à utiliser l’authentification classique pour accéder au compte et voler le document.
POST /login HTTP/2
Host: test.vaadata.com
User-Agent: Custom user agent
Accept: */*
Content-Type: application/json
Content-Length: 64
{"email":"[email protected]", "password":"verystrongpassword"}Comment prévenir les attaques de type Pre-Account Takeover ?
Pour prévenir ce type d’attaques, plusieurs actions peuvent être mises en place :
- Vérification de l’email avant la création du compte : Le compte ne doit être créé sur la plateforme que lorsque l’email utilisé a été vérifié. Pour cela, un lien de vérification contenant un jeton unique, indévinable, et à durée limitée doit être envoyé à l’adresse email de l’utilisateur. Ce jeton est lié à l’email fourni lors de l’inscription. Lorsque l’utilisateur clique sur le lien, il est redirigé vers une page où il peut définir son mot de passe, et le jeton est alors vérifié côté serveur. Si le jeton correspond à l’email fourni, le compte est créé, garantissant que l’utilisateur a bien accès à cette adresse email. Ce même principe doit s’appliquer lors du changement d’adresse email pour sécuriser la gestion des comptes.
- Informer l’utilisateur en cas de compte déjà existant : Lors de la première connexion via SSO, si un compte existe déjà avec la même adresse email, un message doit avertir l’utilisateur qu’un compte existe déjà et lui demander s’il souhaite utiliser ce compte. Le message pourrait indiquer : « Un compte associé à cette adresse mail existe déjà sur la plateforme. Souhaitez-vous associer votre compte à celui déjà existant ? Si vous n’êtes pas à l’origine de la création de ce compte, veuillez contacter le support. » Si l’utilisateur accepte, l’authentification par login/mot de passe doit être désactivée et seul le SSO doit être autorisé. Toutes les sessions existantes (ou JWT) doivent également être invalidées côté serveur pour déconnecter un éventuel attaquant encore connecté.
Auteur : Yoan MONTOYA – Pentester @Vaadata