Log-in/sign-up – Attaques courantes : mass user creation

Nous allons nous intéresser a une faille de sécurité que je rencontre fréquemment lors de bug bounty : la possibilité de créer  un grand nombre d’utilisateurs

Cet article est plus un retour d’expérience sur les différentes vulnérabilités que j’ai pu remonter au cours de bugs bounty. Durant mes recherches, je me suis souvent retrouvé à analyser plus en profondeur les mécanismes d’authentification et de création de compte. J’ai notamment remarqué quelques types de failles qui étaient souvent présentes et il me semble intéressant de partager cela.

Par “mécanisme d’authentification”, j’entends plus précisément tout ce qui touche au profil et à l’ouverture d’une session utilisateur, ainsi qu’à son enregistrement. Il peut donc s’agir :

  • du mécanisme d’enregistrement et de création d’un nouvel utilisateur
  • du mécanisme de log-in/log-out
  • des modification des informations d’authentification (mail, mot de passe et réinitialisation du mot de passe)

Commençons par quelques légères définitions :

  • log-in/log-on :  Il existe une différence substantielle entre ces deux notions mais nous partiront ici du principe qu’il s’agit de s’authentifier sur une plateforme (web, dans notre cas) à l’aide de son login et de son mot de passe (ou autre facteur)
  • le login : le login est le chaine de caractère qui va servir à identifier un utilisateur de façon unique dans le cas d’une authentification simple. Il peut s’agir du nom utilisateur (“jean-kevin35”) ou de l’adresse mail (“jeankevin35@mail.com”) dans la plupart des cas.
  • sign-up : Processus d’auto-enregistrement d’un visiteur.
  • log-out : Processus permettant de fermer une session active, de déconnecter l’utilisateur, qui engendre une suppression de la session utilisateur côté serveur.

Ce premier article est dédié à une faille que j’appelle “mass user creation“, d’autres articles suivront prochainement. Je n’aborderai pas (encore) les attaques sur les mécanismes double/multiple facteur car je n’ai jamais eu à remonter ce genre de vulnérabilité dans le cadre de bug bounty (pour le moment 😉 ).

Note : Je donnerai des exemples techniques dans la mesure du possible, souvent en mode anonymisé, les plateformes de bug bounty n’acceptent pas toujours de voir les vulnérabilités, même patchées, être diffusées publiquement.

Création d’utilisateur en masse : un impact sous évalué

Il s’agit de la faille la plus souvent repérée lors de mes sessions bug bounty. Les vulnérabilités de type “mass user creation” consiste simplement à rejouer le mécanisme de création d’un utilisateur plusieurs fois afin de créer de faux utilisateurs. Il s’agit selon moi d’une faille critique mais donc l’impact est souvent sous-évalué, c’est en tout cas ce que j’ai pu observer lors de la soumission de ce genre de faille à des programmes de bug bounty.

La création d’un utilisateur sur un site web actionne plusieurs mécanismes :

  • Déclenchement d’une suite de formulaire, attachés à une session utilisateur
  • Envoi d’un ou plusieurs mails de confirmation ou d’information sur le profil créé
  • Enregistrement d’informations en base de données
  • Implémentation de différents compteurs et statistiques, notamment utilisés pour comptabiliser le nombre d’utilisateur (gestion des ressources et marketing)

La présence d’une faille de sécurité de ce type peut être repérée lorsque plusieurs points sont validés :

  • Le(s) formulaire(s) ne possède(nt) pas de mécanisme anti-robot (type captcha)
  • Un utilisateur est créé sans validation d’une action humaine (SMS, mail de confirmation)

Ce dernier point peut être à relativiser car la validation d’un lien de confirmation peut être automatisé. Nous voyons donc ici que la checklist est courte, ce qui dans les fait amène à un grand nombre de sites vulnérables.

Concrètement, si le formulaire d’enregistrement d’un utilisateur peut être joué et rejoué par un script, alors un attaquant est en capacité de créer un nombre illimité d’utilisateur sur la plateforme visée. Cela peut avoir des impacts importants sur un site web :

  • Saturation des ressources (base de données principalement)

