Comprenez la notion d'authentification
Avant de parler vulnérabilités, un petit rappel sur ce qu’est l’authentification (à ne pas confondre avec l’habilitation, ou "authorization", en anglais, que nous verrons dans le prochain chapitre).
L’authentification, c’est le fait de vérifier que quelqu’un est bien celui qu’il prétend être. On parle d’authentification à partir du moment où un facteur secret entre en jeu (comme un mot de passe). Sinon, on parle d’identification.
L'habilitation, c’est le fait de vérifier que quelqu’un a bien le droit de faire ce qu’il demande.
Bien, maintenant rentrons dans le vif du sujet : tester les mécanismes d’authentification !
Quand on s'intéresse aux problèmes qui peuvent impacter la cinématique d’authentification, on va généralement parler de différents types :
les bypass d’authentification : faire en sorte d’accéder à une ressource sans avoir besoin de s’authentifier ;
le credential guessing : deviner un couple identifiant - mot de passe valable ;
le vol de sessions : utiliser la session valide d'un utilisateur donnée pour bénéficier de ses accès et réaliser des actions en son nom.
Bypassez l’authentification
Je ne vais pas trop m’étendre sur le sujet des bypass d'authentification car, en un sens, nous avons déjà vus au travers des injections. Mais à votre avis, que se passe-t-il si la mire d’authentification que nous testons possède une injection SQL ?
Il y aura potentiellement un bypass de l’authentification. La base de données peut également être récupérée avec les hashs des mots de passe, que nous pouvons ensuite tenter de casser pour retrouver le mot de passe en clair.
Trouvez un mot de passe avec le credential guessing
Nous allons voir cette technique un peu plus en détail, car c’est souvent là que se trouvent les problèmes.
À partir de quel moment pouvons-nous considérer que l’authentification est vulnérable ou insuffisamment robuste ?
Tout va dépendre de l’information qu’il y a à protéger à l'intérieur. De plus, les standards évoluent : aujourd’hui une authentification qui ne requiert pas un multifacteur (au moins deux facteurs d’authentification) est considérée comme trop faible pour certains besoins.
Mais revenons à votre question sur la vulnérabilité de l’authentification. Pour une application classique, on considère que l’authentification n’est pas suffisamment sécurisée à partir du moment où :
elle nous permet (théoriquement) de tester un nombre non limité de combinaisons de ce que l’on pourrait appeler des ”authentifiants” ;
et qu’en plus la politique de mot de passe en place est faible ou inexistante.
Voilà pour l’approche théorique, mais c’est quand même mieux si on prouve que l’authentification est faible. C’est le graal si en plus on trouve des identifiants valides, d’autant plus s’il s’agit de ceux d’un compte administrateur !
Pour attaquer efficacement une mire d’authentification, nous avons besoin de :
ne pas être bloqué en cas d'échec répété, que ce soit au niveau du compte ou de l’IP d’attaque (bien que le blocage d’IP soit contournable avec un peu de moyens) ;
connaître la politique de mots de passe en place ;
posséder une liste d’identifiants valides ou probables ;
posséder une liste de mots de passe probables ;
être en capacité d’automatiser l’attaque, donc d’avoir un outil adapté (ou alors il faut taper très vite sur son clavier).
Pour mettre tout cela en musique, procédons par étapes :
déterminer si des mécanismes de blocage sont déclenchés en cas de nombreuses tentatives d'authentification infructueuses ;
vérifier la robustesse de la politique de mot de passe ;
identifiez l'existence de comptes utilisateurs valides ;
essayer d'obtenir le mot de passe.
Étape 1 : déterminez si des mécanismes de blocage sont en place
C’est le premier point qu’on vérifie : est-ce qu'il y a un blocage, temporaire ou définitif, du compte utilisé ou d'un autre élément utilisé dans le cadre de l’attaque, comme l’adresse IP ?
Si vous bloquez votre compte, il pourra être difficile de continuer les tests sans le débloquer… et ça peut prendre du temps (jusqu’à plusieurs heures, parfois).
C’est pour cela que, dans le cadre d’un test d’intrusion, on demande généralement deux comptes de même “niveau de privilèges” pour accéder aux mêmes choses au sein de l’application. Cela permet de tester l’authentification et la présence de mécanismes de blocage sans couper la branche sur laquelle on est assis.
Le second point à vérifier est la politique de mot de passe.
Étape 2 : vérifiez la robustesse de la politique de mot de passe
Existe-t-il une politique de mot de passe (nombre minimum de caractère, obligation d'intégrer un caractère spécial, ou encore de varier majuscules ou minuscules) ? Et si oui, est-elle robuste ?
Car ça ne sert en effet à rien de tester des mots de passe faibles si la politique de mot de passe impose 10 caractères avec complexité (chiffres, lettres, majuscules et caractères spéciaux). Pour vérifier cela, vous pouvez par exemple tenter de réinitialiser le mot de passe d’un des comptes qu’on vous a fournis, en saisissant des valeurs simples.
Le troisième point à vérifier est le suivant : sommes-nous en capacité d’identifier l'existence de comptes valides ou non ?
Étape 3 : Identifiez l'existence de comptes valides
Vous savez, cette fonctionnalité faite pour les utilisateurs qui oublient leurs identifiants, où la mire d’authentification répond de manière différenciée selon que le compte existe ou qu’il n’existe pas ? Je parle de celle-ci, qui nous permet, en tant qu’attaquants, de construire une liste d'identifiants (adresse mail, pseudo ou autre) valides. Ça fait déjà un des deux éléments nécessaires pour s'authentifier, connu !
Le quatrième point à obtenir est le plus dur, car il est censé être secret : le mot de passe.
Étape 4 : essayez d'obtenir le mot de passe
Il faut mettre à profit toutes les sources de données et toutes les informations que nous avons :
pour chaque login valide identifié (si identifié), il est nécessaire de tester les mots de passe par défaut ou simples. Vous pourrez par exemple trouver des exemples de listes sur des répertoires comme SecLists ;
si vous avez identifié des identifiants qui sont des adresses mail ou qui sont liés à des adresses mail, recherchez dans les bases de données fuitées si le mail est présent et si vous pouvez récupérer le mot de passe associé. Assurez-vous de le tester ainsi que des variations proches si vous détectez un schéma dans le mot de passe ;
ensuite, si vous connaissez des informations sur une cible précise, il existe des outils comme cupp qui permettent de “profiler” une cible et créer une liste de mots de passe probables ;
ensuite, vous pouvez tester des listes de mots de passe fuités, comme la bien connue rockyou, ou richelieu, qui sont dans SecLists. Ou encore tenter la bruteforce sur l’authentification, mais c’est généralement peu utile voire inutile, étant donné la lenteur des attaques dites “en ligne”.
Je viens de mentionner les attaques “en ligne” qui sont à mettre en opposition aux attaques “hors ligne”.
Les attaques hors ligne sont infiniment plus rapides que les attaques en ligne, car elles ne prennent pas de temps de transport réseau, et le matériel utilisé pour le cassage est bien souvent spécifiquement fait pour ça.
Pour les attaques en ligne, il existe plein d’outils. Personnellement j’utilise ffuf, et c’est ce que je vous invite à faire de suite au travers du challenge à venir.
Allez, je vous montre d'abord en vidéo :
À vous de jouer
Challenge
On va se former au test de la robustesse de l’authentification par le biais d’un petit challenge, avant de passer sur notre application.
Saurez-vous résoudre le challenge Mot de passe faible ?
Solution
Comme vous commencez à en avoir l'habitude : on ne vous donne pas la réponse directement mais la vidéo de démonstration plus haut devrait vous aider.
Pas de solution donc, mais un indice tout de même : rappelez-vous qu’il faut ajouter certaines options pour que Root Me ne bloque pas nos outils ! Dans le cas de ffuf, ce sont les suivantes :
-t 7 -rate 70 -H “User-Agent: Firefox”
Détournez les sessions et cookies des utilisateurs
Les cookies, c’est une des manières de persister la session et de maintenir l’authentification dans les applications web. Si un attaquant vole votre cookie de session, il n’a même pas besoin de se fatiguer à essayer de trouver votre mot de passe, il aura accès à l’application de la même manière que s’il l’avait trouvé !
Globalement, un cookie peut être :
forgé ;
volé ;
utilisé à votre insu, dans le cadre d’attaques CSRF (cross site request forgery).
Un cookie forgé
Un cookie peut être forgé si l’attaquant réussit à comprendre comment le cookie est créé par l’application. Cela arrive rarement de nos jours, car tous les langages de développement fournissent la couche de persistance de session, et il n’est plus nécessaire de l’implémenter. Ce qui limite considérablement les erreurs. Mais de temps en temps, on tombe sur un cookie qui sort de l’ordinaire ; à ce moment-là, il vous faudra vous y intéresser de plus près !
Un cookie volé
Un cookie possède des attributs ou "flags", notamment les attributs “secure” et “HttpOnly”. Sans ces attributs, un attaquant peut être en mesure de voler le cookie d’un utilisateur légitime au travers d’une XSS si le flag “HttpOnly” n’est pas positionné, et en interceptant des flux non chiffrés si le flag “secure” n'est pas positionné.
Un cookie utilisé à votre insu
Le fonctionnement des cookies est mis à profit par les attaques CSRF. Ces attaques sont un peu compliquées dans leur cinématique, je vais donc essayer d’être le plus clair possible :
D'une part, ces attaques ne sont pertinentes que sur des requêtes de modification de contenu, ou qui ont un impact sur l’application.
D'autre part, elles se basent sur un fonctionnement “normal” des cookies, qu’il faut bien avoir en tête. Pour cela, revenons un instant sur le fonctionnement d’un cookie.
Les cookies permettent de persister la session d’un utilisateur, et sont stockés sur le poste de l’utilisateur dans des petits fichiers texte. Ils sont envoyés automatiquement par le navigateur au site web quand l’utilisateur navigue sur le site internet auquel ils appartiennent. C’est le fonctionnement normal des navigateurs avec les cookies.
Revenons maintenant sur le principe des attaques CSRF. Il s'agit :
de “forger” une requête (créer une requête valide avec tous les bons éléments),
et d’utiliser ce mécanisme pour piéger un utilisateur et lui faire faire des actions à son insu.
Prenons un exemple. L’application example.com que nous testons permet de :
modifier son mot de passe ;
sans entrer l’ancien mot de passe, ni aucun paramètre qui ne soit pas prédictible par un attaquant.
C’est le point le plus important : il faut que tous les paramètres de la requête soient prédictibles par l’attaquant, pour que ce dernier puisse forger la requête et la faire exécuter par la victime.
Si l’application n’est pas protégée contre les attaques CSRF, l’attaquant a juste à faire en sorte que la victime envoie la requête forgée au serveur web.
Pour cela, il peut par exemple envoyer un lien contenant tous les arguments nécessaires à la victime, et faire en sorte que celle-ci clique dessus pour exécuter la requête et déclencher l’attaque ! Il peut aussi insérer les requêtes dans des balises <img> pour qu’elles s’exécutent automatiquement, quand le navigateur voudra afficher ce qu’il pensera à tort être une image. Ici, changer le mot de passe de l’utilisateur en question.
En résumé
L’authentification est le fait de s’assurer que quelqu’un est bien celui qu’il prétend être. Sur les applications web, cela revient à demander à l'utilisateur des secrets qu’il est normalement le seul à connaître, avec notamment le couple identifiant - mot de passe.
L’authentification est primordiale pour la plupart des applications web. Des erreurs ou des oublis se glissent parfois sur ces fonctionnalités. Ce qui permet à un attaquant d’accéder à la partie authentifiée de l’application.
La mire d’authentification peut par exemple :
avoir une vulnérabilité dans le code, type injection SQL qui permet de bypasser l’authentification ;
ne pas être protégé contre les attaques par dictionnaire ou bruteforce ;
posséder des identifiants de test ou par défaut valides.
Les cookies, qui persistent la session d’un utilisateur, sont un point de sécurité à regarder, notamment les attributs “secure” et “HttpOnly” de ceux-ci.
Dans le prochain chapitre, nous allons nous attaquer aux problématiques liées au concept complémentaire de l'authentification : l'habilitation et le contrôle d'accès !
