L’authentification multifacteur (MFA) ne résout pas le risque de prise de contrôle de compte. Cela ajoute des obstacles, certes, mais des attaquants déterminés ont découvert des moyens ingénieux pour contourner tous les facteurs d’authentification disponibles. Plutôt que de résoudre le problème de l’authentification, nous devrions considérer l’AMF comme un élargissement de la surface d’attaque : chaque facteur introduit un nouveau système de dépendances, de nouvelles sources de bugs et de vulnérabilités, et de nouvelles opportunités d’ingénierie sociale. Malheureusement, de nombreuses organisations de sécurité considèrent l’authentification multifacteur (MFA) comme nous considérions autrefois le périmètre du réseau, c’est-à-dire comme un rempart capable de résoudre un large éventail d’attaques. L’erreur du périmètre sécurisé, révélée par les partisans de la sécurité Zero Trust , a permis aux attaquants d’exploiter les vulnérabilités à l’intérieur des réseaux pour se déplacer latéralement et augmenter leurs privilèges. De même, l’idée fausse selon laquelle l’authentification multifacteur résout le problème de la prise de contrôle des comptes empêche les organisations de sécurité de reconnaître les faiblesses de l’authentification multifacteur et les nombreuses vulnérabilités restantes du système qui exposent les comptes utilisateurs à une prise de contrôle criminelle. En examinant comment les attaquants contournent l'authentification multifacteur, ce livre blanc démontre que l'authentification multifacteur rend certaines autres mesures de sécurité encore plus importantes, à savoir l'atténuation des robots, les protections de la chaîne d'approvisionnement JavaScript et la surveillance des risques contextuels, des techniques qui renforcent les avantages de sécurité de l'authentification multifacteur tout en réduisant les frictions qu'elle impose aux utilisateurs.
Malgré ses faiblesses, l’authentification multifacteur est là pour rester et pour une bonne raison : l’authentification par mot de passe uniquement a clairement échoué.
Nous, les humains, ne pouvons tout simplement pas nous souvenir de longues chaînes de caractères aléatoires. En conséquence, nous prenons des raccourcis : nous choisissons des mots de passe faciles à retenir et prévisibles, nous réutilisons les mots de passe dans différentes applications, nous griffonnons les mots de passe sur des post-it. Bien que les entreprises atténuent ce risque en imposant des exigences en matière de longueur et de complexité des mots de passe, la mémoire humaine a ses limites ; même face à ces exigences de complexité, nous trouvons des moyens d’être prévisibles : mettre en majuscule uniquement la première lettre, insérer des caractères spéciaux à la place de caractères alphanumériques similaires ($ pour S), ajouter des chiffres devinables tels que 123 à la fin d’un mot de passe. (Voir les résultats de la recherche sur la prévisibilité des mots de passe .)
Nous, les humains, partageons également des défauts qui nous rendent vulnérables à l’ingénierie sociale. Nous divulguons nos mots de passe lorsque les attaquants jouent sur notre confiance, notre désir de nous conformer, notre respect de l’autorité et notre volonté d’aider. Il s'avère que les gens donnent parfois leur mot de passe si vous leur demandez simplement, ce que vous pouvez apprécier en regardant dans cette vidéo amusante de Jimmy Kimmel Live .
Compte tenu des faiblesses de l’authentification par mot de passe, les agences gouvernementales et les associations industrielles encouragent l’adoption de l’authentification multifacteur. En mai 2021, le président Biden a publié un décret exigeant que les agences fédérales adoptent l’AMF dans les 180 jours, et la Cybersecurity and Infrastructure Security Agency (CISA) promeut l’AMF pour les entreprises privées. Le Payment Card Industry Security Standards Council exige, avec sa norme de sécurité des données v4.0 , que les organisations mettent en œuvre l'authentification multifacteur pour tout accès aux données des titulaires de cartes de crédit d'ici le 31 mars 2025.
Les avantages évidents de l’authentification multifacteur par rapport à l’authentification par mot de passe étant à l’origine de son adoption, les professionnels de la sécurité doivent accorder une attention accrue aux inconvénients de l’authentification multifacteur, à la manière dont elle élargit la surface d’attaque et crée de nouvelles vulnérabilités qui permettent aux attaquants de contourner les contrôles d’authentification.
L'authentification multifacteur est définie comme l'application de deux ou plusieurs facteurs dans le processus d'authentification. Par facteur, nous entendons une manière de prouver que vous êtes bien celui que vous prétendez être à travers :
Il existe une multitude de façons de mettre en œuvre l’authentification multifacteur, et bon nombre d’entre elles ouvrent de nouvelles surfaces d’attaque ou exposent les applications aux mêmes vulnérabilités qui caractérisent l’authentification par mot de passe uniquement.
Il existe une multitude de façons de mettre en œuvre l’authentification multifacteur, et bon nombre d’entre elles ouvrent de nouvelles surfaces d’attaque ou exposent les applications aux mêmes vulnérabilités qui caractérisent l’authentification par mot de passe uniquement.
L’implémentation la plus répandue de l’authentification multifacteur utilise les SMS pour envoyer aux utilisateurs un mot de passe à usage unique (OTP), qui prouve en principe la possession d’un smartphone. En général, un utilisateur initie la connexion avec un nom d'utilisateur et un mot de passe, ce qui déclenche l'envoi du message texte par l'application. L'utilisateur visualise ensuite l'OTP et le saisit dans l'application, complétant ainsi l'authentification et générant un jeton de session qui sera valide pendant une durée définie.
La mise en œuvre du facteur de possession via SMS ne parvient pas à fermer plusieurs vulnérabilités clés. Étant donné que l'utilisateur saisit l'OTP et le mot de passe dans l'application et que l'application renvoie l'OTP au serveur via le même canal de communication utilisé par l'application, un attaquant ayant compromis l'application, l'appareil ou le réseau pourra accéder au mot de passe, à l'OTP et au jeton de session.
En utilisant de nombreuses techniques bien établies et toujours courantes, les attaquants prennent le contrôle des appareils en les infectant avec des logiciels malveillants, ce qui donne lieu à une attaque de l'homme dans le navigateur (MitB). L’exécution de code dans le navigateur permet aux attaquants d’obtenir le mot de passe et l’OTP avec lesquels ils peuvent s’authentifier au nom de l’utilisateur. Alternativement, l'attaquant peut laisser l'authentification se terminer, puis voler l'identifiant de session, qui pourrait être utilisé pour contourner l'authentification et accéder au compte d'un utilisateur. (Pour connaître les tendances récentes en matière de logiciels malveillants infectant les terminaux, consultez le rapport de F5 Labs sur BlackGuard Infostealer .)
En infectant une application, les attaquants peuvent prendre le contrôle des comptes des utilisateurs en masse. Outre le fait de compromettre l’infrastructure d’une entreprise par le biais de logiciels malveillants, les criminels peuvent accéder aux données d’une application en compromettant l’une des bibliothèques de code qui composent l’application, une tactique connue sous le nom d’attaque côté offre.
Lors d'une attaque de la chaîne d'approvisionnement de logiciels, l'attaquant cible généralement un fournisseur tiers de confiance ou un référentiel open source qui fournit des composants logiciels (bibliothèques, frameworks, services) à l'organisation ciblée. L’attaquant injecte un malware dans le composant qui est ensuite intégré à l’application. Cette attaque peut être efficace car tous les fournisseurs et toutes les équipes open source ne disposent pas des compétences et des ressources nécessaires pour appliquer des pratiques de codage sécurisées.
Les applications Web et mobiles sont particulièrement vulnérables aux attaques de la chaîne d’approvisionnement, car elles incluent généralement des dizaines de scripts tiers, dont beaucoup sont ajoutés aux pages de manière dynamique par les gestionnaires de balises. Ces scripts, qui changent fréquemment et sans préavis, ne passent pas les contrôles de sécurité du code d’une organisation. Si un attaquant parvient à compromettre l’un de ces scripts, il obtient le contrôle total d’une application, ce qui signifie qu’il peut lire les entrées de l’utilisateur, accéder aux données de la mémoire du navigateur ou détourner le parcours de l’utilisateur pour le diriger vers une application malveillante sans avertissement.
Ces attaques de la chaîne d’approvisionnement , telles que Magecart, ont provoqué des failles de sécurité sur des centaines de milliers d’identifiants. Tout comme les attaques MitB, ces attaques de la chaîne d’approvisionnement fonctionnent contre toute solution MFA dans laquelle le jeton prouvant la possession est saisi dans l’application, ce qui est typique de la plupart des implémentations utilisant des OTP. Étant donné que le code malveillant lit les entrées de l’utilisateur, il pourrait voler à la fois le mot de passe statique et l’OTP, ainsi que toute autre information personnelle ou financière collectée par l’application.
Étant donné qu’avec l’authentification par SMS, le mot de passe, l’OTP et le jeton de session circulent sur la même connexion réseau, cette forme d’authentification multifacteur reste vulnérable aux attaques de l’homme du milieu (MitM) utilisant des vecteurs d’attaque classiques tels que l’empoisonnement DNS, l’empoisonnement ARP et les points d’accès sans fil malveillants.
L’une des attaques les plus courantes et les plus réussies contre l’authentification multifacteur basée sur SMS utilise l’ingénierie sociale pour établir une attaque MitM via des proxys de phishing en temps réel (RTPP).
Dans cette attaque, le fraudeur utilise des e-mails de phishing pour tromper un utilisateur et l'amener à visiter un site contrôlé par l'attaquant, où l'utilisateur saisit dûment ses informations d'identification. Jusqu’à présent, cette tactique est identique à une attaque de phishing pour le vol d’informations d’identification, mais pour contourner l’authentification multifacteur, une étape supplémentaire est nécessaire. Lorsque l'utilisateur saisit son nom d'utilisateur et son mot de passe dans l'application, l'attaquant transmet ces informations d'identification à l'application cible, qui émet ensuite une deuxième demande de facteur à l'utilisateur. Il est très probable que l'utilisateur approuve la demande car il pense s'authentifier auprès d'une application de confiance ; l'utilisateur clique sur le bouton d'approbation ou saisit consciencieusement le jeton dans l'application. Dans les deux cas, l'attaquant obtient l'accès à l'application. (Pour une démonstration de l'attaque, voir cette vidéo de Kevin Mitnick.)
Grâce à l’automatisation et à la propension des utilisateurs à tomber dans le piège des escroqueries par phishing, les attaques RTPP peuvent réussir à grande échelle. (Pour plus de données sur la croissance des proxys de phishing en temps réel, consultez le rapport sur le phishing et la fraude de F5 Labs .)
En plus de ne pas permettre de combler de nombreuses vulnérabilités existantes liées à l’authentification par mot de passe uniquement, l’utilisation des SMS comme deuxième facteur expose une application à des vecteurs d’attaque supplémentaires.
L’attaque la plus évidente contre l’authentification basée sur la possession est peut-être le vol d’un appareil physique. Un criminel qui vole un téléphone peut avoir accès à un OTP affiché dans une notification, même lorsque le téléphone est verrouillé. De nombreuses victimes de vol de téléphone se sont retrouvées à perdre les fonds de leur compte bancaire.
Les criminels n’ont pas besoin de posséder physiquement un téléphone pour accéder aux OTP envoyés par SMS. L'échange de carte SIM , également connu sous le nom de détournement de carte SIM ou portage de carte SIM, permet aux attaquants de contourner l'authentification par SMS, qui est la forme la plus populaire de MFA utilisée dans les applications destinées aux clients. Lors d'une attaque par échange de carte SIM, le fraudeur exploite la capacité des fournisseurs de services de télécommunication à transférer un numéro de téléphone vers un autre appareil, une fonctionnalité qui s'avère utile lorsqu'un téléphone est perdu ou volé.
Le fraudeur commence par recueillir des informations personnelles sur la victime par le biais de recherches en ligne, d’hameçonnage ou d’ingénierie sociale. Grâce à ces informations, l'attaquant convainc l'opérateur téléphonique de transférer le numéro de téléphone de la victime sur la carte SIM du fraudeur. L’attaquant peut également pénétrer dans le compte de l’utilisateur auprès du fournisseur de services en utilisant le bourrage d’informations d’identification, la devinette par force brute ou une attaque par dictionnaire.
En contrôlant le service téléphonique de la victime, l’escroc recevra tous les SMS et appels vocaux destinés à la victime. Cela permet au fraudeur d’intercepter tous les jetons de sécurité envoyés par SMS.
Les dispositifs à jetons matériels sont des dispositifs spécialisés, généralement assez petits, qui affichent un OTP que l'utilisateur saisit dans une application pour s'authentifier. Ces appareils offrent un moyen de prouver la possession sans nécessiter de communication de l’application à l’utilisateur, ce qui supprime l’une des principales vulnérabilités de l’authentification par SMS.
Plutôt que de s’appuyer sur l’envoi de l’OTP à l’utilisateur à chaque connexion, l’appareil génère un flux d’OTP basé sur une valeur de départ initiale et un algorithme. La valeur de départ elle-même est partagée entre l'appareil et le service d'authentification lors de la configuration. La valeur de départ est augmentée par un compteur qui est soit incrémenté par un événement, tel qu'une demande de connexion, soit par une durée telle que 60 secondes . Nous les appelons respectivement OTP basé sur les événements (EOTP) et OTP basé sur le temps (TOTP). EOTP et TOTP sont tous deux des types d'OTP basés sur le hachage (HOTP) car le compteur et la graine sont transmis ensemble à une fonction de hachage qui génère une chaîne de chiffres apparemment aléatoire qui, lorsqu'elle est implémentée correctement, ne révèle pas de modèle prévisible.
En évitant la nécessité d'envoyer l'OTP par SMS, les jetons matériels rendent impossible la capture de l'OTP avant qu'il n'atteigne l'utilisateur par des moyens tels que l'échange de carte SIM. Cependant, comme l’utilisateur doit saisir l’OTP dans l’application, qui transporte l’OTP au service d’authentification en utilisant le même canal de communication que le mot de passe, la plupart des autres vulnérabilités de l’authentification par SMS demeurent. L'attaquant peut accéder au mot de passe et à l'OTP en compromettant le point de terminaison, le réseau ou l'application de la même manière qu'il le ferait pour les OTP envoyés par SMS.
L'attaque la plus courante contre l'authentification par SMS, les proxys de phishing en temps réel, fonctionne tout aussi bien pour les OTP générés sur des périphériques matériels puisque l'utilisateur est amené à saisir l'OTP sur le faux site, que l'OTP apparaisse sur un téléphone ou un appareil spécialisé.
Bien que les périphériques matériels éliminent la possibilité pour les attaquants de capturer l’OTP en transit vers l’utilisateur, les périphériques s’appuient sur des valeurs de départ qui peuvent être compromises. Les attaquants peuvent accéder à la valeur de départ en accédant physiquement aux appareils (voir la mention d'une attaque au microscope électronique dans 12+ façons de pirater MFA ), en compromettant la base de données utilisée par le service d'authentification ou en interceptant le processus de configuration dans lequel la valeur de départ est convenue entre l'appareil et le service d'authentification.
Les applications d'authentification peuvent fonctionner comme des jetons matériels, en générant un flux d'OTP basé sur une graine initiale et un algorithme, évitant ainsi la nécessité de communiquer la graine via un canal vulnérable, mais elles peuvent également aller plus loin en utilisant un canal alternatif pour communiquer l'OTP. Dans ce scénario, après la vérification réussie d’un nom d’utilisateur et d’un mot de passe, le service d’authentification envoie une notification push à l’application d’authentification, qui invite l’utilisateur à approuver la demande. Une fois approuvée, l’application d’authentification envoie l’OTP directement au service d’authentification sans demander à l’utilisateur de le saisir dans l’application. La communication entre l'application d'authentification et le service d'authentification s'effectue via une connexion distincte.
L’utilisation d’un canal de communication alternatif signifie qu’un attaquant ne peut pas accéder à l’OTP en compromettant l’application, puisque l’OTP n’est jamais saisi dans l’application. Il est également plus difficile de recueillir à la fois le mot de passe et l’OTP en compromettant la connexion réseau, car le mot de passe et l’OTP sont transmis via des canaux sécurisés distincts. Cependant, la compromission du point de terminaison pourrait permettre à un attaquant d’accéder à la fois au mot de passe et à l’OTP si l’application elle-même et l’application d’authentification s’exécutent sur le même appareil. (Voir le rapport de F5 Labs sur les logiciels malveillants qui compromettent Google Authenticator.)
Malheureusement, les applications d’authentification n’empêchent pas l’utilisation de proxys de phishing en temps réel. L'utilisateur est toujours amené à saisir son nom d'utilisateur et son mot de passe sur un faux site via un SMS de phishing. Une fois les informations d'identification saisies, l'application déclenche une demande adressée à l'application d'authentification. Étant donné que l'utilisateur pense se connecter à une application de confiance, il est susceptible d'approuver la demande, ce qui complète l'authentification. Bien que l'attaquant ne voie jamais l'OTP, le proxy de l'attaquant aura désormais le contrôle d'une session authentifiée, donnant à l'attaquant l'accès au compte de l'utilisateur. (Pour en savoir plus sur RTPP et l'authentification par notification push, consultez cet article sur les plateformes de phishing dans Hacker News.)
De plus, la facilité d’utilisation des applications d’authentification a créé un autre moyen par lequel les attaquants peuvent vaincre l’authentification multifacteur par l’ingénierie sociale. Dans les attaques de bombardement MFA ou de fatigue MFA, l'attaquant incite la cible à lui donner son code d'authentification en envoyant plusieurs demandes frauduleuses pour obtenir le code. L'attaquant utilise généralement des outils automatisés pour générer un grand nombre de requêtes, submergeant la victime d'un nombre excessif de notifications ou de messages lui demandant de saisir son code d'authentification.
Bien que le bombardement MFA puisse inciter un utilisateur à saisir un OTP à partir d'un message SMS ou d'un périphérique matériel, il est particulièrement efficace contre les applications d'authentification, car l'utilisateur peut très facilement arrêter le flot de demandes en appuyant sur un bouton.
Il existe encore plus de façons de mettre en œuvre l’authentification biométrique que l’authentification basée sur la possession. Il existe non seulement de nombreuses méthodes permettant de déclencher la demande d’authentification et de communiquer ces données au service d’authentification, mais il existe également de nombreuses formes de biométrie, des empreintes digitales aux analyses d’iris. Le matériel nécessaire pour effectuer l'analyse peut être intégré à l'appareil exécutant l'application, comme une caméra de lecture d'empreintes digitales sur un ordinateur portable, ou nécessiter du matériel séparé. Le lecteur biométrique peut être contrôlé par le système d’exploitation ou une application spécialisée. Compte tenu de ces variations de mise en œuvre, il est difficile de modéliser chaque vulnérabilité. Cependant, il est important de comprendre que malgré la réputation de l’authentification biométrique en matière de sécurité, il existe encore des vulnérabilités très évidentes dans l’authentification biométrique.
En effet, l’une des méthodes les plus populaires pour contourner le facteur de possession, les proxys de phishing en temps réel, peut tout aussi bien être utilisée pour contourner la biométrie. Une fois que l'utilisateur se connecte à une application contrôlée par un attaquant, pensant qu'il s'agit d'une application de confiance, cette application utilisera les informations d'identification pour se connecter à l'application au nom de l'utilisateur, déclenchant ainsi la demande d'authentification biométrique. Tant que l’utilisateur croit qu’il s’authentifie dans la véritable application, il est susceptible de procéder à l’authentification biométrique, donnant ainsi à l’attaquant l’accès au compte. (La norme FIDO2 WebAuthn , créée par le W3C, inclut une protection contre le phishing, même si elle n'est pas encore largement adoptée par les applications Web.)
La possibilité de contourner l’authentification biométrique en compromettant le point de terminaison, l’application ou le réseau dépend de l’implémentation spécifique. Dans la mesure où le système d’authentification biométrique s’exécute sur le même appareil que l’application, la compromission du point de terminaison pourrait interrompre l’authentification. Dans la mesure où l’application gère le processus d’authentification biométrique, la compromission de l’application pourrait interrompre l’authentification. Et dans la mesure où l’authentification biométrique est envoyée sur le même canal de communication utilisé par l’application, compromettre le réseau peut rompre l’authentification. En bref, l’authentification biométrique nécessite une modélisation détaillée des menaces spécifique à la mise en œuvre.
L’authentification biométrique ouvre la voie à une vulnérabilité particulière : la copie et l’usurpation d’identité. Pensez aux empreintes digitales. Nous les laissons partout, sur presque toutes les surfaces lisses que nous touchons. Nous les laissons sur les poignées de porte, dans les restaurants, dans les poubelles. Recueillir des empreintes digitales sur ces surfaces est une tâche triviale ; nous l'avons tous vu faire à maintes reprises dans des séries policières. La réplication des empreintes digitales est également simple, que ce soit avec une imprimante 3D ou des oursons en gélatine .
Pour d’autres formes de biométrie, il existe une compétition permanente entre les chercheurs en sécurité qui révèlent comment la biométrie peut être falsifiée et les fournisseurs qui développent une technologie anti-falsification. Les masques 3D ont trompé les lecteurs de visages dans les aéroports, bien que ces masques puissent être détectés grâce à des contrôles d'activité et d'autres méthodes. De même, les attaquants ont utilisé des enregistrements vocaux avec synthèse vocale deepfake pour contourner les systèmes de reconnaissance vocale, bien qu’il soit possible de détecter ces parodies grâce aux distorsions subtiles ajoutées par les appareils d’enregistrement. Même les images de l'iris peuvent être reproduites et falsifiées à l'aide de lentilles de contact cosmétiques ou d'un œil artificiel, bien que diverses techniques anti-falsification, y compris les distinctions lumineuses entre les tissus humains et les matériaux synthétiques, puissent détecter la falsification. En bref, la sécurité des lecteurs biométriques dépendra de l’état actuel de la technologie d’usurpation et d’anti-usurpation.
Même si nous vivions une vie d’ermites et évitions de toucher physiquement les surfaces, des attaquants pourraient voler nos données biométriques. Grâce aux logiciels malveillants, à l’ingénierie sociale et à l’exploitation de vulnérabilités non corrigées, les attaquants ont volé des milliards de noms d’utilisateur et de mots de passe. Si les attaquants parviennent à pénétrer dans les bases de données qui stockent nos mots de passe, ils pénétreront certainement dans les bases de données qui stockent nos données biométriques. Et une fois qu’une seule violation expose nos données biométriques, nous ne pouvons plus les utiliser en toute sécurité à des fins d’authentification, selon que son usurpation peut être détectée ou non.
Le risque de sécurité lié à la copie et à l’usurpation d’identité est aggravé par le fait que nous ne pouvons pas facilement modifier les caractéristiques mesurées par la biométrie. Lorsqu'un attaquant vole un mot de passe, nous pouvons le changer. Si un attaquant vole une clé OPT ou un téléphone portable, nous pouvons le remplacer et réinitialiser la graine. Toutefois, si un attaquant parvient à accéder à notre empreinte digitale, à notre empreinte palmaire, à notre image faciale ou à toute autre caractéristique biologique et apprend à les falsifier efficacement, nous ne pourrons pas modifier ces caractéristiques physiques sans souffrir considérablement.
Bien que l’authentification multifacteur soit une amélioration par rapport à l’authentification à facteur unique basée sur un mot de passe, elle reste vulnérable, du moins dans les formes de mise en œuvre actuellement les plus courantes. Ainsi, plutôt que de considérer l’authentification multifacteur comme la fin du parcours de sécurité, considérez-la comme un nouveau départ. Les meilleures pratiques en matière de sécurité des applications restent plus pertinentes que jamais, notamment la modélisation des menaces, les revues de code, l’analyse des vulnérabilités, les tests de pénétration et le red teaming. Dans la modélisation des menaces, examinez chaque aspect du processus d’authentification et de gestion des sessions, en tenant compte des nombreux points d’attaque, depuis le magasin d’identités jusqu’à la sécurité physique, réseau et des données. Les cyberattaques cibleront probablement le maillon le plus faible. En particulier, les vulnérabilités de l’authentification multifacteur mettent en évidence quelques domaines clés qui nécessitent une plus grande attention : l’atténuation de l’automatisation, la protection contre les attaques de la chaîne d’approvisionnement JavaScript et la prise en compte du contexte de risque.
Les criminels s'appuient sur des robots pour lancer plusieurs attaques clés sur MFA, notamment le bourrage d'informations d'identification, les proxys de phishing en temps réel et le bombardement MFA, ce qui signifie que l'atténuation des robots est essentielle pour protéger toutes les formes de MFA.
Dans les attaques de bourrage d'informations d'identification, telles que définies par l'OWASP , les criminels obtiennent des informations d'identification volées lors de violations antérieures, généralement via un achat sur le dark web, et testent ces informations d'identification par rapport aux connexions d'autres applications. Étant donné que des milliards d’informations d’identification ont été exposées à la suite de violations, les criminels maximisent leurs bénéfices en automatisant les tests avec des robots afin de pouvoir tester un nombre massif d’informations d’identification. Le Federal Bureau of Investigation , la Securities and Exchange Commission et le procureur général de New York ont émis des avertissements sur les risques financiers du credential stuffing, et la Global Privacy Assembly , une association de plus de 130 agences de régulation, a déclaré que le credential stuffing constituait une menace mondiale pour la vie privée.
Empêcher le bourrage d’informations d’identification est tout aussi important pour l’authentification multifacteur que pour l’authentification par mot de passe uniquement. L’intérêt de l’AMF réside dans l’utilisation de plusieurs facteurs, mais si vous ne parvenez pas à protéger le premier facteur, il ne vous reste plus qu’un seul facteur. Une fois qu’un attaquant a découvert le mot de passe d’un utilisateur, l’authentification à deux facteurs devient une authentification à un facteur et la défense en profondeur est perdue.
De plus, il est essentiel d’atténuer les effets des robots, car les criminels les utilisent pour attaquer bien plus que de simples mots de passe. En effet, les robots sont un outil clé pour lancer des attaques proxy de phishing en temps réel réussies, qui sont les mécanismes les plus courants pour vaincre l’authentification multifacteur. Chaque fois qu'un utilisateur est victime d'un e-mail de phishing qui l'incite à saisir ses informations d'identification sur un faux site, l'attaquant devra transmettre ces informations d'identification à l'application cible pour générer la demande MFA, que cette demande implique un SMS, une application d'authentification ou une biométrie sophistiquée. Pour transmettre la demande rapidement et à grande échelle, le criminel devra automatiser le processus, ce qui signifie que la demande sera transmise à l'application à partir d'un bot. (Pour un aperçu des services qui utilisent des robots pour contourner l'OTP, consultez l'article de Krebs on Security The Rise of One-Time Password Interception Bots. ) Cela signifie qu'en empêchant les robots indésirables de soumettre des informations d'identification, une organisation peut paralyser l'efficacité des proxys de phishing en temps réel et sécuriser plus efficacement les facteurs d'authentification de possession et d'inhérence.
Une autre façon évidente dont les criminels utilisent les robots pour attaquer l'AMF est le bombardement de l'AMF. Le bombardement dans ce contexte implique de générer des demandes de connexion en grand volume pour déclencher tellement de demandes d'authentification que l'utilisateur s'y conformera soit par erreur, soit simplement pour mettre fin au désagrément. Pour générer un nombre suffisamment important de requêtes pour de nombreux utilisateurs afin que l'attaque devienne rentable, le criminel devra automatiser, ce qui signifie encore une fois que les demandes de connexion parvenant à votre site seront créées par des robots.
Comme l’illustrent ces exemples, presque toutes les attaques contre l’authentification multifacteur (MFA) dépendront des robots pour réussir à grande échelle, ce qui signifie que les organisations qui mettent en œuvre l’authentification multifacteur doivent prendre au sérieux l’atténuation des robots.
Malheureusement, de nombreuses organisations ne parviennent pas à apprécier la sophistication des robots et la détermination des criminels à les rééquiper très fréquemment pour contourner la détection. Au contraire, trop d’entreprises s’appuient sur des techniques d’atténuation des robots qui ne fonctionnent plus, notamment les CAPTCHA, les listes de refus d’adresses IP et les empreintes digitales d’en-tête HTTP.
Le CAPTCHA n'a pas grand-chose à voir avec la protection contre les robots, si ce n'est qu'il ennuye les vrais clients, car les robots peuvent contourner ces énigmes en utilisant des services de résolution de CAPTCHA à faible coût qui s'appuient sur l'apprentissage automatique et les fermes de clics. Faites simplement une recherche sur le Web sur les services de résolution de CAPTCHA et vous en trouverez au moins une douzaine en concurrence en termes de prix et de rapidité. Pour une bonne lecture sur ces services, consultez un article de Dan Woods, responsable du renseignement chez F5, intitulé J'étais un résolveur de CAPTCHA humain . Encore plus intéressant, ChatGPT a réussi à contourner le CAPTCHA en utilisant l'ingénierie sociale pour inciter une personne à résoudre le CAPTCHA en son nom.
Pour les organisations qui s’appuient sur des listes de refus d’adresses IP basées sur WAF pour atténuer les robots, la tâche est tout aussi ardue. Il existe des services qui offrent aux créateurs de robots des dizaines de millions d'adresses IP résidentielles destinées à contourner la détection des robots. Ces services sont présentés comme des proxys résidentiels rotatifs ; le bot envoie des requêtes HTTP au proxy, tout comme de nombreux navigateurs d'entreprise envoient des requêtes via des proxys de transfert, et le service fait tourner en permanence l'adresse IP publique utilisée pour envoyer la requête au site Web ou à l'API. Dans le passé, les bots utilisaient généralement des proxys de centre de données, souvent issus de services cloud, qui sont bien connus et faciles à identifier. Ces nouveaux services proxy utilisent cependant des adresses IP résidentielles de la même zone géographique que vos clients. Étant donné que chaque adresse IP peut représenter simultanément un bot ou un client valide en raison du NATing des fournisseurs d'accès Internet (FAI), il n'est pas possible de bloquer toutes ces adresses IP sans détourner vos vrais clients. (Pour des recherches sur la manière dont ces services obtiennent ces adresses IP, consultez l'article Votre téléphone est mon proxy .)
Essayer de détecter les robots en fonction des différences dans l'ordre des en-têtes ne fonctionne plus non plus, car les robots ont compris le truc. En effet, plusieurs projets open source, dont stealth-puppeteer et undetected-chromedriver , parviennent à obtenir l'ordre correct des en-têtes, ce qui permet de contourner facilement les détections lors de l'utilisation de ces frameworks d'automatisation populaires.
De nos jours, la détection de robots avancés nécessite une collecte de signaux avancée, une surveillance 24h/24 et 7j/7, un apprentissage automatique et une réaction rapide au réoutillage des robots. Sans une solution de gestion des robots dédiée en place, une défense qui détecte et réagit rapidement au réoutillage, les robots permettront aux criminels de déployer efficacement des attaques contre MFA.
Presque toutes les formes d’authentification multifacteur imaginables échoueront en cas de compromission de l’application. Si l'attaquant insère du code dans une application, c'est la fin du jeu. L'attaquant peut capturer les informations d'identification et autres entrées MFA, prendre le contrôle des sessions en volant des identifiants de session ou exfiltrer des données directement depuis l'application. Étant donné que les applications Web modernes sont généralement composées de plus de 20 fichiers JavaScript , provenant principalement de tiers et non examinés par l'équipe de sécurité des applications de l'organisation, le risque de compromission des applications par le biais d'attaques de la chaîne d'approvisionnement JavaScript est plus élevé qu'on ne le pense souvent.
Les protocoles de sécurité côté client existants sont trop statiques pour défendre les applications Web dynamiques d’aujourd’hui. La politique de sécurité du contenu (CSP) restreint les actions des scripts de manière à empêcher les attaques de la chaîne d'approvisionnement JavaScript, mais la CSP pourrait trop facilement interrompre la fonctionnalité d'un site si un fournisseur tiers met à jour un script de manière dynamique d'une manière contraire aux restrictions de la CSP. Même si vous souhaitez qu’un script échoue s’il enfreint une politique de sécurité, cet échec en production pourrait avoir un impact considérable sur les clients. (Voir Pourquoi le CSP échoue-t-il ? ) L'intégrité des sous-ressources (SRI), un autre protocole de sécurité Web, est encore moins réalisable pour le contenu dynamique tiers car il nécessite la mise à jour des balises de script avec la valeur de hachage à chaque fois qu'un script change, ce qui n'est pas possible si les modifications se produisent sans préavis. En effet, le SRI est censé empêcher le type de mises à jour de scripts sur lesquelles s’appuient la plupart des applications modernes.
Sans contrôles clairs pour éliminer les vulnérabilités de la chaîne d’approvisionnement JavaScript, les organisations doivent faire preuve de créativité pour trouver des moyens de surveiller au moins le risque. Les organisations peuvent mieux documenter les scripts sur leur site et les classer en fonction des risques en fonction de la source et de la fréquence des modifications. Les scripts ajoutés via les gestionnaires de balises doivent faire l'objet d'examens réguliers pour évaluer les risques. Il est possible d'obtenir des outils de surveillance qui suivent le comportement des scripts à l'aide d'une surveillance synthétique, de CSP en mode reporting ou d'agents basés sur JavaScript exécutés dans le navigateur.
Étant donné que les scripts tiers changent très fréquemment et sans possibilité de contrôle de sécurité, il est important pour les organisations de surveiller en permanence leurs applications pour détecter tout comportement suspect, comme des scripts lisant des données sensibles et les exfiltrant vers des domaines non approuvés. Sans cette surveillance des attaques de la chaîne d’approvisionnement JavaScript, aucune forme d’authentification multifacteur ne garantira la sécurité des utilisateurs.
L’objectif de l’AMF devrait être d’améliorer la sécurité plutôt que de surcharger les clients avec un théâtre de sécurité inutile. En adaptant les exigences de connexion au risque contextuel, les organisations peuvent éviter de punir en permanence les précieux clients qui reviennent avec des exigences MFA et, au contraire, faciliter leur parcours avec des sessions utilisateur prolongées, en les accueillant avec une expérience personnalisée et sans effort, comme la façon dont la TSA accélère les voyageurs de confiance avec TSA PreCheck.
Le risque contextuel a de nombreuses dimensions :
Si l’utilisateur a fait ses preuves en matière de bon comportement et accède à un site depuis le même endroit, le même appareil, la même heure de la journée, avec un comportement similaire, en utilisant ses fonctionnalités habituelles, il n’est peut-être même pas nécessaire de demander à l’utilisateur de se connecter ; il suffit plutôt d’effectuer une authentification silencieuse continue pour prolonger la session pour la commodité de l’utilisateur. Si le contexte s'écarte de la normale, indiquant un risque plus élevé, vous avez la possibilité d'ajouter des politiques adaptatives à votre application pour augmenter les exigences de sécurité par étapes mesurées : exiger une connexion par mot de passe, exiger une authentification à deux facteurs, signaler un compte pour examen, alerter l'utilisateur par SMS ou par e-mail concernant la connexion, ou verrouiller le compte pour forcer l'utilisateur à contacter le support.
Trop souvent, la durée de la session est une période définie indépendamment du risque contextuel, permettant à toute personne disposant d'un jeton de session de continuer à accéder aux données pour lesquelles l'utilisateur est autorisé, ignorant le risque de détournement de session. Une approche plus sûre consiste à suivre les principes de confiance zéro : supposer une violation et surveiller en permanence. Si le contexte change au cours d'une session, mettez fin à la session plus tôt que prévu et exigez une authentification supplémentaire, la rigueur dépendant du degré de changement du contexte et de la sensibilité des données.
Conformément au cliché selon lequel la sécurité est un voyage, MFA a créé plusieurs bifurcations sur le chemin, offrant des options supplémentaires qui, lorsqu'elles sont mises en œuvre correctement, améliorent la sécurité de manière significative. Pourtant, aucune forme d’AMF, quel que soit le nombre de facteurs, la qualité de sa mise en œuvre et son coût, ne nous permet d’éviter le voyage qui nous mène à destination. Nous verrons certainement davantage de proclamations de la mort des mots de passe, davantage de battage médiatique autour des nouvelles techniques d’authentification multifacteur qui sécuriseront l’authentification une fois pour toutes, mais il restera des moyens pour les attaquants déterminés de contourner les nouvelles technologies.
Dans votre parcours vers une meilleure sécurisation des applications critiques, vous avez un partenaire en F5. Les services cloud distribués de F5 incluent Bot Defense pour l'atténuation des robots, Client-Side Defense pour surveiller les attaques de la chaîne d'approvisionnement JavaScript et Authentication Intelligence pour reconnaître les utilisateurs qui reviennent et quantifier le risque contextuel. Avec le support de F5, vous pouvez garantir la sécurité du MFA tout en optimisant l'expérience client. Apprenez-en davantage sur F5 Distributed Cloud Services et inscrivez-vous pour parler avec notre équipe.
Les dernières nouveautés en matière de renseignement sur les menaces applicatives.
La communauté F5 pour les forums de discussion et les articles d'experts.