Sur une plateforme de type Facebook, ce point est difficilement atteignable. Sur l’application web d’une start-up, cela peut être rapide à atteindre car les ressources ne sont pas illimitées. La création d’un utilisateur requiert le stockage de plusieurs informations (login, mot de passe et autres informations personnelles). Également, on peut dans certains cas créer un ensemble de données dans le but de gonfler la place qu’un enregistrement peut prendre en base de données telle qu’une description, une image de profil, etc.

  • Présence d’un grand nombre de faux compte, pollution des statistiques

Le nombre d’utilisateur, inscrits et actifs, est aujourd’hui le nerf de la guerre lorsque l’on souhaite se démarquer de ses concurrents. Avoir un nombre réel est alors important. Afficher  1 million d’utilisateur inscrits alors que 99% sont des faux peut être problématique dans les faits. On peut avoir à investir dans une infrastructures sur-dimensionnée par rapport à son besoin réel par exemple.

  • Blocage de création de compte pour un utilisateur réel

Si les comptes utilisateurs sont créés avec des adresses mails aléatoires, ce point n’est pas un problème. Cependant, il est aujourd’hui facile de se procurer une liste d’adresses mails réelles à partir d’un leak de données (Yahoo, Linkedin, Badoo, etc.) afin de créer des comptes pour de vraies adresses mails. Dans certains cas, les utilisateurs n’en sauront pas notifiés, dans d’autres ils recevront un mail de confirmation sans savoir d’où celui-ci provient.

Si un de ces utilisateurs souhaite un jour se créer un compte sur la plate-forme visée, celui-ci rencontrera un “login/adresse mail déjà utilisée”. Ce qui peut être problématique pour l’utilisateur, mais aussi pour le site web qui perdra des utilisateurs potentiels.

  • Attaque déportée sur les services mail

Il faut ici penser à ce qui est fait des adresses mail une fois que celles-ci sont enregistrées dans le système. Les adresses mail des utilisateurs peuvent être utilisées pour recevoir des campagnes de pubs, des newsletters, des mails d’informations envoyés par la plateforme web. Si 99% des mails sont des faux (non existant) alors le nombre de “Mail non Delivry” peut être important et potentiellement causer des blacklistages de la part de certains fournisseurs. Également, dans le cas où les plateformes ciblées sont hébergées chez des hébergeurs tiers, l’envoi d’un très grand nombre de mail par rapport à la moyenne habituelle peut être vu comme un signal d’infection et causer un blacklistage du service. Dans les faits, une plateforme de 10 000 utilisateurs sur laquelle on crée 3 millions d’utilisateur s supplémentaires va se retrouver à envoyer 3 millions de mail au lieu des 10 000 habituels, l’infrastructure et les différentes offres souscrites chez l’hébergeur peuvent ne pas être ajustées pour cela.

Voici une première exploitation, dans le cadre d’un bug bounty, de ce type de vulnérabilité :

Ici, je suis capable de créer cinq comptes sur une plateforme Magento, installée en local pour l’occasion. L’impact serait plus important simplement en modifiant le paramètre de mon script de “5”à “10000000” par exemple. Je montre ici que la création est automatisée, puisqu’un utilisateur est correctement inscrit sans avoir à valider un quelconque mail.

Suite à cette bonne création, je pourrait très bien automatiser le log-in de chaque utilisateur afin d’uploader une image de profil très volumineuse, ou alors spamer le lien “reset password” pour surcharger le service d’envoi de mail pour chacune des adresses créées si aucun quota n’est mis en place. Mais nous parlerons de la fonctionnalité de réinitialisation du mot de passe plus tard.

Quelques uses cases

Explorons plusieurs scénarios d’exploitation de cette vulnérabilité au travers différents cas rencontrés dans des bugs bounty :

User case 01 : enregistrement simple

Le formulaire d’inscription demande un nom, une adresse mail, une adresse postale et un mot de passe. Une fois ces informations saisies, le compte est directement créé.

