Contournement de la double authentification
Table des matières
Cela fait un petit moment que je n'ai pas parlé de sécurité ici, et plus particulièrement de double authentification. Début octobre 2022, j'ai vu passer sur LinkedIn un post de Florent Curtet avec une image très intéressante.
Une belle liste des méthodes de contournement de l'authentification à 2 facteurs (2FA) :
Le but de ce blogpost est de tester toutes ces techniques sur le logiciel TodoList. Je vous avais présenté une façon d'ajouter la double authentification avec Symfony 4 et une autre en utilisant le nouveau module de sécurité de Symfony 5.
Sans plus attendre, voyons les attaques possibles, si elles sont efficaces sur le logiciel TodoList et comment les éviter ou les contourner.
Clickjacking on 2FA disabled feature
Le détournement de clic, ou clickjacking, est une technique malveillante visant à pousser un internaute à fournir des informations confidentielles ou à prendre le contrôle de son ordinateur en le poussant à cliquer sur des pages apparemment sûres. Wikipedia
Ce contournement sera difficile à tester sur TodoList car la fonctionnalité d'activation ou de désactivation de la double authentification n'est pas présente. Cependant, pour désactiver ou activer une fonctionnalité de sécurité, il est nécessaire de valider l'action par la saisie du mot de passe de l'utilisateur.
Dans le cas de TodoList, le code est envoyé par courriel. Il conviendrait donc de valider l'adresse courriel pour être sûr qu'elle est valide. Puis lors de l'activation ou la désactivation de la double authentification, demander le mot de passe de l'utilisateur.
Attention, il serait imprudent de laisser la possibilité à l'utilisateur de changer son adresse courriel sans la valider et confirmer le changement par la saisie et la validation du mot de passe. Une telle possibilité serait un autre moyen de contournement en utilisant la technique du clickjacking. Je parlerais d'un contournement lié à l'adresse courriel plus bas.
Absence de token CSRF pour désactiver le 2FA
CSRF : cross-site request forgery. L'attaquant envoie un lien réalisant une action (généralement dangereuse) qu'il ne peut pas faire à une personne ayant les autorisations adéquates.
Cette faille est courante sur d'autres fonctionnalités risquées et rejoint la précédente. En plus de valider l'action par la saisie et la validation du mot de passe de l'utilisateur, il est nécessaire d'utiliser un token CSRF. Ça doit être le cas pour toutes les actions dangereuses. Pour toute action dangereuse (comme la désactivation du 2FA) l'utilisation du verbe HTTP POST pour l'envoi de la requête au serveur est très fortement recommandée.
En cas d'absence du token CSRF, il est donc possible de forger une URL pour désactiver la 2FA sur le compte de la cible et cacher ce lien dans l'URL d'une image ou dans un lien envoyé par courriel à la cible.
En ce qui concerne TodoList, la faille est absente car il n'est pas possible de désactiver la double authentification. Trouverai-je une faille dans cette application de démonstration ?
Manipulation de la réponse
J'ai regroupé deux techniques de contournement car elle nécessite toutes les deux l'utilisation d'un proxy sur la connexion entre le navigateur (ou l'application) et le serveur. Ce genre d'attaque est courante sur les smartphones ou dans les réseaux ouverts (WiFi). Méfiance donc lors de l'utilisation du WiFi.
L'application TodoList n'est pas sujette à ce type d'attaque car c'est le serveur qui redirige l'utilisateur une fois le code correctement validé.
Manipulation du contenu de la réponse
La première manipulation serait de modifier le contenu de la réponse retournée par le serveur après la vérification du code. Typiquement, le site envoie le code saisie par l'utilisateur au serveur pour vérification. Le serveur envoie une réponse indiquant si le code est accepté ou non.
Une contre mesure de cette attaque consiste en la signature du contenu de la réponse par le serveur. Javascript pourrait ainsi détecter la corruption de la réponse. Cependant, la clé de signature doit être échangée de façon sécurisée (avec Diffie-Hellman) pour éviter qu'elle ne soit interceptée et remplacée par une clé maîtrisée par l'attaquant.
Manipulation du code HTTP de la réponse
La seconde attaque possible consiste à modifier le code retour HTTP de la réponse. Cette faille s'appuis sur une mauvaise gestion des codes retour.
Abandonner la connexion est la contre mesure la plus simple à un code HTTP autre que 200 durant la phase de connexion. Pour les applications natives, le suivi des redirections est désactivé sur les requêtes de validation du mot de passe et de validation du code 2FA. Le but étant d'éviter une redirection sur un serveur externe à l'application.
Récupérer le code dans la réponse du serveur
Celle-là est facile, même trop facile car elle est exploitable dans tout navigateur pour une application Web. Envoyer le code de vérification 2FA au navigateur ou à l'application native revient à corrompre le code instantanément.
La contre mesure est simple : seuls les serveurs doivent connaître le code et seuls les serveurs doivent le vérifier.
Réutilisation d'un code
On arrive ici dans un autre groupe de contournement, cette fois centré sur le code 2FA en lui-même. TodoList n'est pas sensible à cette attaque car le code est généré aléatoirement pour chaque utilisateur. La probabilité que deux utilisateurs aient le même code en même temps est de 4^9 !
Mais voyons un peu ces contournements.
Code déjà utilisé encore valide
Le premier est simple, utiliser le code reçu lors de la dernière connexion. Parfois ça pourait être pratique quand le code n'arrive pas ! Mais la sécurité ne sert plus à rien dans ce cas...
La contre mesure est de limiter le code généré à un utilisateur, le supprimer une fois utilisé et limiter sa validité dans le temps.
Utilisation du code 2FA d'un autre utilisateur
Cette technique nécessite d'avoir un compte pour l'attaquant. La faille consiste à utiliser le code reçu par l'attaquant sur le compte de la cible. Si cela fonctionne, il y a un gros problème de sécurité. Il n'y a qu'un seul code pour tous les utilisateurs qui se connecte au même moment ?
La contre mesure me paraît évidente : l'utilisation d'un code par session d'utilisateur souhaitant se connecter.
L'activation de la 2FA ne ferme pas les sessions existantes
L'application TodoList est vraiment très sécurisée, ce contournement n'est pas possible car la 2FA est activé par défaut et ne peut pas être désactivée.
Pour votre site, il est nécessaire de conserver un lien entre les sessions et l'utilisateur. Le but étant de fermer les sessions lors de l'activation de la 2FA. Dans le cas contraire, un attaquant déjà connecté à votre compte ne serait pas impacté par l'activation de la double authentification. Elle serait efficace uniquement pour les nouvelles connexions ce qui est évidemment insuffisant.
Contourner le code avec le Referer
Quand j'ai vu ce contournement, j'ai d'abord cru à une blague. Mais non, la vérification de l'entête de requête Referer est encore utilisée.
Cette entête contient l'URL de la page d'origine de la requête. Les navigateurs l'envoie de moins en moins souvent rendant son utilité désuète. Le principal problème est qu'il est très facile de le modifier.
Se baser dessus pour vérifier que le visiteur provient bien de la page de 2FA revient à ne rien vérifier du tout.
La contre mesure à ce contournement est de vérifier le code 2FA et tagguer la session comme complètement authentifié côté serveur en cas de succès.
Analyse des fichiers JS
Ce contournement concerne les applications JavaScript exécutées dans le navigateur. L'analyse du code source permet parfois de comprendre plus précisément comment fonctionne la double authentification et ainsi la contourner plus facilement.
La contre mesure consiste à ne pas utiliser l'application JavaScript pour la connexion de l'utilisateur et la double authentification. Tout ce qui est envoyé au navigateur peut subir des modifications. L'application se charge après la connexion complète de l'utilisateur avec un token d'authentification.
Dans le cas où vous utilisez du code JavaScript pour l'authentification, l'application ne doit pas fonctionner tant qu'elle n'a pas reçu de token valide de la part du serveur. Toutes les vérifications liées à l'authentification doivent être réalisées par le serveur.
Brute force du code
Est-il possible de parler de sécurité sans parler de brute-force ?
Un code à 4 chiffres peut être brisé en quelques minutes (je compte le temps de traitement de chaque code) si aucune limite n'existe côté serveur.
La contre mesure consiste à limiter à 3 essais pour un code à 4 chiffres avant d'envoyer un nouveau code. Plus le code est grand et utilise des caractères différents plus le nombre d'essais peut augmenter. Dans tous les cas, il est nécessaire de limiter le nombre de tentatives (par code, par session, par IP).
Désactivation du 2FA au changement de mot de passe
J'en parlais à demi-mot au début de ce blogpost. Le changement de mot de passe ou d'adresse courriel ne doit pas désactiver le 2FA.
La contre mesure pour le changement de mot de passe est évidente. Après la modification du mot de passe, l'utilisateur doit se reconnecter et toutes les sessions ouvertes doivent être fermées (ça inclut également les cookies "Remember me").
Pour le changement d'adresse courriel, la contre mesure consiste à ne changer l'adresse qu'une fois celle-ci confirmée.
Accès direct à une page protégée
Je n'ai pas été surpris de voir ce contournement, c'est une faille très courante. C'est même LA faille N°1 du top 10 de l'OWASP. L'appel direct de l'URL d'une page réservée aux utilisateurs connectés accessible sans connexion...
La contre mesure à ce contournement est de considérer l'utilisateur comme connecté après la validation du code 2FA. Comme montré sur l'application TodoList.
Les codes de secours
Les codes de secours sont utilisés temporairement lors de difficultés de connexion avec le protocole 2FA habituel. Ces codes de secours sont générés lors de la mise en place de la double authentification sur le compte de l'utilisateur.
Il est possible d'appliquer les attaques vues plus haut aux codes de secours. La contre mesure est de générer des codes à usage unique pour chaque utilisateur et de les considérer comme des mots de passe à usage unique. Selon le nombre de caractères de chaque code, le nombre de tentatives de saisie sera plus ou moins élevé.
Conclusion
L'application TodoList a peu de surface d'attaque pour le contournement de la double authentification. Cela provient globalement de l'effet "démo" de l'application. Elle ne dispose que d'une partie des fonctionnalités liées à la double authentification. Cela me donne donc de nouvelles excuses pour en parler dans de prochains blogpost à commencer par la mise en place de la 2FA.
Les contournements énumérés dans ce blogpost peuvent être présents sur vos applications, vérifiez-les ! Je reste disponible pour plus d'informations, pour toutes questions où si vous avez besoin d'aide.
Consultant Expert Web, j'aide les entreprises ayant des difficultés avec leur projet Web (PHP, Symfony, Sylius).
@jbnahan69 | Macintoshplus | Linkedin | JB Dev Labs