Les entreprises du secteur financier figurent parmi les sociétés les plus ciblées par les cyberattaques au monde. Elles attirent en effet les attaquants les plus sophistiqués et les mieux équipés.
La collaboration de tous les niveaux de l’entreprise pour identifier et parer les attaques qui exploitent les vulnérabilités inhérentes revêt une importance croissante. Cela est d’autant plus vrai pour les failles qui ne peuvent être corrigées, car elles résultent d’exigences commerciales valables et souvent critiques.
L’utilisation automatisée d’identifiants de connexion dérobés pour accéder de manière frauduleuse à des comptes d’utilisateurs, alias le « credential stuffing »
Le « credential stuffing » est une pratique qui consiste pour les acteurs malveillants à se procurer des centaines de milliers, des millions, voire des milliards de combinaisons de nom d’utilisateur et de mot de passe sur le Dark Web ou auprès d’une organisation peu sécurisée. Ils ont ensuite recours à l’automatisation pour tenter ces combinaisons sur les applications de connexion d’autres sociétés qui n’étaient pas les cibles du piratage initial.
Les acteurs malveillants lancent parfois des attaques par le biais d’une fintech, comme un programme de fidélité ou un agrégateur financier, ou encore un service de paiement de factures. Pour utiliser ces services gratuits, l’abonné doit d’abord « relier » son compte à sa banque, son point de vente, son hôtel, sa compagnie aérienne, son fournisseur de télécommunications, etc., en donnant à la fintech son nom d’utilisateur et son mot de passe pour chaque compte. La fintech tente ensuite de se connecter de manière systématique à chaque compte. Si l’abonné fournit la bonne combinaison nom d’utilisateur/mot de passe, la liaison est établie. Une fois le compte lié, la fintech a recours à l’automatisation pour se connecter de manière répétée au compte et en extraire le contenu, parfois à plusieurs milliers de reprises par jour.
Dans le cas des comptes canaris, le cybercriminel va tenter d’obtenir des noms d’utilisateur et des mots de passe à partir d’identifiants dérobés ou achetés, avec un taux de réussite compris entre 0,1 et 3 %. Il utilise ensuite la même méthode pour se connecter plusieurs fois à un ou plusieurs comptes canari, affichant un taux de réussite de connexion de 100 %. Résultat : le taux net de réussite de connexion progresse pour toutes les transactions provenant de la même infrastructure.
Une autre technique consiste à lancer une attaque contre une application qui confirmera si le nom d’utilisateur correspond à un compte valide. Si ce n’est pas le cas, l’attaquant sait que l’utilisation du mot de passe entraînerait l’échec de la connexion. Les applications fréquemment visées par les attaques par énumération sont Nom d’utilisateur, ID ou mot de passe oublié et Créer un compte.
Il est observé fréquemment l’utilisation de l’automatisation contre l’application « créer un compte » pour des raisons autres que l’attaque par énumération. Ce constat se vérifie particulièrement pour les entreprises de services financiers exploitées pour le blanchiment d’argent et pour la création et le maintien d’identités synthétiques.
La protection d’une organisation contre les attaques visant ses vulnérabilités intrinsèques résulte exclusivement du respect strict d’un processus permanent en trois étapes :
Pour identifier les applications susceptibles d’être automatisées, il convient de répondre de manière informée et objective aux questions posées pour chaque application. Pourquoi quelqu’un pourrait-il lancer une automatisation contre l’application ? Pourquoi quelqu’un pourrait-il percevoir un avantage monétaire ou de collecte de renseignements en agissant de la sorte ? Ou existe-t-il une motivation à long terme, plus stratégique ? Pour obtenir des réponses à ces questions, il faut maîtriser les applications et les flux de travail, et s’appuyer sur une connaissance approfondie de l’automatisation observée dans d’autres sociétés financières.
Il est nécessaire d’autoriser les bonnes automatisations et d’atténuer les mauvaises. Les éléments clés à prendre en compte sont les suivants :
Il faut éviter les transactions selon une liste d’autorisation utilisant un attribut qui peut être facilement usurpé, tel qu’une chaîne User-Agent. Dans l’idéal, les transactions selon une liste d’autorisation utilisent un secret partagé quelque part dans l’en-tête http.
Il est important de ne pas atténuer une mauvaise automatisation en abandonnant la session, ce qui renseignerait l’acteur à cet égard et l’inciterait à se réorganiser. Au contraire, il faut privilégier la discrétion afin de retarder la prise de conscience par l’acteur malveillant de l’atténuation de l’automatisation. Il convient de se diriger vers des solutions qui proposent des options d’atténuation supplémentaires, telles que : rediriger ou faire suivre la transaction, injecter ou modifier un élément dans la transaction et le transmettre à l’origine, ou renvoyer une page HTML entièrement formée.
Les organisations doivent effectuer une analyse rétrospective permanente des transactions qui touchent l’application ciblée afin d’identifier rapidement les réorganisations ou autres automatisations indésirables, avec des systèmes d’intelligence artificielle et d’apprentissage automatiques assistés par l’homme et fonctionnant sur des transactions agrégées.
Il est également primordial de disposer d’un moyen de mettre rapidement à jour les défenses d’une organisation en temps réel sans affecter les clients légitimes.
Les solutions traditionnelles comprennent les défenses de niveau 5 à 7, telles que les pare-feu pour applications Web (WAF), l’exigence d’une vérification en deux étapes (2FA) pour l’application ciblée, ou les outils de détection et de prévention des bots, tels que les CAPTCHA :
Pare-feu pour applications Web (WAF). Les WAF traditionnels s’intéressent principalement à la couche applicative pour se défendre contre le Top 10 de l’OWASP. Cependant, la couche applicative fournit un signal insuffisant pour détecter de manière fiable une automatisation sophistiquée. Des signaux supplémentaires, tels que ceux obtenus en collectant des données biométriques comportementales et en interrogeant l’environnement du navigateur/de l’appareil, sont requis.
Authentification double facteur (2FA). L’authentification 2FA joue un rôle important, mais son utilisation généralisée est coûteuse et entraîne des points de friction avec les clients. De plus, si elle rend la prise de contrôle de comptes plus difficile, elle n’empêche pas toujours le « credential stuffing ». Dans la plupart des implémentations 2FA, un client soumet un nom d’utilisateur et un mot de passe. Si ceux-ci sont corrects, il est invité à entrer l’authentification double facteur. Si les données saisies sont incorrectes, le client reçoit un message d’erreur et n’est pas invité à saisir le deuxième facteur d’authentification. La différence perçue dans la réponse indique à l’attaquant si les identifiants sont corrects. L’attaquant n’a pas pris le contrôle du compte, mais il peut vendre les identifiants connus à un autre attaquant spécialisé dans la neutralisation de l’authentification 2FA (par exemple, via des ports de sortie, des échanges de cartes SIM, des compromissions SS7, des logiciels malveillants sur iOS/Android, ou l’ingénierie sociale).
CAPTCHA. Les CAPTCHA génèrent des points de frictions indésirables pour les clients, ce qui entraîne l’abandon de la session et des revenus. En plus de ce point commun avec l’authentification 2FA, ils n’arrêtent pas les bots. Des dizaines d’entreprises utilisent la reconnaissance optique de caractères (OCR), l’apprentissage automatique et même des fermes à clics avec intervention humaine pour résoudre les CAPTCHA pour une somme symbolique.
Shape a constaté qu’après avoir réussi à limiter l’automatisation indésirable contre les applications Web et mobiles, et après avoir combattu les acteurs qui se réorganisent pendant des semaines, voire des mois, de nombreux acteurs poursuivent leur activité manuellement en utilisant des fermes à clics avec intervention humaine.