Lassitude MFA (MFA fatigue), push-bombing et 2FA bombing : comment les attaquants contournent votre second facteur

En septembre 2022, un attaquant qui avait acheté le mot de passe d’un prestataire d’Uber a tenté de se connecter encore et encore. Chaque tentative envoyait au prestataire une demande d’approbation du second facteur. Les premières ont bloqué l’attaquant. Puis l’une d’elles a été acceptée, et l’attaquant est entré (communiqué de sécurité d’Uber). Un mois plus tôt, Cisco avait décrit le même schéma dans sa propre compromission : des appels vocaux d’une personne se faisant passer pour le support, et un flot de notifications push jusqu’à ce qu’un employé en accepte une (Cisco Talos).

Les deux entreprises avaient activé l’authentification multifacteur. Les attaquants n’ont pas cassé le second facteur : ils l’ont contourné, à l’aide de techniques qui fonctionnent parce que le MFA en place demande à un humain fatigué de prendre une décision de sécurité au pire moment possible.

Si votre MFA repose sur un code SMS ou sur une notification « Approuver ? » en un tap, ces dix minutes de lecture en valent la peine. Ces deux méthodes sont désormais celles que les attaquants prévoient de contourner, et non celles qui les arrêtent.

Trois attaques qui déjouent « un peu de MFA »

• Push-bombing (lassitude MFA, MFA bombing, 2FA bombing). L’attaquant possède déjà le mot de passe, issu d’une fuite, d’un hameçonnage ou d’une réutilisation. Il déclenche connexion sur connexion, faisant pleuvoir un flot de demandes d’approbation sur le téléphone de l’utilisateur jusqu’à ce que, par confusion ou simplement pour que cela cesse, quelqu’un appuie sur Approuver. Un seul tap et l’accès est ouvert.
• SIM swap. Le SMS n’a jamais été conçu comme un canal de sécurité. Un attaquant qui convainc (ou soudoie) un opérateur mobile de transférer un numéro vers une nouvelle carte SIM reçoit chaque code à usage unique qui y est envoyé. Pas de logiciel malveillant, pas de page d’hameçonnage : un simple appel à un service client.
• Adversaire intercepteur (AiTM). Une fausse page de connexion convaincante relaie la vraie en temps réel. La victime saisit son mot de passe, le vrai système demande le second facteur, et la victime le fournit, puisqu’elle essaie réellement de se connecter. Le proxy de l’attaquant récupère la session qui en résulte. Le MFA a « fonctionné ». Le compte est perdu malgré tout.

L’agence américaine de cybersécurité CISA cite ces trois attaques dans ses recommandations et trace une ligne claire : seules l’authentification FIDO/WebAuthn et l’authentification à clé publique (PKI) sont considérées comme résistantes au phishing, car la clé est liée à l’adresse du vrai site et une page imitée ne peut pas s’en servir. L’approbation par notification push, même avec saisie d’un numéro de correspondance (number matching), ne figure pas sur cette liste (fiche de la CISA).

Ce qui arrête chacune d’elles

Ces attaques n’ont pas les mêmes points faibles ; il vaut donc la peine d’être précis sur ce qui déjoue quoi.

• SIM swap et interception de code : supprimer le code. Si la clé de l’utilisateur est générée dans le matériel sécurisé du téléphone et ne le quitte jamais, aucun secret partagé ne dort dans une base de données et rien n’arrive par SMS. Il n’y a rien à intercepter, et transférer un numéro de téléphone ne transfère rien dont un attaquant puisse se servir.
• Push-bombing : permettre à l’utilisateur de lire ce qu’il approuve. Une fois qu’une demande atteint le téléphone, ni la clé ni la biométrie n’y peuvent rien, car l’attaque se contente de demander à l’utilisateur de dire oui. La biométrie confirme seulement que c’est bien le propriétaire du téléphone qui appuie, pas que la connexion est légitime. Ce qui fonctionne, c’est une demande qui porte une description spécifique et lisible de ce qui est exactement approuvé : quel service, quelle action, depuis où. Une demande que l’utilisateur n’a jamais lancée n’est visiblement pas la sienne, et il la refuse. L’expiration des demandes et la limitation de la fréquence à laquelle elles peuvent être déclenchées privent l’attaque du volume dont elle dépend.
• Adversaire intercepteur : l’approbation seule ne suffit pas. Ici, l’utilisateur n’est pas amené à approuver la connexion de quelqu’un d’autre. Il approuve la sienne, mais sur le mauvais site. Ce qui aide, c’est de montrer d’où vient la demande : si l’approbation indique l’adresse d’où provient la connexion, un proxy situé dans un autre pays saute aux yeux d’un utilisateur attentif. Cela augmente le coût de l’attaque ; cela ne la rend pas impossible. Lorsque le modèle de menace exige une résistance au phishing au sens strict, la réponse réside dans des clés FIDO liées au site, associées à des durées de session courtes et à des politiques de connexion qui limitent les endroits où les sessions peuvent être utilisées.

Voilà toute la différence entre un MFA qu’un attaquant a déjà appris à contourner par script et un MFA qui rend chacune de ces attaques visible ou inutile.

Où Notakey intervient

Notakey supprime le code et rend chaque approbation lisible.

• La clé de l’utilisateur est générée dans le matériel sécurisé du téléphone et ne le quitte jamais. Aucun SMS à intercepter, aucun code à relayer.
• La notification n’est qu’une sonnette. Lorsque l’utilisateur ouvre l’application, celle-ci récupère la carte d’approbation via HTTPS auprès du serveur auprès duquel elle a été enrôlée : ce que l’utilisateur lit provient donc de votre serveur, et non de la notification, et sa signature porte sur cette demande précise.
• Face au push-bombing, la défense tient à ce que l’utilisateur lit : la carte indique quel service fait la demande et ce qui est approuvé, de sorte qu’une demande que personne n’a lancée saute aux yeux et se voit refusée. Les demandes expirent, et un limiteur intégré plafonne la fréquence à laquelle elles peuvent être déclenchées, ce qui coupe court au flot de notifications sur lequel l’attaque compte.
• Face à l’adversaire intercepteur, le serveur peut être configuré pour afficher sur la carte l’adresse IP à l’origine de la demande, le nom du service ou l’URL, afin que l’utilisateur voie d’où provient réellement la connexion. Nous ne prétendrons rien de plus : cela rend un proxy visible pour un utilisateur attentif ; cela ne rend pas l’attaque impossible.
• Notakey couvre les chemins que les attaquants empruntent réellement : consultez les guides pratiques sur la 2FA sur un VPN via RADIUS, le bureau à distance Windows et le SSH Linux.

Voyez par vous-même

Le moyen le plus rapide de ressentir la différence, c’est d’approuver une transaction que vous pouvez réellement lire : une action précise, signée depuis votre propre téléphone, plutôt qu’une demande sans contexte.

Essayez la démo en ligne pour en signer une en deux minutes environ, ou demandez une démo et nous monterons un pilote couvrant vos connexions VPN, SSO ou Windows sur votre propre infrastructure.