Défaut d'identification et d'authentification : Top 10 OWASP #7

L’authentification et, par extension, l’identification d’un utilisateur sont des éléments centraux des applications web.

En effet, de ces deux mécanismes découlent la gestion des droits et des accès (par exemple entre un administrateur et un utilisateur standard), le cloisonnement des données entre différents comptes, la possibilité d’identifier différents utilisateurs, etc.

En bref, l’authentification est cruciale et sa compromission peut avoir des impacts critiques sur l’application : vol de compte, vol des données, imitation d’un compte tiers, voire compromission totale de la plateforme en cas de vol d’un compte administrateur.

Dans cet article, nous explorerons les vulnérabilités liées au défaut d’identification et d’authentification à travers le prisme de l’OWASP. En partant de scénarios d’attaques, nous détaillerons les exploitations courantes ainsi que les bonnes pratiques pour se prémunir.

Quelles sont les méthodes d’authentification les plus courantes ?

L’objectif d’un système d’authentification est d’identifier un utilisateur et de s’assurer que ce dernier est bien celui qu’il prétend être. De fait, tous les systèmes d’authentification reposent sur au moins un de ces 4 facteurs :

  • Ce que l’on sait (facteur de connaissance), une information que seul l’utilisateur connait, par exemple un mot de passe.
  • Un facteur physique : un objet uniquement en possession de l’utilisateur, par exemple une carte d’accès.
  • Un facteur biologique, par exemple une empreinte digitale.
  • Ou ce que l’on sait faire (un facteur « singulier »), une action que seul l’utilisateur sait faire, par exemple une signature.

Chacun de ces systèmes a des avantages et des inconvénients, mais seuls les 3 premiers critères sont raisonnablement utilisés aujourd’hui en informatique pour identifier un utilisateur et, de ces 3, le premier domine massivement avec la fameuse combinaison « nom d’utilisateur – mot de passe ». Nous allons donc nous focaliser sur celui-ci.

Plus récemment, cette combinaison s’est vue renforcée par le 2FA (Two-factor authentication, ou authentification à deux facteurs). Ce type de mécanisme requiert, en plus du mot de passe, un code reçu via un second canal, généralement par email ou par téléphone. Cela permet d’assurer que même en cas de compromission du mot de passe, un acteur malveillant ne puisse pas se connecter sur la plateforme.

Malheureusement, aucun système d’authentification n’est infaillible. En effet, des problèmes d’implémentation ou de configuration peuvent permettre à un attaquant de le contourner et/ou d’en abuser.

Dans cet article, nous n’expliciterons pas toutes les attaques possibles sur l’authentification. Nous nous focaliserons sur les plus courantes.

Quelles sont les attaques et exploitations courantes sur les systèmes d’authentification ?

Le cas le plus évident et le plus connu : tenter des mots de passe différents jusqu’à trouver le bon via brute force. Il peut également être utilisé pour contourner certains types de 2FA, par exemple si un code à 4 ou 5 chiffres est demandé.

Cette attaque est facile à détecter et à contrer. En effet, il suffit de mettre en place une limite de tentative de connexion (rate limiting) ou d’implémenter un délai entre chaque tentative de connexion.

Une autre mesure de protection consiste à instaurer une politique de mots de passe robustes.

Pour en savoir plus sur les attaques brute force, nous vous invitons à consulter notre article dédié : Attaques brute force : principes et bonnes pratiques sécurité.

Une fonctionnalité récurrente dans les systèmes d’authentification est la réinitialisation de mot de passe, notamment en cas d’oubli de celui-ci.

Elle fonctionne généralement comme ceci :

  • L’utilisateur saisit son identifiant (généralement son adresse email)
  • Un email contenant un lien de réinitialisation lui est envoyé.
  • En suivant ce lien, l’utilisateur est redirigé vers un formulaire qui lui permet de saisir un nouveau mot de passe.

Une vulnérabilité souvent repérée lors de ce processus vient de la génération du lien en lui-même. En effet, un attaquant ayant accès à ce lien peut changer le mot de passe d’un compte ne lui appartenant pas et ainsi voler le compte.

Exemple d’exploitation

Prenons par exemple le lien suivant, reçu lorsque nous faisons une tentative de réinitialisation de mot de passe de l’utilisateur « [email protected] » sur un site de test :

https://test.vaadata.com/passwordreset/ZHVtbXkxQHRlc3QtdmFhZGF0YS5mcg==

Il semble que la partie ZHVtbXkxQHRlc3QtdmFhZGF0YS5mcg== soit l’identifiant qui permet de connaitre le compte concerné par la réinitialisation de mot de passe.

Lorsque nous faisons une seconde demande de réinitialisation avec le même email, quelque chose d’intéressant se passe :

Premier email suite envoi demande de réinitialisation de mot de passe
Second email suite envoi demande de réinitialisation de mot de passe

Nous recevons la même URL, ce qui est mauvais signe, car cela signifie que le code n’est pas généré aléatoirement.

Si nous tentons de décoder en base64 l’id en question, nous obtenons : « [email protected] »

Au vu des comportements observés, il semblerait que la réinitialisation de mot de passe se base uniquement sur l’email encodé en base64 pour identifier le compte qui fait la demande, ce qui devrait nous permettre, en remplaçant cet id par celui d’un compte que nous ne possédons pas, de voler ledit compte.

