Comment les pirates contournent la technologie moderne d’authentification à deux facteurs et comment protéger vos utilisateurs
Dans cet article, nous examinerons des exemples d’outils et de techniques que les pirates peuvent utiliser pour contourner les méthodes d’authentification à deux facteurs (2FA), qu’il s’agisse d’un mot de passe unique acheminé par SMS ou de notifications poussées envoyées vers une application mobile. La méthode permettant de contourner l’authentification à deux facteurs n’est pas qu’une attaque par force brute, et elle peut être très efficace contre la plupart des méthodes de 2FA utilisées de nos jours, y compris l’authentification hors bande. Un gestionnaire de mots de passe sera peu utile pour lutter contre ces attaques; nous discuterons donc des types de mesures de protection que les banques peuvent mettre en place pour atténuer les risques et protéger leurs clients contre les pirates et cybercriminels qui cherchent à exécuter des fraudes par prise de contrôle de comptes, à voler des renseignements sensibles, à déployer des rançongiciels ou à effectuer des attaques de « personne du milieu » (aussi appelées « attaques d’homme du milieu »).
Comprendre l’authentification à deux facteurs
L’authentification à deux facteurs (2FA) n’est pas qu’une couche de sécurité supplémentaire. Elle consiste en un processus d’authentification pour les comptes en ligne qui s’appuie sur deux facteurs. En revanche, l’authentification multifacteurs (AMF) comprend deux facteurs d’authentification ou plus. Ces facteurs incluent soit quelque chose que l’on possède (comme un mot de passe unique à six chiffres), quelque chose que l’on connaît (comme son mot de passe, ses identifiants ou les réponses à ses questions de sécurité) ou quelque chose que l’on « est » (comme des identifiants biométriques). Dans un processus type de code de vérification à deux étapes, un utilisateur entre ses identifiants de connexion habituels. Par la suite, l’application Web, l’application mobile ou l’outil envoie un code de vérification ou une clé de sécurité par message texte au numéro de téléphone de l’utilisateur. L’utilisateur entre ensuite ce code de 2FA dans la page de connexion, puis obtient l’accès à son compte d’utilisateur ou peut terminer le processus de récupération de son compte ou de réinitialisation de son mot de passe. Ces codes de vérification à deux étapes, codes de sécurité et codes de récupération peuvent aussi être envoyés par l’entremise d’une application d’authentification, d’un jeton d’authentification ou d’un autre système d’authentification.
Comment contourner la vérification par mot de passe unique : mise en place de l’attaque
Pour exécuter cette attaque de contournement de l’A2F, nous utiliserons une combinaison de deux outils : Muraena et Necrobrowser. Muraena est un outil mandataire inverse qui exécutera notre page d’hameçonnage par ingénierie sociale. Les sites et la page Web d’hameçonnage imiteront la page originale avec laquelle la victime interagira. Une fois que la victime aura authentifié sa session, Muraena transférera la session à Necrobrowser, qui permettra au pirate de prendre le contrôle de la session ou d’automatiser les prochaines étapes de l’attaque. Comme Muraena agit comme outil mandataire inverse, il n’y a aucune différence entre notre site malveillant et le site Web original, exception faite de l’adresse URL. Muraena peut être configuré pour utiliser des certificats SSL obtenus, par exemple, par l’entremise de LetsEncrypt. Du point de vue de la victime, l’expérience dans son ensemble semblera légitime, puisqu’elle donnera l’impression que la personne interagit avec la page officielle. La victime accomplira chacune des étapes du processus d’authentification normal, y compris la vérification à deux facteurs. Si la 2FA consiste en un code d’authentification unique envoyé par SMS, jeton matériel ou jeton logiciel, la victime l’entrera comme à l’habitude. Cependant, même les fonctionnalités de sécurité modernes comme les notifications poussées envoyées sur un appareil mobile ou la numérisation d’un code QR à l’écran seront contournées par cette attaque.
- L’utilisateur visite la page d’hameçonnage, où la fonctionnalité SSL a été activée.
- L’outil mandataire inverse (Muraena) récupère la page légitime de la banque et en affiche une copie à la victime.
- La victime de cette fraude essaie alors de se connecter à cette page, et le site procède à l’authentification à deux facteurs.
- Une fois que la victime a terminé le processus d’authentification, l’outil mandataire inverse (Muraena) transfère la session au pirate (Necrobrowser) pour qu’il prenne le contrôle et retire l’accès à la victime.
Dans l’image ci-dessous, vous pouvez voir Muraena qui héberge Google sur le domaine phish.anti. Aux fins de notre démonstration, j’ai mis sur pied un DNS local pour résoudre ce site sur mon ordinateur d’essai, et j’ai également délivré des certificats à l’aide de ma propre autorité de certification, à laquelle fait confiance le navigateur. Cependant, le résultat est exactement ce que la victime verrait si le tout était déployé sur votre propre domaine à l’aide de certificats valables.
Une cybersécurité qui protège contre l’attaque
Maintenant que nous comprenons comment l’attaque fonctionne, nous pouvons déterminer quelles stratégies et fonctionnalités de sécurité permettront de déceler ce type d’attaque avec succès et de protéger contre cette attaque.
La liaison dynamique offre une bonne première couche de défense contre diverses attaques. Elle consiste en une authentification à deux facteurs effectuée au moment de la transaction : elle intègre les détails de la transaction au processus de signature. Cette technologie est souvent appelée « Ce que vous voyez, c’est ce que vous signez », puisque les détails de la transaction seront présentés à l’utilisateur final avant que le processus de signature ne soit terminé. Une fois la signature apposée, elle sera uniquement valable pour cette transaction, ce qui la rend plus difficile à contourner pour un pirate. Habituellement, la liaison dynamique est mise en place à l’aide de jetons matériels ou logiciels ou intégrée à une application mobile. Nous présentons ci-dessous deux exemples de liaison dynamique : un premier démontrant un paiement légitime, et un second où un pirate tente de modifier le paiement.
- L’utilisateur crée une transaction dans les services bancaires en ligne.
- L’utilisateur soumet la transaction.
- La banque envoie les détails de la transaction au téléphone mobile de l’utilisateur.
- L’utilisateur vérifie les détails du transfert et autorise le paiement à l’aide d’un facteur biométrique (OU d’un autre deuxième facteur).
- L’application mobile génère un mot de passe unique à l’aide des détails de la transaction et de la clé de jeton qui se trouve dans l’application mobile.
- L’utilisateur tente de créer un paiement dans les services bancaires en ligne.
- Le pirate modifie le paiement pour qu’il soit envoyé au compte d’un autre bénéficiaire et/ou en change le montant.
- La banque envoie les détails de la transaction au téléphone mobile de l’utilisateur.
- L’utilisateur voit l’information de paiement modifiée et refuse le paiement.
Les exemples ci-dessus démontrent également l’importance d’utiliser un cryptage de bout en bout lors du déploiement d’une liaison dynamique. De plus, ils montrent que l’application mobile proprement dite doit être protégée, étant donné que le pirate pourrait tenter d’attaquer l’application mobile au point terminal pour masquer les détails de paiement modifiés afin que l’utilisateur ne puisse pas en prendre connaissance.
Une autre façon efficace de reconnaître une vaste gamme d’attaques et de se défendre contre celles-ci est de mettre en place une surveillance continue sur vos plateformes numériques en guise de niveau de sécurité supplémentaire. En surveillant la session du moment de son déclenchement jusqu’à la fin, nous pouvons obtenir plus de renseignements grâce aux gestes posés par les utilisateurs et aux appareils Microsoft Android et Apple iOS ou aux comptes auxquels ils sont associés. La surveillance continue s’harmonise parfaitement aux autres couches de sécurité comme l’authentification à deux facteurs ou la liaison dynamique, puisqu’elle permet à la banque d’obtenir également du contexte de la part de ces méthodes d’authentification.
La banque peut ensuite surveiller les indices habituels d’attaques connues, comme de nouveaux appareils, de nouveaux endroits, la présence d’un outil mandataire, etc. Ces renseignements peuvent être mis en corrélation avec la base d’utilisateurs de la banque afin de mieux comprendre les risques qui y sont associés. Nous pouvons ensuite tenir compte des gestes posés par l’utilisateur tout au long de la session et les comparer à ses comportements habituels. Cette approche définit un profil de risque en continu pendant la session, qui peut changer en fonction de chaque geste posé par l’utilisateur final. Non seulement cette technologie permet à la banque de prendre des mesures en temps réel lorsque des anomalies sont détectées, mais elle lui permet de réduire les irritants pendant les sessions légitimes en diminuant le nombre d’authentifications nécessaires.
Conclusion
Même si l’attaque de contournement de l’authentification à deux facteurs présentée dans cet article fait appel à des technologies et des concepts qui existent depuis belle lurette, nous constatons que le fait de les utiliser correctement peut tout de même se solder par une fraude qui connaît beaucoup de succès et qui contourne diverses méthodes d’authentification. Il est important pour les banques et les prestataires de services d’utiliser une approche multiniveaux, car la plupart des niveaux individuels de sécurité comportent des vulnérabilités qui peuvent encore faire l’objet d’attaques ou être exploitées. Lorsqu’elles mettent en place une liaison dynamique, les banques doivent s’assurer de créer un canal de communication sécurisé avec l’utilisateur final. Par exemple, il a été démontré qu’il n’est pas fiable de s’appuyer sur la vérification par SMS, car les messages peuvent être volés, imités ou interceptés par le pirate. Cependant, lorsqu’elles mettent en place des applications mobiles, les banques doivent aussi savoir que ces applications deviennent une cible, et elles doivent protéger leurs applications mobiles contre les attaques externes. Cet article a principalement pour but de démontrer que les attaques par hameçonnage peuvent être modernisées pour contourner l’authentification à deux facteurs lors de l’ouverture de session et que l’utilisation de ce type d’authentification ne permet pas à elle seule de protéger complètement contre l’hameçonnage. Enfin, nous avons mentionné quelques-unes des couches de sécurité que les banques peuvent utiliser pour offrir plus de protection à leurs utilisateurs finaux, et indiqué quelques-uns des pièces à éviter dans le cadre de ce processus. En résumé :
- Mettez en place une liaison dynamique avec un cryptage de bout en bout.
- Déployez une analyse du côté serveur pour surveiller les sessions, les appareils et les comportements des utilisateurs finaux pour déceler les attaques possibles.
- Protégez vos applications mobiles contre les logiciels malveillants et les autres menaces externes.