Avec de l’anticipation, les pirates peuvent créer des situations qui leur permettent de s’emparer d’un compte qui vient tout juste d’être créé.
Le problème c’est que pour de nombreux sites, lorsque tu demandes de réinitialiser le mot de passe, le site valide simultanément le nouveau mot de passe et l’émail du compte (souvent l’email est utilisé comme sel/salt pour le hashage du mot de passe).
Dit différemment, dans la base de donnée du site, tu as un champs « hash(pw) » un champ « email » un champ « non_validated_email » et un champ « temporary_pw ».
Lorsque tu demandes de changer de mail, le site remplit le champ « non validated email » et attends que tu valides l’email (ce que tu ne fais pas, vu que tu n’es pas au courant de la demande). Idem pour re-initialiser le mot de passe.
Donc le pirate qui n’a ni accès à ta boite mail ni à ton compte, peut demander la le changement de l’émail (via l’API adéquate). Tu n’es pas au courant de la demande.
Lorsque tu demandes de réinitialiser le mot de passe, tu visites le lien dans le mail, tu vas changer ton mot de passe mais tu valides simultanément le changement de mail en cours (ce dont tu n’es pas au courant).
Le pirate reçoit alors un mail sur sa boite « votre mot de passe a bien été modifié ». Il n’a plus qu’à re-initialiser le mot de passe à son tour pour accéder à ton compte.
Le vrai problème là dedans, ce n’est pas le fait de lier mot de passe et email (après tout, plus il y a d’information/entropie, meilleur est le hashage des identifiants), c’est le fait que chaque site ait ses propres règles à la c.n pour les mots de passe et donc qu’il est impossible de se souvenir des mots de passe (sauf à avoir des mots de passe faibles) ou un gestionnaire de mot de passe. Du coup, tu passes bien trop souvent par la fonction « ré-initialiser le mot de passe » et donc ce genre d’attaque fonctionne.
Du coup, vu que les mots de passe sont c.iant à gérer pour les utilisateurs, le site autorise des sessions super longues (plusieurs semaines) donc tu ne te rends pas compte que ton email a été modifié avant qu’il ne soit bien trop tard. De plus la demande de changement d’email est valide trop longtemps (ça devrait être quelques minutes, mais souvent c’est plusieurs jours), ce qui laisse au pirate une grande fenêtre d’attaque.
Enfin, le fait de changer de mail devrait systématiquement envoyer une requête à l’ancien email l’utilisateur avec l’adresse IP trucmuche a demandé à changer votre email, et invalider la session en cours de l’utilisateur.
5 « J'aime »
Oui enfin moi je suis développeur et on génère un token pour chaque envoi de mail avec une expiration à quelques heures. Quand l’utilisateur clique sur le lien dans le mail, il y a le token qui permet de ne traiter que la demande en question associée à ce token.
L’adresse email étant unique en base de données dans notre cas (pas possible d’avoir 2 comptes avec même adresse email), pas possible de l’associer à un autre compte si déjà utilisée. Du coup je ne comprends pas si ces cas peuvent se produire :/.
Quand il parle d’API, je pense qu’il parle du fait que tu fais une requête HTTP de type PUT sur une URI sur un serveur pour la modification de mail avec des paramètres (ex « oldEmail » et « newEmail ») mais tu peux appeler cette même URI avec des paramètres modifiés (des valeurs différentes correspondant au compte de la victime). Sans forcément être connecté au compte de la victime.
Le hackeur peut créer un compte pour lui, faire la modification tout en analysant les requêtes faites au serveur avec les paramètres pour les identifier puis rappeler l’URI en mettant les paramètres qu’il veut.
Normalement en tant que développeur on doit faire des vérifications à la réception de la requête coté serveur entre par example l’utilisateur connecté et l’ancien email renseigné et rejetter la demande. Je ne pense pas que l’article parle de ce type de problème.
J’aimerais bien savoir comment tout ca est géré sur ces sites pour comprendre d’où vient le problème.
Autre technique : pour les sites permettant à la fois une authent oauth (FB, twitter, google…) et par email, créer un compte avec email + password avec l’email de la cible et attendre que celle-ci fasse un signup oauth.
@philou44300 : Y en a qui font le job correctement, à priori comme vous et y a les autres.
« J’aimerais bien savoir comment tout ca est géré » : faut pas… vous risqueriez certainement l’avc lol
Non pas tout le temps. Si tu suis la procédure du site, oui, il faut que tu cliques sur « Mon profil », « Changer de mail », tu auras un formulaire dans lequel tu entres l’ancien email (ou pas, suivant l’ergonomie du site) et le nouvel email. Le formulaire est soumis à une URL.
En réalité, n’importe qui peut appeler cette URL sans avoir de token d’authentication valide. Normalement, ça ne fait rien si le site est bien fait, mais sur certains sites, ça remplit le champ « non_validated_email » (ce qui n’est pas sensé être critique, vu que tu as toujours le champ email & pw valide). Ça envoi un mail avec un lien à confirmer au nouvel email, et sur l’ancien email sur les bons sites mais sur la plupart des sites, non car si tu veux changer de mail, c’est que tu n’as probablement plus accès à ton ancienne boite mail.
Dans tous les cas, le token provisoire à confirmer est le même que pour le mot de passe temporaire/oublié (fainéantise des devs) et ne nécessite donc pas d’être connecté. Le fait que toi, tu vas te connecter après pour ré-initialiser le mot de passe, tu valides les 2 champs d’un coup.
Juste une remarque: Si le site t’envoyait un mail (ancien) à la demande de changement de mail (nouveau), avec un lien, je pense que la première des choses que tu ferais serait d’aller te connecter au site en question. Pour peu que ce ne soit pas un site que tu utilises souvent, bim, réinit de mot de passe et t’es foutu.
Normalement, tu ne peux pas, puisque OAUTH ne transmet pas les informations du compte d’origine, seulement un token (et un pseudo/identifiant). Donc le compte email + pw que tu crées, même s’il a le même pseudo, pour le site, c’est 2 comptes différents. C’est d’ailleurs une des critiques principale d’OAUTH, le manque de transparence sur le compte délégué.
Même si l’utilisateur oublie qu’il a utilisé OAuth la première fois et utilise son email la deuxième fois (et donc « ré-init » de mot de passe), il devrait recevoir la requête de ré-initialisation sur sa boite mail et non celle du pirate.
De plus pour valider le compte la première fois, le pirate n’ayant pas accès à la boite mail de l’utilisateur, il est normalement marron.
Le seul cas possible, c’est lorsque un site utilise un identifiant pour se connecter (et pas un email), et que le pirate enregistre cet identifiant sur sa boite email (et donc un PW connu par lui). Dans ce cas, lorsque toi tu essayes de te connecter (en ayant oublié que tu avais utilisé OAuth), tu entres ton identifiant habituel, ton mot de passe (invalide).
Ça échoue, tu cliques « oubli du mot de passe » et là, ça envoie un mail au pirate avec un lien pour réinitialiser le mot de passe.
Ici, le pirate pourrait, à la limite forwarder le mail (plus exactement, bouncer le mail) vers ton email habituel. Tu cliquerais alors le lien et changerais le mot de passe du compte pirate.
Là, le pirate peut alors, à son tour, changer le mot de passe et avoir accès à son propre compte.
Pas super utile, sauf à attendre que tu utilises le/son compte pendant des mois et que tu y déposes des choses utiles. Mais ça veut dire que tu es distrait et ne vérifie pas l’email du compte. C’est possible mais tordu.
Mais du coup comment le propriétaire peut créer son compte si le pirate l’a créé avant ? Il devrait avoir un message qui lui dit que le compte existe déjà et l’inviter à choisir un autre identifiant.