Le vol de mot de passe par phishing

Le phishing est très en vogue du fait de son efficacité.
C’est une sorte de compromis entre les méthodes techniques (force brute, password spraying) et le social engineering.
Il est principalement utilisé pour le vol de mot de passe, afin d’usurper l’identité de personnes auprès de services internet, que ces derniers soient grand public ou proposés par des entreprises à leurs employés.
Le mode opératoire est simple pour le pirate : il commence par l’achat d’un nom de domaine proche du service visé et par la copie de sa page d’authentification installée sur un serveur qu’il contrôle.
Une campagne de mailing ciblée incite les victimes à se connecter au (faux) site qui leur demande de s’authentifier. Croyant être sur le service légitime, les personnes dupées saisissent leur login et leur mot de passe.
Le site retourne alors une erreur technique et conserve le mot de passe qui est utilisé par le pirate pour se connecter au vrai site.
L’élément humain assure un taux de réussite important. Tout le monde a ses moments de faiblesse, tout le monde baisse sa garde et, malgré toutes les campagnes de sensibilisation, tout le monde finit un jour par cliquer sur un lien dans un message.
Surtout que le temps est révolu où les messages de phishing étaient repérables par leur esthétique douteuse ou leurs fautes d’orthographe. De nos jours rien ne les distingue des messages légitimes.

Une première parade : un autre facteur d’authentification

Dans sa version que l’on vient de décrire, le phising fonctionne car il vole une information statique : le mot de passe qui est utilisable par le pirate jusqu’à ce que la victime en change.
Une première mesure de protection est de briser ce caractère statique, c’est-à-dire de rendre le mot de passe volé inopérant en introduisant un élément dynamique dans l’authentification.
C’est ce que l’on fait quand on passe nos comptes en 2FA (second facteur d’authentification), ce qui se fait souvent en les protégeant par un authentificateur (la plupart du temps une app Google ou Microsoft).
A la connexion, on saisit d’abord le mot passe habituel, puis un code qui s’affiche dans une app mobile. Comme ce code change très régulièrement, le pirate se retrouve avec un mot de passe valide, mais avec un code périmé qui l’empêche de se connecter.
La saisie du code matérialise un second facteur d’authentification. Le premier facteur est le mot de passe : ce qu’on sait. Le second est du type ce qu’on a. La connaissance du code affiché sur le téléphone atteste qu’on est en la possession d’un équipement qui aura été enregistré au préalable.
Les chiffres actuels annoncent d’ailleurs une protection efficace, avec des taux proches de 99%. L’ajout d’un second facteur d’authentification assure donc actuellement un niveau de sécurité satisfaisant.
Or la situation risque malheureusement de se dégrader.

La riposte des attaquants

Comme tout bon informaticien, un attaquant préfère minimiser les efforts et privilégier les cibles faciles. Tant que la grande majorité des authentifications se font par mot de passe, il n’est pas rentable de casser les authentifications plus robustes.
Mais à partir du moment où ses cibles passent en 2FA ou MFA (authentification multifacteur), un pirate est incité à s’adapter et à s’attaquer à ce qu’il a auparavant négligé.
Comme les accès critiques sont de mieux en mieux protégés, c’est ce qui est en train de se passer.
Lorsqu’il n’est plus possible de récolter des accès permanents utilisables n’importe quand, les pirates introduisent à leur tour des éléments dynamiques dans leurs attaques.
Ils ont réussi à le faire, avec actuellement deux tendances :
• le phishing à exploitation en temps réel, avec deux variantes
• la sollicitation par messagerie instantanée de type WhatsApp

Le phishing au temps du 2FA par OTP

