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.
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 :
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.
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.
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 : johnbrown@gmail.com.
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.www.vaadata.com
User-Agent: Custom user agent
Content-Type: application/json
Content-Length: 104
{"email":"johnbrown@gmail.com", "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.www.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.www.vaadata.com
User-Agent: Custom user agent
Accept: */*
Content-Type: application/json
Content-Length: 64
{"email":"johnbrown@gmail.com", "password":"verystrongpassword"}Pour prévenir ce type d’attaques, plusieurs actions peuvent être mises en place :
Auteur : Yoan MONTOYA – Pentester @Vaadata
