Le vol de comptes est une pratique courante qui met en danger la sécurité des utilisateurs et de leurs données. L’impact pour les victimes dépend du type de compte ciblé. Il peut être mineur s’il s’agit d’un compte fidélité personnel, mais devient critique pour un compte administrateur d’entreprise.
Les attaques utilisent diverses techniques, souvent basées sur des campagnes de masse pour voler un maximum d’identifiants. Cependant, il existe aussi des vulnérabilités applicatives permettant des vols de comptes plus ciblés. La présence de ces failles représente un risque majeur pour les entreprises, surtout si un compte administrateur est compromis.
Dans cet article, nous détaillerons les principales techniques utilisées pour voler des comptes utilisateurs. Avec des cas concrets à l’appui, nous présenterons également les bonnes pratiques et mesures à implémenter pour réduire les risques.
Campagnes de Vols d’identifiants
La plupart des vols de comptes proviennent de campagnes de grande envergure visant à obtenir les informations d’authentification de nombreuses victimes. ces opérations reposent sur plusieurs techniques :
- Fuites de données : les attaquants exploitent des listes d’identifiants obtenues à la suite de failles de sécurité sur divers sites web. Cela leur permet non seulement d’accéder à ces sites, mais aussi à d’autres comptes si les victimes utilisent les mêmes identifiants.
- Malwares « stealers » : ces logiciels malveillants infectent les ordinateurs des victimes pour exfiltrer des données sensibles, comme les mots de passe ou les cookies de session. Les attaquants diffusent ces stealers par des campagnes de phishing ou via des sites web, encourageant les victimes à les installer involontairement.
- Phishing : les campagnes de phishing, par e-mail ou SMS, incitent les victimes à divulguer leurs informations d’authentification en se faisant passer pour des applications légitimes. Ces articles dédiés au phishing (par email) et au smishing (phishing par SMS) détaillent les risques associés et les moyens de s’en protéger.
Ces techniques permettent aux attaquants de créer de vastes listes d’identifiants valides, facilitant des attaques ciblées ultérieures. Elles exploitent les erreurs ou l’inattention des victimes, que ce soit par la réutilisation d’identifiants ou par la crédulité face à un e-mail frauduleux. Toutefois, les attaquants peuvent également voler des comptes en exploitant des failles sur les sites ciblés, sans interaction directe avec les victimes.
Vulnérabilités applicatives pouvant mener à un vol de compte
L’exploitation de failles dans les applications web pour voler des comptes nécessite plus de temps et d’efforts que les campagnes de masse. En effet, chaque cas est unique et demande une analyse spécifique par l’attaquant. Cependant, cette approche permet des attaques plus ciblées, donnant un accès systématique à tous les comptes concernés.
Les failles menant au vol de comptes se présentent sous deux formes. La première, plus intuitive, consiste à voler des cookies de session ou deviner les informations de connexion via brute force.
La seconde forme, spécifique aux applications web, cible les fonctionnalités de réinitialisation de mot de passe ou d’email. L’objectif est d’exploiter une faille ou de contourner les processus pour remplacer les informations de connexion d’une victime par celles contrôlées par l’attaquant.
Attaques brute force
Pour être réalisée, cette attaque nécessite que les comptes visés utilisent des identifiants relativement faibles.
Voyons un cas concret rencontré lors d’un pentest d’application web.
Le processus de connexion ne reposait pas sur un mot de passe, mais exclusivement sur l’utilisation d’un code à 6 chiffres envoyé par SMS, valide pendant 10 minutes.
Ce processus est illustré dans le schéma ci-dessous :
Cependant, l’application n’était protégé par aucune forme de rate limiting. Il était donc possible de tirer parti du fait qu’un code à 6 chiffres ne représente que 1 million de combinaisons; un nombre restreint pour une attaque brute force.
En effectuant des tests de charge, il est apparu que le serveur pouvait traiter environ 2000 requêtes de connexion par minute (étape 5). Il aurait donc fallu environ 19 heures pour compromettre un compte (avec une probabilité de succès de 90%).
Bien que ce processus soit chronophage, la vulnérabilité permettait de viser n’importe quel compte. Un seul compte bien choisi (comme un compte administrateur) aurait permis d’acquérir les plus hauts niveaux de privilèges.
Ainsi, notre attaque s’est déroulée comme suit :
- Dans les premières secondes, générer autant de codes que possible (20 dans notre cas). Chaque code généré déclenchait l’envoi d’un e-mail, ce qui ralentissait considérablement le serveur en cas de charge excessive.
- Effectuer un brute force avec des codes aléatoires pendant les 10 minutes de validité des codes générés.
- Répéter ces deux étapes autant de fois que nécessaire.
À raison de 2000 requêtes par minute, avec 20 codes valides parmi le million de possibilités, il faut environ 1 heure pour avoir une probabilité de 90% de trouver un code valide.
Cette attaque peut être automatisée en utilisant l’outil Intruder de Burp, lancé toutes les 10 minutes.
Après quelques essais, nous avons obtenu un cookie de session valide, indiquant que le vol de compte est un succès (voir image ci-dessous).
Cet exemple ne présente qu’une technique de brute force. Pour plus d’informations, vous pouvez consulter notre article dédié : Attaques brute force : principes et bonnes pratiques sécurité.
Failles Cross-Site Scripting (XSS)
Cette faille n’est pas exclusive au vol de comptes. Cependant, elle peut le permettre si des protections adéquates ne sont pas en place. Nous ne détaillerons pas ici les principes de base des XSS, mais plutôt les différents scénarios qui peuvent mener au vol de comptes.
Pour une exploration plus approfondie des XSS, nous vous renvoyons vers notre article dédié : Failles XSS (Cross-site Scripting) : principes, types d’attaques, exploitations et bonnes pratiques sécurité.
Lorsqu’un attaquant réussit à injecter une XSS sur un site web, plusieurs scénarios peuvent lui permettre de voler des comptes :
- Si la sécurité des cookies est mal configurée, il est possible d’exfiltrer directement les cookies de la victime vers un serveur externe. Dans ce cas, l’attaquant peut accéder au compte de la victime sans être arrêté par des protections comme le MFA. Cependant, le vol de compte est limité par la durée de validité de la session exfiltrée.
- Si des informations d’authentification telles qu’un couple « nom d’utilisateur/mot de passe » ou une clé d’API sont visibles en clair dans une partie de l’application, l’attaquant peut développer un payload JavaScript pour effectuer des requêtes en lieu et place de la victime, récupérer ces informations et les exfiltrer vers un serveur externe.
- Si les deux premiers scénarios ne sont pas possibles, il est parfois envisageable de voler les comptes des victimes en modifiant directement leurs informations de connexion à la place de les exfiltrer. Par exemple, si la fonctionnalité de changement d’adresse e-mail ne requiert pas de vérification de mot de passe, l’attaquant peut utiliser la faille XSS pour simplement modifier l’adresse e-mail des victimes par une adresse qu’il contrôle (voir exemple de payload ci-dessous). Ensuite, l’attaquant n’a plus qu’à utiliser la fonctionnalité de réinitialisation de mot de passe pour changer les mots de passe et ainsi voler les comptes des victimes.
fetch("/change-email/", {
method: "POST",
body: JSON.stringify({"new-email": "[email protected]"})
})Ce dernier scénario se distingue des exemples précédents, car la victime perd l’accès à son compte dès que son identifiant est modifié.
Divulgation d’identifiants par l’API
Il est fréquent que les API utilisées par certaines applications web soient mal configurées et divulguent des informations sensibles telles que des variables d’environnement ou des données personnelles d’autres utilisateurs.
Lors de nos pentests, il arrive que les routes permettant de lister les autres utilisateurs de la plateforme soient affectées; offrant ainsi la possibilité de voler n’importe quel compte grâce à la fonctionnalité de réinitialisation de mot de passe.
Prenons l’exemple d’un site d’e-commerce où les utilisateurs peuvent laisser des avis publics sur les articles. Lorsqu’un utilisateur consulte la page d’un article, des requêtes sont envoyées à l’API pour obtenir des informations sur les autres utilisateurs ayant également laissé des avis, comme leur nom, prénom et photo de profil.
Une requête typique de ce genre de cas pourrait ressembler à cela :
GET /comment/1 HTTP/1.1
Host: not-vulnerable-site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: */*Réponse :
HTTP/1.1 200 OK
Content-Length: 633
Content-Type: application/json
[...TRUNCATED DATA...]
{
“content”: “Great article !”,
“user”: {
“name”: “foo”,
“lastname”: “bar”,
“profile_picture”: “http://...”
}
}Dans la réponse ci-dessus, seules les informations nécessaires de l’objet user sont retournées. Mais dans les cas symptomatiques que nous rencontrons, l’API est mal configurée et retourne l’ensemble des champs de la table répertoriant les utilisateurs en base de données.
Requête :
GET /comment/1 HTTP/1.1
Host: vulnerable-site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: */*Réponse :
HTTP/1.1 200 OK
Content-Length: 633
Content-Type: application/json
[...TRUNCATED DATA...]
{
“content”: “Great article !”,
“user”: {
“id”: 10
"createdAt":"2024-07-08T08:19:40.037Z",
“name”: “foo”,
“lastname”: “bar”,
“email”: “[email protected]”,
“phone”: “0101010101”,
“password”: “$2y$15$KCZKk3HhrnXA0KJKwT3dUuI27mjoq7/Zl0jDFwdFCYM4GH5Obrfli”,
“token_reset”: null,
“profile_picture”: “http://...”
}
}On voit ici rapidement que beaucoup d’informations inutiles à la situation sont retournées; en particulier les champs email, phone et password ne devraient pas être transmis à tous les utilisateurs.
Cependant, la donnée la plus dangereuse ici est le champ token_reset. En effet, il s’agit du champ contenant le code aléatoire qui est envoyé à un utilisateur lorsque celui a oublié son mot de passe.
Ainsi, il suffit d’initier une requête de réinitialisation de mot de passe pour l’e-mail du compte ciblé. En revenant ensuite à la page de l’article initial et en observant la requête effectuée pour récupérer les informations de l’utilisateur ciblé, on constate que reset_token a été généré et nous est retourné.
HTTP/1.1 200 OK
Content-Length: 633
Content-Type: application/json
[...TRUNCATED DATA...]
{
“content”: “Great article !”,
“user”: {
“id”: 10
"createdAt":"2024-07-08T08:19:40.037Z",
“name”: “foo”,
“lastname”: “bar”,
“email”: “[email protected]”,
“phone”: “0101010101”,
“password”: “$2y$15$KCZKk3HhrnXA0KJKwT3dUuI27mjoq7/Zl0jDFwdFCYM4GH5Obrfli”,
“token_reset”: “e1a59e94-5c9b-4f32-ad05-4a29858dd65e”,
“profile_picture”: “http://...”
}
}Enfin, il est possible de poursuivre la procédure de réinitialisation de mot de passe comme si l’on avait légitimement reçu l’e-mail et cliqué sur le lien suivant : https://vulnerable-site.com/reset-password?token= e1a59e94-5c9b-4f32-ad05-4a29858dd65e.
Cet exemple illustre un cas d’exploitation de réinitialisation de mot de passe, mais il existe d’autres techniques. Notre article sur la réinitialisation de mots de passe examine en détail ces aspects ainsi que les mesures de sécurité à mettre en œuvre.
Comment prévenir le vol de comptes ?
Diverses mesures de protection peuvent être mises en place à différents niveaux d’une application web pour se protéger contre les risques de vol de comptes : au niveau de l’utilisateur lui-même, au niveau de la configuration globale du serveur web utilisé, et enfin au niveau des fonctionnalités et du fonctionnement interne de l’application.
Instaurer une politique de mots de passe robustes
Du point de vue de l’utilisateur, lorsqu’il s’agit d’utiliser des mots de passe, il est essentiel de mettre en place des politiques de « mot de passe fort » afin de garantir que les utilisateurs choisissent des mots de passe suffisamment robustes.
L’objectif principal lors de l’implémentation de ce type de politique devrait être de promouvoir l’utilisation de mots de passe longs (au minimum 15 caractères, sans limite de taille). Cela aide à protéger ces informations contre les risques de brute force sur leurs identifiants.
Implémenter un Rate Limiting
Ensuite, il est crucial de configurer correctement le serveur web et les frameworks utilisés. Les routes sensibles telles que celles de connexion ou de réinitialisation de mot de passe doivent être soumises à un mécanisme de rate limiting pour prévenir les attaques brute force.
Les cookies ou jetons d’authentification doivent avoir une durée de validité limitée et être déclarés comme HttpOnly (dans le cas des cookies). Cela réduit les risques d’exfiltration de sessions via des stealers ou des failles XSS.
Sécuriser les applications et APIs
Enfin, le point le plus crucial concerne la sécurité de l’application elle-même. Les recommandations spécifiques dépendent des langages utilisés et des fonctionnalités. Il est donc difficile de définir des directives précises, mais il est essentiel de veiller à ce que les processus de connexion et de réinitialisation de mot de passe ne puissent en aucun cas être contournés ou exploités.
De même, les champs sensibles liés à l’authentification (email, mot de passe, token de réinitialisation, etc.) doivent être rigoureusement contrôlés pour éviter toute divulgation accidentelle.
En général, les failles de sécurité résultent souvent de problèmes liés à la configuration ou à l’interaction avec les backends utilisés pour la gestion des comptes. Il est donc essentiel de garder à l’esprit les bonnes pratiques de sécurité relatives aux APIs tout au long des phases de développement.
Auteur : Maël BRZUSZEK – Pentester @Vaadata