Comme on l’a évoqué plus haut, la mesure de renforcement de l’authentification la plus répandue actuellement est l’ajout d’un second facteur : l’utilisateur saisit son mot de passe habituel et le complète par un code tournant récupéré auprès d’une app sur téléphone.
Le phishing est cependant toujours possible, en reprenant les mêmes techniques et en les adaptant.
Le pirate met en place une copie du site, y fait venir ses victimes par un message bien tourné et récupère le mot de passe ainsi que le code. Puis il affiche un message d’erreur et redirige éventuellement vers le site légitime.
Le code n’étant valide que quelques minutes, un mécanisme alerte le pirate immédiatement pour qu’il se connecte au site légitime en temps réel avec les éléments obtenus.
C’est plus contraignant car cela demande de la réactivité de sa part ; il passera à côté d’opportunités s’il n’est pas disponible au bon moment, mais le taux de réussite reste élevé.
Les attaquants ont d’ailleurs développé des consoles spécifiques pour centraliser les alertes et automatiser les opérations.

L’industrialisation par proxy

Mettre en place un faux site pour faire du phishing relève de l’artisanat. Il faut récupérer la page originale, souvent la modifier pour qu’elle fonctionne comme on le voudrait, l’installer sur un serveur, etc.
Or l’informatique étant faite pour les fainéants souhaitant automatiser au maximum, il existe évidemment des solutions pour passer au stade supérieur.
Elles se basent sur des reverse-proxy, dans le cadre d’attaques de type man-in-the-middle.
Le reverse-proxy est configuré avec un domaine proche de celui du service internet visé. Les victimes sont incitées par une campagne de mails à s’y connecter.

Dans un premier temps, le reverse-proxy se contente de rediriger les requêtes vers le site légitime.
La victime ne s’aperçoit de rien, puisqu’elle accède au vrai service. Seul le mauvais nom de domaine peut lui indiquer que quelque chose cloche.
Elle s’authentifie donc de la manière habituelle, en donnant son mot de passe et son code OTP.
Une fois l’authentification réussie, le reverse-proxy entre en action. Il intercepte le cookie de session (puisqu’il voit passer l’ensemble du trafic) et le transmet au pirate. Ce dernier l’intègre dans son navigateur et récupère donc la session ouverte légitimement par la victime.
Le pirate usurpe donc l’identité de sa victime tant que la session ouverte est valide. Pour éviter que l’utilisateur originel y mette fin en se déconnectant, le reverse-proxy peut afficher un message d’erreur à la victime juste après l’authentification et la rediriger vers le site réel.
Le projet evilginx2 est un démonstrateur de ce type d’attaque (qui ne doit évidemment en aucun cas être utilisé par des pirates pour des attaques réelles).

L’arnaque à l’OTP WhatsApp

Les méthodes précédentes présentent un défaut pour les pirates : il faut que quelqu’un soit disponible quand la victime décide de cliquer sur le lien frauduleux.
En ajoutant un peu de social engineering, un pirate peut non seulement maîtriser le moment de l’attaque, mais aussi la déclencher.
Deux prérequis sont cependant indispensables : disposer du mot de passe, qui pourra être récupéré par du phishing classique et avoir la possibilité d’entrer en contact direct avec la victime.
Le pirate ayant le mot de passe, il ne lui manque plus qu’un code OTP valide pour se connecter.
Or tous ceux qui travaillent dans la sécurité (du bon ou du mauvais côté) le savent : pour obtenir une information, il suffit généralement de la demander.
C’est exactement le principe de l’arnaque à l’OTP WhatsApp (ou toute autre messagerie instantanée).
Entre en jeu le second prérequis : avoir obtenu le numéro de téléphone ou un autre moyen de communiquer en messagerie instantanée.
Il suffit alors de se faire passer par l’opérateur du site cible et d’envoyer un message annonçant qu’un dysfonctionnement a été détecté dans l’application. Il est ajouté qu’une correction va être apportée, mais par mesure de sécurité, l’identité de la victime doit être vérifiée. Pour cela, on lui demande d’envoyer un code OTP valide.
La suite est évidente : la victime est remerciée et le code OTP est utilisé par l’attaquant pour se connecter.

Les faiblesses exploitées par les attaquants

