Comment les attaquants contournent l'authentification moderne à deux facteurs et comment protéger vos utilisateurs

Ben Balthazar, février 4, 2020
How Attackers Bypass Modern Two-factor Authentication and How to Protect Your Users

Dans cet article, nous allons jeter un oeil à un exemple d'outils et de techniques que les attaquants peuvent utiliser pour contourner la plupart des méthodes traditionnelles d'authentification à deux facteurs (2FA), de SMS OTP aux notifications push cryptées à une application mobile. La méthode d'attaque peut être très efficace contre la plupart des types de 2FA déployés aujourd'hui, y compris l'authentification hors bande. Nous discuterons également du type de contre-mesures qui peuvent être mises en œuvre par les banques pour atténuer le risque de telles attaques et protéger leurs clients.

Mise en place de l'attaque

Pour exécuter cette attaque, nous utiliserons une combinaison de deux outils, Muraena et Necrobrowser. Muraena est un proxy inversé qui exécutera notre page de phishing. La page d'hameçonnage proxy la page d'origine avec laquelle la victime interagira. Une fois que la victime a authentifiéla, la session Muraena remettra la session à Necrobrowser, ce qui permet à l'attaquant de prendre le contrôle de la session ou d'automatiser les prochaines étapes de l'attaque. Parce que Muraena agit comme un proxy inverse, il n'y aura aucune différence entre notre site malveillant et le site web d'origine en dehors de l'URL. Muraena peut être configuré pour utiliser SSL avec des certificats obtenus par exemple LetsEncrypt. Du point de vue de la victime, toute l'expérience semblera légitime car il semble qu'ils interagissent avec la page authentique. Ils passeront par le processus d'authentification régulier, y compris le 2FA. Si le 2FA se compose d'un mot de passe unique régulier livré par SMS, matériel ou jeton logiciel, puis la victime entrera comme d'habitude. Cependant, même les méthodes modernes telles qu'une notification push à un appareil mobile ou la numérisation d'un code QR à l'écran seront contournées par cette attaque.

Illustration de l'attaque inversée d'hameçonnage par procuration.

  1. L'utilisateur visite la page d'hameçonnage, qui a activé SSL.
  2. Le Proxy inversé (Muraena) récupère la page bancaire légitime et en sert une copie à la victime.
  3. La victime tente de se connecter à la page et est invitée à l'authentification à deux facteurs
  4. Une fois que la victime a terminé le processus d'authentification, le proxy inversé (Muraena) remet la session à l'attaquant (Necrobrowser) pour prendre le contrôle, coupant la victime.

Dans l'image ci-dessous, vous pouvez voir Muraena hébergeant Google sur le domaine phish.anti. Pour les besoins de démonstration, j'ai mis en place un DNS local pour résoudre ce problème à ma machine de test et a également émis des certificats en utilisant mon propre CA qui est approuvé par le navigateur. Cependant, c'est exactement ce qu'il ressemblerait du point de vue de la victime si cela a été déployé sur votre propre domaine en utilisant des certificats valides.

Capture d'écran de Muraena proxying google.com sur phish.anti en utilisant SSL.

Protéger contre l'attaque

Maintenant que nous comprenons comment fonctionne l'attaque, nous pouvons identifier les étapes qui réussiraient à identifier ou à protéger contre ce type d'attaques.

La liaison dynamique fournit une bonne première couche de défense contre une variété d'attaques. Le lien dynamique consiste en une authentification à deux facteurs effectuée au moment de la transaction, qui intègre les détails de la transaction dans le processus de signature. Souvent appelé Ce que vous voyez est ce que vous signez, parce que l'utilisateur final doit être présenté avec les détails de la transaction avant de terminer le processus de signature. Une fois signée, la signature ne doit être valide que pour cette transaction spécifique, ce qui rend plus difficile le contournement de l'attaquant. Typiquement liaison dynamique est implémentée via des jetons matériels, des jetons logiciels ou intégré dans le cadre d'une application bancaire. Ci-dessous nous avons 2 exemples de liaison dynamique, d'abord pour un paiement légitime et le second où un attaquant tente de modifier le paiement.

Illustration de liaison dynamique dans un paiement légitime.

  1. L'utilisateur crée une transaction dans la banque en ligne.
  2. L'utilisateur soumet la transaction.
  3. La banque envoie les détails de la transaction au téléphone mobile de l'utilisateur.
  4. L'utilisateur vérifie les détails du transfert et autorise le paiement avec un biométrique (ou un autre deuxième facteur).
  5. L'application mobile génère un mot de passe one Time en utilisant les détails de la transaction et la clé de jeton à l'intérieur de l'application mobile.