Ici, aucune validation n’est nécessaire, on peut donc inscrire une adresse mail existante, même si celle-ci ne nous appartient pas, mais également une adresse mail non-existante. Cela pose plusieurs problèmes. Si l’on inscrit une personne (via son adresse mail) existante, cette personne risque de rencontrer des problèmes si elle souhaite s’inscrire légitimement par la suite (compte déjà existant) et devra penser à réinitialiser son mot de passe pour finalement se retrouver avec un compte contenant des informations fausses. S’il s’agit d’une adresse mail non existante, cela impactera le service mail ainsi que sa réputation (trust) auprès des hébergeurs et des autres services mail :

auth-mecanisme-attaque-01

Cas d’un processus d’enregistrement simple. mass user creation possible

Sur ce diagramme, nous voyons les différents actions à réaliser dans le cas d’une inscription simple. Pour l’utilisateur, il suffit de récupérer le formulaire (potentiellement un token anti-CSRF à réinjecter) puis de soumettre les informations nécessaires. Dans la plupart des cas, aucun captcha n’est en place et le compte est créé directement sans validation. L’attaque consiste donc simplement à scripter ce processus, à nettoyer les cookies de session afin de se faire passer pour un nouvel utilisateur, puis de refaire un tour de boucle, et cela jusqu’à saturation des ressources.

Use case 02 : Enregistrement et validation par mail

Le formulaire d’inscription demande un nom, des informations personnelles, une adresse mail et un mot de passe, la confirmation d’un lien envoyé par mail est nécessaire

Ici, la création d’un compte n’est pas protégé par un captcha, ce qui permet son exécution par un script, mais le compte n’est réellement créé qu’après une validation par mail.

Une nuance est ici à apporter. Il m’est souvent arrivé de trouver des plateformes qui créent le compte, mais dont l’accès n’est pas autorisé tant que le lien du mail d’activation n’a pas été validé. Dés lors, il est possible de créer un grand nombre de compte qui sont dans une attente de validation. Pour une meilleur protection, il serait recommandé de supprimer ces comptes “en attente” au delà de quelques heures/jours

Si l’attaquant utilise des adresses mail sur un domaine dont il est le propriétaire (user01@mondomaine.flute, user02@mondomaine.flute), il est alors possible d’automatiser la réception du mail et la validation du lien qu’il contient. Cela requiert une technique plus poussée et relève donc le niveau de difficulté de la mise en place de l’attaque.

Ici, il est également possible de réaliser une attaque DoS/Mail bombing. En effet, si la création d’un compte peut être automatisée est génère l’envoi d’un ou plusieurs mails. Il est possible de récupérer une liste de mails légitimes afin de les utiliser pour la création des comptes. Cela causera alors l’envoi massif de mail à des utilisateurs qui n’ont rien demandé (pouvant causer une atteinte à l’image de l’entreprise si des utilisateurs tatillons viennent à se plaindre sur les réseaux sociaux), mais aussi une surcharge des services mail selon l’ampleur et la vitesse de l’attaque :

auth-mecanisme-attaque-02

Cas d’un processus d’enregistrement avec mail de validation. mass user creation possible

L’attaque 01 démontre comment une telle exploitation peut impacter un ou plusieurs utilisateurs, ceux-ci recevront des mails qu’ils n’ont pas demandé. Le service mail de l’application web peut également être impacté (blacklistage). Dans le cas de l’attaque 02, les adresses mail utilisées appartiennent à l’attaquant qui est en mesure de valider le lien envoyé. Ainsi, il procède à la création de vrais comptes.

Use case 03 : Enregistrement et auto suppression

Le formulaire d’inscription demande les informations habituelles, le compte est supprimé si aucune action/ login n’est effectué sous 7 jours

Ici, on se retrouve dans le même contexte que précédemment, donc avec les mêmes contraintes et impacts au niveau du service mail. Cependant, si aucune action n’est réalisée au bout d’un certains temps, le compte est supprimé. Cela peut être une bonne option dans le but d’empêcher d’avoir un trop grand nombre de compte “mort”. Cependant il faut veiller à ce que ces actions de “validation” ne soient pas également automatisables. Sans cela il sera possible de rendre un compte “actif” et légitime facilement. Cependant, il s’agit d’une première couche de protection intéressante qu’il m’a été donné de rencontrer.