Si les pirates peuvent déjouer certaines solutions d’authentification, c’est qu’elles présentent des faiblesses.
Leur analyse aidera à dégager les solutions d’authentifications robustes de celles qui sont faillibles.
Pour cela, repartons du besoin d’authentification : une assurance sur l’identité de la personne qui accède à un site web, c’est-à-dire sur la personne qui est derrière son navigateur.
Cette assurance découle de la communication par l’utilisateur de facteurs d’authentification : connaissance d’un secret partagé , possession d’un objet connu par le site ou caractéristique personnelle.
Le contournement de l’authentification par le phishing en temps réel et par l’arnaque WhatsApp mettent en lumière des défauts de vérification du facteur de possession par les méthodes vulnérables.
L’OTP généré par un équipement (quel qu’il soit) apporte en effet une preuve que quelqu’un est bien en sa possession. Mais on n’a pas beaucoup d’informations supplémentaires. En particulier, rien ne garantit que cette personne est celle qui accède au service.
Elle peut très bien se trouver loin du navigateur et communiquer le code à un tiers. C’est exactement ce qu’exploitent les pirates.
L’OTP n’est en effet qu’une assurance qu’une personne quelque part dispose d’un objet connu, mais en aucune façon que cette personne soit en train s’authentifier à un service internet.
Avec l’OTP par app mobile, la vérification d’identité d’un utilisateur se connectant à un service devient donc biaisée car elle repose sur :
• un facteur de connaissance qui peut être volé (le mot de passe)
• le fait que le propriétaire du compte est en possession d’un objet particulier,
On parle bien du propriétaire du compte, or on ne vérifie en rien que la personne qui tente de s’authentifier est bien ce propriétaire.

Ne pas se faire voler son identité

Si le phishing en temps réel et l’arnaque WhatsApp exploitent des défauts des méthodes d’authentification, le phishing avec proxy de vol de session est plus sophistiqué.
La phase d’authentification se passe correctement : le service internet vérifie bien l’identité du propriétaire du compte.
La vulnérabilité exploitée est de type man-in-the-middle, c’est-à-dire l’interception des communications entre la victime et le service internet.
Cette technique est rendue possible par le défaut dans une autre authentification : celle que l’utilisateur du service doit réaliser pour être sûr qu’il se connecte au service légitime. C’est exactement cette défaillance des utilisateurs qui rend possible le phishing classique : l’URL dans la barre des navigateurs n’est pas correcte et l’utilisateur ne s’en rend pas compte.
Ce n’est donc pas une déficience de la méthode d’authentification qui est en cause, mais la protection contre les interceptions des connexions qui présente une faille. Cette protection repose sur l’établissement d’une liaison sécurisé s’appuyant sur trois éléments :
• son chiffrement
• l’authentification de l’utilisateur par le service internet
• l’authentification du service internet par l’utilisateur
Avec l’attaque au reverse-proxy, la liaison ne répond pas aux critères de sécurisation, puisqu’elle est composée de deux connexions chiffrées (et non d’une seule), et que l’utilisateur n’a pas correctement authentifié le service internet.
On a ici une illustration que la méthode d’authentification n’est pas le seul aspect à soigner dans le contrôle de l’identité.
La phase de vérification effective se déroule correctement avec 2 facteurs, mais l’identité peut être volée.
On verra d’ailleurs plus loin que la phase d’authentification doit être considérée comme un ensemble et non par le prisme particulier des facteurs.

Ce qui fait la force d’une authentification

