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 le présent article, nous examinerons des outils et des techniques que les pirates peuvent utiliser pour contourner la plupart des méthodes traditionnelles d'authentification à deux facteurs (2FA), du code SMS OTP aux notifications push cryptées sur une application mobile. La méthode d’attaque peut s'avérer très efficace contre la plupart des types d'authentification 2FA déployés aujourd’hui, y compris l’authentification des données hors bande. Nous parlerons également des types de contre-mesures que les banques peuvent mettre en œuvre pour atténuer le risque de ces attaques et protéger leurs clients.

Préparation de l’attaque

Pour mettre cette attaque à exécution, nous utiliserons une combinaison de deux outils, Muraena et Necrobrowser. Muraena est un proxy inverse qui exécutera notre page d'hameçonnage. La page d'hameçonnage sera un proxy de la page d’origine avec laquelle la victime interagira. Lorsque la victime a authentifié les données associées à la session, Muraena transmet cette dernière à Necrobrowser, ce qui permet au pirate de prendre le contrôle de la session ou d’automatiser les étapes suivantes de l’attaque. Et puisque Muraena agit comme un proxy inverse, il n’y aura aucune différence entre notre site malveillant et le site d’origine, à l’exception de l’URL. Muraena peut être configuré de façon à utiliser le protocole SSL avec des certificats obtenus par exemple via LetsEncrypt. Du côté de la victime, l’expérience dans son ensemble lui semblera normale, car elle aura l’impression d’interagir avec la page d’origine. La victime effectuera le processus d’authentification habituel, notamment la 2FA. Si les données associées à la 2FA consistent en un mot de passe à usage unique ordinaire transmis par SMS, par un jeton matériel ou logiciel, la victime le saisira comme d’habitude. Cependant, même les méthodes modernes telles que la notification push sur un appareil mobile ou la lecture d’un code QR à l’écran seront contournées par cette attaque.

Illustration de l'attaque par hameçonnage via un proxy inverse

  1. L’utilisateur consulte la page d'hameçonnage sur laquelle le protocole SSL est activé.
  2. Le proxy inverse (Muraena) va chercher la page authentique de la banque et en livre une copie à la victime.
  3. La victime essaie de se connecter à la page et est invitée à procéder à une authentification à deux facteurs.
  4. Lorsque la victime a terminé le processus d’authentification, le proxy inverse (Muraena) transmet la session au pirate (Necrobrowser) pour en prendre le contrôle, déconnectant la victime.

Dans l’image ci-dessous, vous pouvez observer Muraena hébergeant Google sur le domaine phish.anti. Pour les besoins de la démonstration, j’ai installé un DNS local pour résoudre ce problème sur ma machine de test et j’ai également délivré des certificats en utilisant ma propre AC à laquelle le navigateur fait confiance. Cependant, voici exactement ce à quoi l'expérience ressemblerait aux yeux de la victime si cela était déployé sur votre propre domaine en utilisant des certificats valides.

Capture d'écran de Muraena agissant comme un proxy de google.com sur phish.anti en utilisant SSL.

Protection contre l’attaque

Maintenant que nous savons comment fonctionne l’attaque, nous pouvons identifier les mesures qui permettraient d’identifier ce type d’attaques et de s'en protéger.

L'authentification dynamique constitue un bon premier niveau de défense contre toute une série d’attaques. L'authentification 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. Elle est souvent appelée « What You See Is What You Sign » (ce que vous voyez est ce que vous signez), car l’utilisateur final doit se voir présenter les détails de la transaction avant de terminer le processus de signature. Une fois la transaction signée, la signature ne devrait être valable que pour cette transaction spécifique, ce qui rend le contournement plus difficile pour le pirate. En général, l'authentification dynamique est mise en œuvre au moyen de jetons matériels, de jetons logiciels, ou elle est intégrée dans une application de service bancaire. Voici deux exemples d'authentification dynamique, le premier pour un paiement authentique et le second où un pirate tente de modifier le paiement.

Illustration de l'authentification dynamique dans un paiement authentique.

  1. L’utilisateur crée une transaction dans les services bancaires en ligne.
  2. L’utilisateur soumet la transaction.
  3. La banque envoie les détails de la transaction sur le téléphone portable de l’utilisateur.
  4. L’utilisateur vérifie les détails du transfert et autorise le paiement à l’aide d’un système biométrique (ou d’un autre second facteur).
  5. L’application mobile génère un mot de passe à usage unique en utilisant les détails de la transaction et la clé à jeton à l’intérieur de l’application mobile.

