La plupart des organisations victimes d’une compromission l’an dernier avaient l’authentification multifacteur activée. C’est la partie dérangeante. Les attaquants n’ont pas cassé le second facteur : ils l’ont contourné, à l’aide de techniques qui fonctionnent précisément 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 intègrent à leur plan de contournement, et non celles qui les arrêtent.
Trois attaques qui déjouent « un peu de MFA »
- Push-bombing (lassitude MFA). 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 la victime 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. C’est ainsi qu’ont commencé plusieurs compromissions retentissantes.
- 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 et son code ; l’attaquant transmet les deux instantanément et vole le jeton de session qui en résulte. Le code était valide. Le MFA a « fonctionné ». Le compte est perdu malgré tout.
Le fil conducteur : chacune de ces méthodes repose sur un secret ou une approbation qui peut être relayé, c’est-à-dire copié depuis l’utilisateur légitime, puis rejoué par l’attaquant. Coupez le relais et les trois attaques s’arrêtent avec lui.
Ce qui les arrête vraiment : une authentification résistante au phishing et liée au matériel
« Résistant au phishing » n’est pas un argument marketing : c’est le nom d’une propriété précise. Deux conditions doivent être réunies en même temps : la clé ne peut jamais quitter l’appareil de l’utilisateur, si bien qu’il n’y a rien à capturer ni à réutiliser ; et l’utilisateur peut lire exactement ce qu’il approuve, si bien que rien n’est approuvé à l’aveugle.
- La clé réside dans le matériel sécurisé du téléphone. Elle y est générée et ne peut être ni exportée, ni copiée, ni transférée par SIM swap. Aucun secret partagé ne dort dans une base de données ni n’arrive par SMS, et c’est ce qui ferme la porte à l’interception, au SIM swap et au relais AiTM.
- Vous pouvez lire exactement ce que vous approuvez. C’est ce qui arrête le push-bombing, et il faut être précis sur ce point : 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 déjoue le push-bombing, c’est que chaque demande porte une description spécifique et lisible de ce qui est exactement approuvé : cette connexion, ce serveur, depuis ici, maintenant. Une demande que l’utilisateur n’a jamais lancée n’est visiblement pas la sienne, et il la refuse. Le rempart, c’est une description assez précise pour être lue d’un coup d’œil, et non un humain fatigué qui résiste à un « Approuver ? » sans contexte.
- La session ne peut pas être rejouée. Parce que la signature est cryptographique et liée à la demande, un proxy AiTM n’a rien qui vaille la peine d’être volé.
Voilà toute la différence entre un MFA qui relève le niveau et un MFA qu’un attaquant a déjà appris à contourner par script.
Où Notakey intervient
Notakey a été conçu autour de cette propriété exacte. La clé de l’utilisateur est générée dans le matériel sécurisé de son téléphone et ne le quitte jamais, et chaque approbation est un enregistrement signé et horodaté de l’action précise, et non un tap anonyme.
- Aucun secret partagé à hameçonner, aucun SMS à intercepter, aucun code à relayer.
- Face au push-bombing, la défense tient à ce que l’utilisateur lit : chaque demande affiche une description précise de ce qui est exactement approuvé (quel système, quelle action, depuis où), de sorte qu’une demande que personne n’a lancée saute aux yeux et se voit refusée. Il n’y a rien à approuver à l’aveugle.
- Elle couvre les chemins que les attaquants empruntent réellement : voyez les guides pratiques sur le 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 à la manière résistante au phishing : en lisant et en signant une action précise depuis votre propre téléphone, plutôt qu’en tapotant 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 ferons correspondre vos connexions VPN, SSO ou Windows à un pilote sur votre propre infrastructure.