Maintenant qu’on en sait plus sur les raisons pour lesquelles certaines authentifications sont vulnérables au phishing, il est temps de se pencher sur les critères de robustesse d’une authentification.
Pour commencer par des banalités : une authentification forte est une authentification qui ne peut être exploitée par un attaquant.
Quant à la caractériser de manière rigoureuse, c’est compliqué. On a vu d’ailleurs que cela a changé au cours des années (l’OTP était considéré jusque récemment par l’archétype de l’authentification forte). Il est même contraire aux principes de la sécurité que d’énoncer ce que des pirates ne seraient jamais capables de faire. Le temps finit souvent par apporter un démenti.
On peut toutefois dessiner des grandes lignes d’une hiérarchie, et dans cet objectif s’avancer sur les traits suivants :
• reprendre la combinaison de plusieurs facteurs différents de la définition initiale
• requérir que ces facteurs soient communiqués directement par le même navigateur
• intégrer des mécanismes intrinsèques empêchant les interceptions, que ce soit des facteurs ou d’autres éléments (la session applicative en particulier)
Les conditions ajoutées visent à s’assurer que l’authentification concerne bien la personne derrière son navigateur.
Pour cette raison, et contrairement à d’autres domaines de la sécurité, on proscrit la communication des facteurs par des canaux différents (Out-of-Band) car il est facile que ces canaux n’aient pas la même origine, comme l’atteste l’arnaque WhatsApp.
La notion d’interception n’est pas circonscrite au man-in-the-middle, mais à toutes les occasions de détournement. Ainsi toute saisie manuelle peut être récupérée, soit lors de sa transmission (par phishing), soit par une autre communication (arnaque WhatsApp).
Pour aller plus loin, on peut considérer que si l’utilisateur a la possibilité d’accéder à l’information utilisée pour la vérification de son identité, elle pourra fuiter vers un pirate.
Par exemple une preuve de possession pourrait être matérialisée par le dépôt d’un identifiant dans un espace de stockage du navigateur (localStorage). Or ces informations sont consultables par le mode « développeur ». Un pirate pourrait trouver un moyen de convaincre une victime de réaliser des opérations pourtant compliquées pour se faire envoyer ce secret.

Portrait robot d’une authentification robuste

Après cette tentative de caractérisation d’une authentification forte, on s’aventure à imaginer à quoi elle pourrait ressembler.
Elle se baserait évidemment sur du HTTPS, mais sur une unique liaison qui fait passer tous les facteurs. De plus, la solution d’authentification intégrerait des mécanismes d’identification des parties empêchant les ruptures de la liaison.
On se prémunis ainsi contre certains types d’interception et on a une assurance que tous les facteurs ont la même origine.
Un objectif est évidemment qu’il ne soit pas possible d’insérer un reverse proxy pour voler des informations. Pour cela, l’authentification doit être liée à la liaison HTTPS pour empêcher qu’il soit possible de copier des informations d’une connexion à une autre.
Le facteur de possession serait attesté par un échange cryptographique asymétrique, dont la clé privée ne serait accessible par personne (aucune possibilité d’export).
On a ainsi une garantie que l’objet en question est attaché au navigateur et que l’on authentifie bien la personne qui accède au site.
La session applicative passerait par cette même liaison HTTPS (même cookie de session) ou hériterait de l’authentification par un jeton sécurisé, ne transitant pas par le navigateur.
On rend de ce fait (théoriquement) impossible le vol de session.
Comme dans tout système sécurisé, la cryptographie jouerait donc un rôle central.

Evaluation des technologies

Maintenant qu’on y voit plus clair sur les niveaux de sécurité des méthodes d’authentification, il est temps d’analyser les méthodes que l’on a à disposition.
On va toutefois le faire uniquement pour les catégories les plus répandues.
OTP par saisie manuelle d’un code (calculettes, logiciels et apps) : on a vu que ces authentifications étaient vulnérables pour toutes les méthodes présentées.
Envoi d’un SMS : il s’agit toujours de saisir manuellement un code, on rencontre donc les mêmes limites qu’avec l’OTP.
Push dans une app mobile : ces méthodes sont vulnérables au proxy, de type evilginx2 mais aussi à l’arnaque WhatsApp. Il en existe des plus sophistiquées où il faut sélectionner un code affiché à l’écran, mais sans grandes conséquences malheureusement sur l’élévation de la sécurité.
QR code vérifié dans une app mobile : niveau de sécurité identique aux app de type push.
Secret enregistré dans le navigateur : le secret n’est utilisable que lorsque le navigateur est connecté directement au site légitime. On a donc une sécurité satisfaisante au phishing, même si un pirate pourrait demander à l’utilisateur de lui envoyer le secret en lui indiquant la procédure adéquate. On notera aussi souvent une vulnérabilité à l’injection Javascript (XSS).
Certificat client (sans carte à puce) : c’est la connexion HTTPS qui est authentifiée, avec donc une certaine résistance au phishing. La clé privée résidant sur le poste, un pirate pourrait toutefois réussir à la récupérer par social engineering.
Carte à puce : authentification par certificat client, mais la clé privée est inaccessible, ce qui lui donne une résistance optimale au phishing.
Clé USB à la norme FIDO2 : le modèle de sécurité se rapproche de la carte à puce, avec une protection équivalente de la clé privée. La méthode se prémunit contre les proxy en intégrant l’URL du site dans la réponse, avec vérification d’intégrité, rendant inopérante la copie de données par le reverse proxy. La réponse reçue par le site légitime contiendra en effet l’adresse du proxy.
Dans tous les cas, il est recommandé qu’aucune information exploitable ne soit saisie par l’utilisateur dans un formulaire web, car elle sera facilement récupérable par phishing. Ce serait une première ligne de défense qui tomberait, laissant les pirates se concentrer sur les autres mécanismes de protection.