Illustration de liaison dynamique où un attaquant tente de modifier le paiement.

  1. L'utilisateur tente de créer un paiement dans la banque en ligne.
  2. L'attaquant modifie le paiement pour avoir un nouveau compte bénéficiaire et/ou un montant.
  3. La banque envoie les détails de la transaction au téléphone mobile de l'utilisateur.
  4. L'utilisateur est présenté avec les informations de paiement modifiées et rejette le paiement.

Les exemples ci-dessus illustrent également l'importance d'utiliser le chiffrement de bout en bout lors de la mise en œuvre de liaisons dynamiques. En outre, il montre que l'application mobile elle-même doit être protégée car l'attaquant peut essayer d'attaquer l'application pour masquer les détails de paiement modifiés de l'utilisateur.

Une autre façon efficace de reconnaître et de se défendre contre une grande variété d'attaques est d'implémenter une surveillance continue sur vos plates-formes numériques. En surveillant la session du moment de l'initiation jusqu'à la fin de la session, nous pouvons mettre en contexte plus de contexte à travers les actions des utilisateurs et les appareils ou comptes auxquels ils s'associent. La surveillance continue se combine parfaitement avec d'autres couches telles que 2FA ou liaison dynamique car elle permet à la banque de mettre en contexte à partir de ces dispositifs d'authentification ainsi.

Exemple de surveillance continue pour comprendre chaque tentative d'opération, authentification et résultat.

La banque peut alors surveiller les indicateurs typiques des attaques connues telles que les nouveaux appareils, les emplacements, la présence de proxy, ou d'autres. Ces informations peuvent être corrélées à travers sa base d'utilisateurs pour mieux comprendre le risque de ces éléments. Nous pouvons alors également tenir compte des opérations que l'utilisateur effectue tout au long de la session elle-même et profilez cela par rapport à leur comportement habituel. Cette approche établit un profil de risque continu pour la session qui peut changer à chaque action effectuée par l'utilisateur final. Non seulement cela permet à la banque de prendre ensuite des actions automatisées en temps réel lorsque des anomalies sont détectées, mais elle permet également à la banque de réduire les frictions pour les sessions légitimes en réduisant le nombre d'authentifications nécessaires pour les sessions authentiques.

Conclusion

Bien que l'attaque dans cet article utilise la technologie et les concepts qui ont été autour depuis des siècles, nous voyons que leur application correcte peut encore conduire à un grand succès et vaincre les différentes méthodes d'authentification déployée aujourd'hui. Il est important pour les banques d'utiliser une approche en couches car la plupart des couches individuelles peuvent encore être attaquées ou exploitées. Lors de la mise en œuvre de liaisondynamique, les banques doivent s'assurer qu'elles établissent une ligne de communication sécurisée avec l'utilisateur final. S'appuyer sur SMS par exemple s'est déjà avéré peu fiable car les messages peuvent être volés, usurpés ou interceptés par l'attaquant. Toutefois, lors de la mise en œuvre d'applications mobiles, les banques doivent également être conscientes que ces applications deviennent une cible et qu'elles doivent protéger leurs applications mobiles contre les attaques externes. Le but de cet article est principalement de démontrer que les attaques d'hameçonnage peuvent être modernisées pour vaincre l'authentification à deux facteurs lors de la connexion et la mise en œuvre de 2FA seul n'offre pas une protection complète contre l'hameçonnage. Enfin, nous avons mentionné certaines couches que les banques peuvent mettre en œuvre pour fournir une protection supplémentaire à leurs utilisateurs finaux, ainsi que les pièges à éviter en le faisant. Pour résumer:

  • Implémenter un lien dynamique avec le chiffrement de bout en bout.
  • Déployez des analyses côté serveur pour surveiller les sessions, les périphériques et le comportement de l'utilisateur final en fonction des attaques potentielles.
  • Protégez vos applications mobiles contre les logiciels malveillants et autres menaces externes.
Couverture ebook
E-book

Piratage de compte : Garantir la protection de ses clients et de son activité

Luttez contre le piratage de compte et protégez vos clients à chaque étape de leur parcours numérique.

Télécharger

 

 

Ben Balthazar est consultant en fraude chez OneSpan pour aider les institutions financières d’Europe, du Moyen-Orient et d’Asie à se défendre contre la cybercriminalité financière. Ben a débuté sa carrière chez OneSpan en 2014 et a quitté la Belgique pour Dubaï en 2016.