Essayons avec « [email protected] », qui devient ZHVtbXkyQHRlc3QtdmFhZGF0YS5mcg== en base64.

Bingo ! Avec cela, nous pouvons voler n’importe quel compte, du moment que nous connaissons son email.

Comment prévenir ce type d’exploitation ?

Pour se protéger de ce type d’attaque, le jeton de réinitialisation doit être :

  • Aléatoire, comme un UUID par exemple.
  • Limité dans le temps, donc valide qu’une heure ou deux maximum
  • Invalidé après son utilisation, pour s’assurer qu’en cas de fuite, il ne puisse pas être réutilisé par un attaquant
  • Invalidé lorsqu’une nouvelle demande de réinitialisation (concernant le même utilisateur) est faite, afin d’éviter qu’un attaquant génère plusieurs jetons, ce qui lui faciliterait la tâche pour en « deviner » un.

Pour en savoir plus sur ce type d’exploitation, vous pouvez consulter notre article : Réinitialisation de mots de passe : exploitations et bonnes pratiques sécurité.

Le SSO (ou Single Sign-On, authentification unique) est une méthode qui permet de centraliser l’authentification sur un seul serveur et qui permet, avec un seul compte, d’accéder à plusieurs services/applications. L’exemple le plus connu est sans doute Google qui, via un seul formulaire d’authentification, vous génère un jeton de session qui donne accès à tous ses services (gmail, gmap, gdrive, etc.).

C’est également un système très prisé dans les grandes entreprises, car cela permet de faciliter massivement la gestion des employés/utilisateurs en centralisant le tout dans un seul système.

Voyons déjà comment fonctionne, dans les grandes lignes, un système SSO :

Du fait de sa popularité, de nombreuses applications proposent maintenant à leurs clients de relier leur SSO d’entreprise à l’application. Cependant, si cela n’est pas implémenté correctement, cela peut permettre à un attaquant de compromettre complètement tout le système d’authentification.

En effet, si un acteur malveillant est autorisé à relier son propre SSO, il peut configurer celui-ci pour, lors de la réponse « SSO->application » post login SSO, autoriser l’utilisateur à se connecter avec un utilisateur ne faisant pas partie du SSO et sur lequel l’acteur malicieux ne devrait avoir aucun droit :

Si l’application ne vérifie pas que le jeton retourné par le serveur SSO est valide et concerne bien un compte sous la juridiction dudit SSO, un attaquant peut se connecter avec un compte ne lui appartenant pas.

De manière générale, toute donnée provenant de SSO externes doit être considérée comme potentiellement manipulée et doit donc être vérifiée attentivement.

Ce cas-ci est techniquement peu compliqué, mais représente pourtant un véritable défi : tout le monde réutilise son mot de passe. En effet, la complexité de ceux-ci augmente avec le temps, la faute à des ordinateurs de plus en plus puissants (et qui peuvent donc les craquer plus facilement). Le standard aujourd’hui (selon le National Institute of Technology) est un mot de passe de minimum 8 caractères, maximum 64, tout type de caractères autorisés, pas de lettres qui se répètent à la suite, etc.

Il est également fortement recommandé de ne pas mettre en place de rotation de mot de passe, car les utilisateurs ont tendance à mettre des variantes (motdepasse1, motdepasse2, motdepasse3…), ce qui n’augmente pas la sécurité, mais les pousse à mettre des mots de passe plus courts.

Une fois toutes ces conditions réunies, le mot de passe est généralement peu facile à retenir, ce qui pousse les utilisateurs à n’en avoir qu’un ou deux différents sur toutes leurs plateformes.

Or, certaines de ces plateformes finiront inévitablement par se faire pirater et leurs mots de passe se retrouveront en libre accès sur internet.

Rajouter à cela que de nombreux utilisateurs utilisent des mots de passe extrêmement simplistes et connus. En 2022 Google à sorti une étude montrant que 24% des Américains utilisent des variantes de abc123Password123456Iloveyou111111QwertyAdmin, et Welcome.

Mozilla a également publié un papier selon lequel 59% des utilisateurs utilisent leur nom ou date de naissance dans leurs mots de passe.

Tous ces facteurs réunis font qu’un attaquant, sans même attaquer le système d’authentification en tant que tel, a déjà de grandes chances de réussir à gagner un accès à une plateforme juste en tentant des mots de passe connus.

Pour pallier ceci, une première solution peut être la mise en place de 2FA. Ainsi, même si le mot de passe est connu, l’attaquant ne pourra pas gagner accès au compte.

De plus, pousser ses utilisateurs à utiliser des gestionnaires de mot de passe est un bon moyen de renforcer leur sécurité.

Conclusion

Dû à son rôle à la fois de porte d’entrée et de clé de voûte dans l’application, le système d’authentification est une cible tentante pour un acteur malveillant.

Heureusement, les vecteurs d’attaques le concernant sont clairement identifiés et il existe des standards qui, si suivis scrupuleusement, garantissent (autant que se peut, bien sûr) la sécurité des utilisateurs et de la plateforme.

Auteur : Renaud CAYOL – Pentester @Vaadata