Maintenant, il faudra expliquer à vos processus métiers et à vos commerciaux pourquoi des clients potentiels se voient leur compte supprimé au bout d’un certain délai 🙂

Use case 04 : Protections suffisante (captcha + mail + auto suppression)

Le formulaire d’inscription demande uniquement le nom et l’adresse mail, est protégé par un captcha, un quota de création par cookie, un lien de validation est envoyé par mail afin de saisir les informations supplémentaires et un mot de passe.

Il s’agit là d’un cas de figure dont la sécurité est relativement bonne. Dans les faits, rare selon les casse-cou souhaitant s’attaquer à ce genre de mécanisme. Le contournement du captcha, si efficace, est déjà une tâche qui éloignera une grande majorité des attaquants. Aucun compte n’est créé tant que le lien du mail n’est pas cliqué, celui-ci amènera l’utilisateur vers la saisie d’un mot de passe, puis des informations personnelles.

auth-mecanisme-attaque-03

Cas d’un processus d’enregistrement avec plusieurs couches de sécurité

Ainsi il est nécessaire pour l’attaquant de développer un script de réception et validation du mail. Puis de re-suivre une suite de formulaire pour la saisie du mot de passe. Cela dans l’éventualité où il parvient à contourner le captcha en place 😉

Parmi les autres protection rencontrée:

  • Quota de création par cookie : il s’agit d’une protection assez faible puisque dans le principe, un utilisateur est en capacité de supprimer ses cookies. Il s’agit là de repérer, pour une session donnée, combien de création ont été effectuées. Dans un cas normal, un visiteur seul sur son poste n’aura besoin de créer qu’un seul utilisateur. Détecter plusieurs tentatives de création par cookie permet d’ajouter une couche de protection supplémentaire. Pour information, ce type de protection était à une époque opérée par OpenClassRooms pour empêcher les utilisateurs de visualiser trop de vidéos/cours en mode gratuit et ainsi, inciter les visiteurs à s’inscrire (rien à voir avec l’authentification/l’enregistrement, mais le principe est le même : le quota)
  • Saisie des informations d’enregistrement après la validation du lien dans le mail envoyé. Ici, il s’agit de demander la saisie du mot de passe et d’autres informations nécessaires à la création du compte uniquement après que l’utilisateur ai cliqué sur le lien présent dans le mail envoyé. Ainsi, le statut de compte en attente n’existe pas puisque aucune information, hormis son adresse mail, n’est à enregistrer. Si l’attaquant n’est pas en capacité de recevoir un grand nombre de lien de création sur des adresses mails différentes et de suivre la suite de formulaire nécessaire à la création d’un compte ensuite, il ne lui sera pas possible de procéder à une attaque.

Quelques protection contre la vulnérabilité Mass User Creation