Comment faire le bon choix ?

L’objet du présent article n’est pas de prescrire telle ou telle solution d’authentification.
Comme toujours, il n’est pas possible de préconiser quoi que ce soit en sécurité sans une analyse du contexte et des risques.
Surtout qu’on rappelle que n’importe quelle solution de 2FA assure actuellement une protection correcte dans l’immense majorité des cas.
Ensuite, une solution vulnérable au phishing pourra convenir à certains contextes qui ne sont pas sensibles à ce type d’attaque.
Inversement, une méthode très sécurisée entrainera dans d’autres contexte des contraintes en restreignant l’adoption par les utilisateurs, voire même en interdisant le déploiement.
Le conseil que l’on tente de dégager, c’est de prendre conscience que l’affirmation « il suffit de déployer du MFA ou du 2FA pour tout sécuriser » relève de la paresse intellectuelle.
La réalité est bien plus nuancée.
Et on espère que cet article concourra à faire des choix mieux éclairés de solutions d’authentification renforcée.

La méthode de vérification des authentifications n’est qu’un des aspects du problème

En parlant justement de choix, il ne faut pas oublier que la problématique de l’authentification ne se limite pas au mécanisme de vérification de l’identité.
Comme dans les autres domaines de la sécurité, le niveau de sécurité réel est celui de son maillon le plus faible.
En authentification, la chaîne est composée non seulement de la méthode de vérification, mais aussi
• du processus d’enregistrement des utilisateurs (enrôlement)
• de la gestion de l’oubli du dispositif
• de celui de sa perte
Un logiciel spécialisé dans l’authentification supporte par exemple une authentification par OTP, mais pour s’enregistrer il suffit de disposer d’un mot de passe. De fait, la connaissance d’un mot de passe suffit pour s’authentifier. La méthode d’authentification est bien du 2FA, mais la sécurité globale du dispositif est dégradée à celle d’un unique mot de passe.

Ce type de vulnérabilité a d’ailleurs été exploité dans la nature. Une solution d’authentification forte était déployée pour les accès VPN d’une organisation, mais elle se désactivait automatiquement pour les comptes ne s’étant pas récemment authentifiés. Or pour se réenregistrer, un simple mot de passe suffisait. Les attaquants ont réussi à découvrir un compte actif, à MFA désactivée, protégé par un mot de passe faible. Ils ont pu s’enregistrer auprès de la MFA et ont pénétré le réseau grâce à cet accès.
Finalement, il faut tenir compte du facteur humain. Des méthodes d’authentification perçues comme trop complexes par rapport aux enjeux de sécurité encouragent les utilisateurs à trouver des méthodes de contournement. Il n’est pas rare de découvrir dans les open space des dispositifs MFA bien en évidence, avec le code PIN noté sur un post-it, pour que chacun puisse se connecter à un système sécurisé.
Le contournement ultime étant d’ailleurs le refus de la connexion au service.
Tous ces aspects doivent être pris en compte dans le choix de la méthode d’authentification.

 

Auteur : Marc (Directeur technique)