Illustration de l'authentification dynamique lorsqu'un pirate essaie de modifier le paiement.

  1. L’utilisateur essaie de créer un paiement dans les services bancaires en ligne.
  2. Le pirate modifie le paiement pour créer un nouveau compte bénéficiaire ou un nouveau montant.
  3. La banque envoie les détails de la transaction sur le téléphone portable de l’utilisateur.
  4. L’utilisateur reçoit les informations de paiement modifiées et rejette le paiement.

Les exemples ci-dessus illustrent également l’importance d’utiliser un chiffrement de bout en bout lors de la mise en œuvre d'une authentification dynamique. Ils montrent également que l’application mobile elle-même doit être protégée, car le pirate peut essayer de l’attaquer pour cacher à l’utilisateur les détails de paiement modifiés.

La mise en place d'une surveillance continue sur vos plateformes numériques constitue un autre moyen efficace de reconnaître une grande variété d’attaques et de s'en protéger. En surveillant la session, de son ouverture jusqu’à sa fermeture, nous pouvons mieux comprendre la situation au travers des actions des utilisateurs et des appareils ou comptes auxquels ils sont associés. La surveillance continue se combine à merveille avec d’autres niveaux de protection tels que la 2FA ou l'authentification dynamique, car elle permet à la banque de comprendre la situation également à partir de ces dispositifs d’authentification.

Exemple de surveillance continue pour comprendre chaque tentative d'attaque des opérations, l'authentification et le résultat.

La banque peut ensuite surveiller les indicateurs habituels des attaques connues, tels que les nouveaux dispositifs, les lieux, la présence d’un proxy, ou autres. Ces informations peuvent être corrélées entre les utilisateurs pour mieux comprendre le risque que présentent ces éléments. Nous pouvons également prendre en compte les opérations que l’utilisateur effectue tout au long de la session et les comparer à son comportement habituel. Cette approche permet d’établir un profil de risque continu pour la session, qui peut changer à chaque action effectuée par l’utilisateur final. De cette manière, la banque peut non seulement prendre des mesures automatisées en temps réel lorsque des anomalies sont détectées, mais elle peut également apporter de la fluidité aux sessions légitimes en réduisant le nombre d’authentifications requises.

Conclusion

Bien que l’attaque dont il est question dans cet article repose sur des technologies et des concepts qui existent depuis des lustres, nous constatons que s'ils sont correctement mis à exécution, ils peuvent encore permettre aux pirates de gagner la partie et de venir à bout des diverses méthodes d’authentification déployées aujourd’hui. Il est donc important pour les banques d’utiliser une approche par niveau, car la plupart des niveaux individuels peuvent encore être attaqués ou exploités. Lors de la mise en œuvre de l'authentification dynamique, les banques doivent s’assurer qu’elles établissent une ligne de communication sécurisée avec l’utilisateur final. Le recours aux SMS, par exemple, s’est déjà révélé peu fiable, car les messages peuvent être volés, usurpés ou interceptés par le pirate. Toutefois, lors de la mise en œuvre d’applications mobiles, les banques doivent également savoir que ces applications sont de plus en plus ciblées. Elles doivent donc protéger leurs applications mobiles contre les attaques extérieures. L’objectif de cet article est principalement de démontrer que les attaques par hameçonnage peuvent être modernisées afin de vaincre l’authentification à deux facteurs lors de la connexion, et que la mise en œuvre de la 2FA seule ne garantit pas une protection complète contre l'hameçonnage. Enfin, nous avons mentionné certains niveaux que les banques peuvent mettre en œuvre pour fournir une protection supplémentaire à leurs utilisateurs finaux, ainsi que les pièges à éviter lors de cette mise en œuvre. En résumé :

  • Mettez en œuvre une authentification dynamique en utilisant un chiffrement de bout en bout.
  • Déployez des analyses côté serveur pour surveiller les sessions, les appareils et le comportement des utilisateurs finaux en vue de détecter d’éventuelles attaques.
  • Protégez vos applications mobiles des logiciels malveillants et autres menaces extérieures.
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.