Comme vous l’aurez vu, il s’agit là avant tout d’une faille logique, qui prend naissance en fonction de la façon dont le mécanisme d’enregistrement a été pensé dés sa phase de conception. Dans la plupart des cas, l’ajout de protections techniques est assez simple. Dans d’autres, il faut revoir le déroulement de l’enregistrement et cela requiert une implication beaucoup plus forte. Parmi les protection à envisager :

  • La première est bien entendu la mise en place d’un captcha efficace, celui-ci est la barrière principale contre l’automatisation et le scripting du remplissage d’un ou plusieurs formulaires. En effet, la présence d’un captcha éloignera la plupart des attaques souhaitant exploiter ce genre d’attaque. Attention à ne pas confondre Token anti-CSRF et Captcha !
  • Il est nécessaire de vérifier la validité des informations saisies par l’utilisateur, au moins son adresse mail. Cela s’opère simplement par l’envoi d’un mail avec un lien de confirmation. Ce lien permet de répondre à plusieurs questions comme “Êtes-vous bien le propriétaire de cette adresse mail ?“, si la réponse est non, l’attaquant ne pourra valider l’inscription et le compte ne saura pas créé. Également “Souhaitez-vous bien créer un compte ?” si un utilisateur reçoit un tel mail sur sa boite mail et qu’il n’a pas demandé la création d’un compte, c’est qu’une autre personne essai de le lui créer. Il lui suffira alors de ne pas cliquer sur le lien. Enfin, et pour le bien de la plateforme web en elle même, cela répondra à la question “cette adresses mail existe-t-elle ?“, évitant ainsi les appels support de l’utilisateur qui s’enregistre avec une mauvaise adresse mail et l’envoi de mail recevant en retour des “non-delivery”.
  • Interdire à tout prix les mail jetables, souvent utiliser dans les cas où l’attaquant ne possède pas de nom de domaine et qu’il est obligé de passer par des adresses mails valides. Sans forcément avoir besoin de tous les domaines proposant des mails jetables, il faut au moins bannir l’utilisation de “yopmail.com”. Encore un fois, c’est une protection qui n’est pas suffisante en elle même mais qui est nécessaire pour constituer un ensemble de barrières de protection efficaces.
  • Savoir gérer les quotas : tant au niveau de la création de compte, ce qui peut être difficile à mettre en place, que sur l’envoi de mail. L’essentiel étant de protéger les services mails d’un éventuel blacklistage, éviter d’envoyer les 3 millions de newsletter au lieu des 10 000 habituels. Un monitoring des inscriptions peut être ici une solution intéressantes, mais peu efficace en terme de protection.

Note : D’autres protections ont été envisagées, en fonction des contextes, dans les exemple plus haut, comme la suppression d’un compte non validé ou inactif après un certain délai

Pour la route, voici une autre exploitation, un peu plus rapide, découverte lors du challenge Bug bounty à la Nuit du Hack 2015 :

Sur cette vidéo, la création est assez rapide, quelques machines arriverons assez rapidement à créer plusieurs centaines de milliers de comptes en quelques heures. Sur cet autre exemple, la  création est beaucoup plus longue (environs 1 seconde) :

Un attaquant déterminé pourra alors s’aider d’un botnet. Par exemple, sur une base de 1 création par seconde, on peut estimer que 10 000 machines parviendrons à 10 000 création de compte par seconde, soit environs 36 millions en une heure.

Nous n’avons pas fait le tour des protections qui peuvent être mises en place. Mais nous voyons tout de même que le processus d’enregistrement peut être assez critique pour les utilisateurs, mais surtout pour la plateforme web visée. Il s’agit parfois de petite subtilités logiques qui permettent néanmoins une exploitation impactante. Comme indiqué en début d’article, les vulnérabilités logiques ne peuvent être détectées par des scans automatiques, seul un humain est capable de comprendre le fonctionnement et la logique d’un processus d’enregistrement, de l’éventuelle présence d’un rejeu, de la présence d’un mail de validation, etc.

Mon retour concernant la soumission de ce type de vulnérabilité dans des bugs bounty est assez mitigé. Parfois l’impact de cette vulnérabilité est très bien compris et pris au sérieux, parfois les rapports sont classés en “hors scope” ou “Non applicable” cas considéré comme du DoS ou comme un simple manque de Captcha. Dans la moitié des cas, la vulnérabilité n’est pas corrigée, laissant alors la plateforme vulnérable aux différents impacts étudiés plus haut.

N’hésitez pas à partager vos avis dans les commentaires.

Vous aimerez aussi...

2 réponses

  1. Julien dit :

    Bonjour,

    merci pour cet article très intéressant.
    Quels types d’outils (de bibliothèques) utilisez-vous pour créer automatiquement les comptes?
    Peut-on imaginer d’utiliser un browser headless ou Selenium par exemple?

    Merci

    • Mickael Dorigny dit :

      Bonjour,
      J’utilise exclusivement des scripts Python écrits manuellement, chaque formulaire est différent est requiert des paramètres et méthodes (GET/POST) qui lui est propre. Il doit exister des outils mais la conception d’un script Python pour réaliser cette tâche ne prend généralement que quelques minutes.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *