MFA fatigue et push bombing : quand l'invite d'approbation devient l'attaque
L'authentification multifacteur fonctionne mieux quand le second facteur exige un geste délibéré. Une invite d'approbation push exige bien moins : un simple appui. Les attaques par MFA fatigue — aussi appelées push bombing — exploitent cet écart. Un attaquant qui détient déjà un mot de passe valide déclenche des tentatives de connexion à répétition, saturant le téléphone de la cible de demandes d'approbation jusqu'à ce que l'une soit acceptée, par réflexe, par agacement, ou dans l'espoir qu'approuver fasse enfin cesser les notifications.
Comment se déroule une attaque par push bombing
Le schéma est constant dans les cas documentés par les équipes de sécurité. L'attaquant part d'identifiants volés ailleurs — les logs d'infostealers vendus en masse sont une origine courante — et vérifie que le mot de passe fonctionne encore. Il déclenche ensuite des tentatives de connexion répétées, générant des notifications push sur l'appareil enregistré de la victime. Chaque invite est identique à une invite légitime, et des années d'approbations quotidiennes anodines ont appris à beaucoup d'utilisateurs à approuver presque sans réfléchir. Les campagnes ajoutent souvent une seconde couche : un appel ou un message de quelqu'un qui se fait passer pour le support informatique, enjoignant la cible d'accepter les invites pour qu'elles cessent. Côté utilisateur, c'est déroutant par conception. L'invite se présente comme si l'utilisateur avait lui-même lancé la connexion, mais rien dans la notification ne prouve qui l'a déclenchée. En principe, l'invite est un contrôle de sécurité ; en pratique, c'est un message sur votre écran que quiconque détient votre mot de passe peut générer, puis régénérer, jusqu'à ce que la fatigue fasse le reste. Traiter une telle invite comme une entrée non fiable, c'est précisément le réflexe que ces attaques contournent.Uber, septembre 2022 : le cas d'école
L'exemple le plus cité reste la violation d'Uber de septembre 2022. Comme l'a rapporté TechCrunch, Uber a attribué l'intrusion à un pirate affilié à Lapsus$ et indiqué que le mot de passe professionnel d'un prestataire externe avait pu être acheté sur un marché du dark web, vraisemblablement issu de logs du malware infostealer RedLine. Le mot de passe seul ne suffisait pas, car le compte exigeait un second facteur. L'attaquant a déclenché des invites push pendant plus d'une heure, puis a contacté le prestataire sur WhatsApp en se faisant passer pour l'IT d'Uber, lui affirmant que les notifications cesseraient une fois acceptées. Le résultat, le pirate l'a ensuite résumé à TechCrunch en une phrase :And well, he accepted and I added my device.Avec cette approbation, l'attaquant a enregistré son propre appareil pour la MFA et est entré dans le réseau interne d'Uber via le VPN. Comme l'a documenté BleepingComputer, l'accès s'est vite étendu : un message annonçant la violation est apparu sur le Slack d'Uber, et l'attaquant a atteint des consoles cloud, le domaine Windows et les tickets HackerOne de l'entreprise, téléchargeant selon les rapports des rapports de vulnérabilités privés avant que l'accès ne soit coupé. Sur un partage réseau, un script PowerShell exposait des identifiants d'administration de la plateforme d'accès privilégié d'Uber. La couverture de TechCrunch notait que le number matching n'était vraisemblablement pas activé là où cela comptait.
Cisco : le même levier, autrement
L'équipe de réponse aux incidents de Cisco, Talos, a documenté un cas parallèle la même année. Le 24 mai 2022, Cisco a découvert une compromission qui commençait par le compte Google personnel d'un employé, où s'étaient synchronisées des informations d'identification professionnelles enregistrées dans Chrome. L'attaquant a combiné des appels de vishing en se faisant passer pour une organisation de support de confiance avec des demandes push MFA répétées, jusqu'à ce que l'une soit acceptée, donnant accès au VPN. Talos a estimé, avec une confiance modérée à élevée, que l'acteur était un courtier en accès initial lié à UNC2447, à Lapsus$ et aux opérateurs du ransomware Yanluowang, et a décrit une activité pré-ransomware : l'accès d'abord, la monétisation ensuite. Deux violations, même porte : l'invite push, approuvée sous pression.Number matching et l'échelle des mesures d'atténuation
Les mesures d'atténuation sont bien comprises. Les orientations de la CISA sont sans détour : « la MFA résistante au phishing est le standard que tous les leaders du secteur devraient viser, mais toute MFA vaut mieux que pas de MFA ». L'agence cite FIDO/WebAuthn comme seule option résistante au phishing largement disponible et, quand ce n'est pas possible, recommande « la MFA avec correspondance de nombres pour bloquer le bombardement push mobile ». Microsoft a depuis fait du number matching la norme pour ses notifications push Authenticator : l'écran de connexion affiche un nombre, et l'approbation exige de saisir ce nombre dans l'application. Une invite hors contexte n'a pas de nombre à saisir — c'est exactement pourquoi la technique déjoue l'approbation aveugle.- Traitez chaque invite inattendue comme une entrée non fiable : refusez-la, signalez-la et changez le mot de passe qu'elle testait.
- Préférez les facteurs qui exigent une action délibérée — codes d'authenticator ou clés matérielles — au push simple d'un appui.
- Ne synchronisez jamais d'identifiants professionnels ou sensibles dans un profil de navigateur personnel ; l'attaquant de Cisco est entré par cette brèche.
- Réservez les clés de sécurité matérielles aux comptes qui comptent le plus ; selon TechCrunch, ce sont elles qui ont tenu chez Cloudflare face à une attaque similaire.