À mesure que de plus en plus de sites web, et donc d'internautes, optent pour l'authentification à deux facteurs (2FA), de plus en plus de sites web d'hameçonnage (phishing, en VO) utilisent des kits permettant d'automatiser la récolte des informations d'identification et des cookies de session. Plus de 1200 ont été identifiés l'an passé.
Un groupe de chercheurs de l'Université Stony Brook et de Palo Alto Networks a identifié, entre mars 2020 et mars 2021, 1 220 sites Web de phishing utilisant des kits d'attaques de l'homme du milieu (HDM) ou man-in-the-middle attack (MITM) afin de capturer les codes de sécurité d'authentification à deux facteurs (2FA, en anglais) reçus par e-mail, SMS ou application dédiée.
Agissant à la manière de serveurs proxy inverse (reverse proxy, en VO), qui relayent le trafic entre la victime, le site de phishing et le service légitime, ils affichent en effet le contenu des services en ligne qu'ils usurpent, tout en automatisant la récolte des informations d'identification et des cookies de session en transit.
Ironiquement, souligne The Record, bon nombre de ces boîtes à outils de phishing MitM sont basées sur des outils développés par des chercheurs en sécurité, tels que Evilginx, Muraena et Modlishka. Les chercheurs, en l'espèce, ont analysé 13 version de ce genre de kits.
The Record relève également que ce chiffre représenterait « un bond significatif par rapport aux quelque 200 sites de phishing exécutant des proxys inversés qui étaient actifs fin 2018 et début 2019 » :
« Une raison pour laquelle ils l'ont fait peut également être liée au fait que la plupart sont téléchargeables gratuitement, faciles à exécuter, et qu'il existe de nombreux tutoriels et demandes de collaboration sur les forums de piratage qui ont aidé les acteurs de la menace à se familiariser avec cette nouvelle technologie. »
Un angle mort dans les listes de blocage de phishing
Pour étudier les effets réels des attaques de phishing MITM et comparer les performances de leur infrastructure de détection à une solution de détection de phishing commerciale, les chercheurs se sont associés à Palo Alto Networks (PAN) :
« 57,6 % des domaines de phishing MITM découverts par notre infrastructure ont été étiquetés comme étant explicitement malveillants ou hautement susceptibles d'être malveillants par les scanners PAN. De plus, parmi les domaines répertoriés comme tels, 15,1 % ont reçu leur étiquette respective au moins une semaine après que notre infrastructure l'ait découverte. »
PAN leur a également fourni des statistiques sur le nombre de ses clients qui avaient visité chaque site Web de phishing MITM. Sur une période de 6 mois, ils ont capturé 6 403 demandes dirigées vers 260 des 1220 sites Web identifiés, enregistrées à partir de 368 pare-feu distincts :
« En moyenne, chaque site Web d'hameçonnage MITM a reçu 25 demandes (telles qu'enregistrées par le middleware de PAN), le site le plus populaire recevant 4 728 demandes de leurs clients. »
Les chercheurs à l'origine de cette étude estiment que ces kits d'outils de phishing MITM « occupent un angle mort dans les listes de blocage de phishing, avec seulement 43,7 % des domaines et 18,9 % des adresses IP associés présents sur les listes de blocage » répertoriées par VirusTotal, laissant les utilisateurs sans méfiance vulnérables à ces attaques.
De plus, il fallait en moyenne sept jours après que leurs robots d'exploration découvrent un site Web de phishing MITM pour que ces URL soient étiquetées comme telles par les listes de blocage de domaine :
« C'est nettement plus long que les campagnes de phishing traditionnelles, dont des travaux antérieurs ont montré qu'elles sont détectées par des listes de blocage après seulement neuf heures. »
En outre, seulement 18,9 % des adresses IP associées aux kits d'outils de phishing MITM apparaissaient sur au moins une liste de blocage IP signalée par VirusTotal. Cela suggèrerait que les attaquants utilisent de nouvelles adresses IP et de nouveaux domaines pour lancer des attaques et se déplacer rapidement avant qu'ils ne soient découverts.
Les trois marques les plus ciblées : Instagram, Google, Facebook
La plupart de ces sites étaient situés en Amérique du Nord et en Europe, qui accueillent une forte concentration d'hébergeurs populaires. Ce qui permet aux attaquants de lancer et supprimer rapidement leurs sites malveillants.
En outre, ces boîtes à outils cherchant à usurper l'identité de sites Web réels, leur localisation sur une infrastructure d'hébergement Web populaire pourrait déjouer les scanners de sécurité qui recherchent des sites Web hébergés dans des systèmes autonomes de mauvaise qualité.
Plus de 40 % des sites analysés restent en ligne pendant plus d'un jour, et environ 15 % plus de 20 jours. 339 (27 %) des domaines associés étaient co-localisés sur la même adresse IP qu'un domaine bénin, et 23 domaines avec au moins un autre domaine étiqueté comme malveillant par les listes de blocage de domaines signalées par VirusTotal :
« Cela indique que les attaquants acquièrent généralement une infrastructure dédiée, ou réutilisent une infrastructure malveillante existante, pour leurs campagnes plutôt que de compromettre des domaines existants. »
Les chercheurs ont découvert 19 marques ciblées, et qu'un sous-ensemble de marques est ciblé « de manière disproportionnée » : les trois marques les plus ciblées (Instagram, Google, Facebook) représentent en effet 61 % de l'ensemble des sites Web de MITM phishing.
Les noms de domaine associés se répartissent en trois catégories : le combosquatting (par exemple, paypalhelp.com), l'intégration de la marque en sous-nom de domaine (par exemple, login.paypal.com.attacker.com) et le typosquatting (par exemple, paypl.com).
Un outil, PHOCA, pour analyser et détecter le phishing MITM
Les chercheurs expliquent s'être concentrés sur deux catégories de fonctionnalités au niveau du réseau pour distinguer les kits d'outils de phishing MITM des serveurs Web bénins : les fonctionnalités de synchronisation du réseau et les empreintes digitales des certificats TLS.
Ils ont ensuite développé un outil pour collecter automatiquement des données et classer les kits d'outils de phishing MITM sur le Web. Les phoques étant des mammifères aquatiques connus pour chasser des proies cachées en utilisant les vibrations générées par leur respiration, ils l'ont appelé PHOCA :
« De la même manière que cette technique de chasse, PHOCA peut détecter des boîtes à outils de phishing MITM précédemment cachées en utilisant des fonctionnalités inhérentes à leur nature, par opposition aux indices visuels. »
Il suffit de lui fournir une URL ou un nom de domaine : PHOCA sonde le serveur Web pour déterminer s'il s'agit d'une boîte à outils de phishing MITM. À l'aide de cet outil, de nouvelles données d'entraînement peuvent être facilement générées pour toute future itération de la boîte à outils de phishing MITM.
Les résultats de leur analyse montrent que « notre système de détection est résilient aux mécanismes de dissimulation incorporés par ces outils et est capable de détecter le contenu de phishing précédemment caché » :
« Enfin, nous proposons des méthodes que les services en ligne peuvent utiliser pour identifier les requêtes provenant de ces boîtes à outils et arrêter les tentatives de phishing lorsqu'elles se produisent. »
Commentaires (24)
#1
ÇA c’est de l’information !
J’ai une idée : On pourrait identifier l’autorité de certification qui a délivré un certificat pour le site de phishing et le mettre sur une liste noire… non ? Comment se fait-il qu’on puisse se connecter en https sur un site de phishing sans avoir d’avertissement ?
A moins que ça se complique avec les certificats let’s encrypt…
#2
Comme c’est dit dans l’article, il y a du typosquatting et autres astuces qui permettent d’avoir un certificat valide (oui, notamment signé par Let’s Encrypt, mais pas que).
#3
Effectivement, l’extension de l’usage du multifacteur va générer l’extension de méthodes de contournement par les fraudeurs. J’ai parcouru (en diagonale) le document original, mais il me paraît un peu insuffisant, au sens où il manque certaines précisions ou certaines conditions.
Tout d’abord les MITM ne sont pas les seules formes d’attaques contre les 2FA : des malwares comme TinyNuke utilisent depuis longtemps (hélas) du MITB (Man In the Browser), c’est-à-dire que le “proxy” est localement installé sur le poste de la victime. Mais c’est un détail. Plus important : le papier n’indique pas clairement les vrais enjeux ni les moyens de sécurité impliqués. En effet, je crois comprendre que, du côté des MFA, sont visés les facteurs d’authentification où l’utilisateur doit saisir un code de vérification (SMS, Google Authenticator, etc.). Ces moyens sont en effet sensibles à ces attaques, mais pas d’autres dispositifs comme FIDO où même un attaquant en position intermédiaire ne peut rien faire dans le cas d’une authentification (ça n’est pas la même chose dans le cas de la validation d’une transaction, par exemple, mais c’est assez long à expliquer).
Donc les facteurs visés et attaquables sont ceux où l’utilisateur doit saisir un code de confirmation sur le même canal et non sur un canal distinct (ce qui est plus sûr, bien que plus complexe à mettre en œuvre).
Sinon, le second levier est le vol du cookie. Et là, quelle que soit la méthode d’authentification, même la plus parfaite, celui qui détient le cookie (d’authentification) détient le pouvoir. Donc une attaque MITM qui peut voler le cookie peut donc attaquer quasiment n’importe quel système d’authentification, mais le problème réel ne sera pas forcément dans l’authentification elle-même mais dans cette gestion du cookie qui est le point le plus critique. Et là, ce n’est plus le 2FA qui est en cause, mais le cookie.
#4
Le dernier phishing en date avec boulanger.com utilisait un certificat let’s encrypt (en plus d’une copie parfaite du site web d’origine)
#5
#6
Il ne suffirait pas que l’utilisateur signe ses identifiants (et l’adresse visitée) avec sa clé privée ?
Il n’y aurait même plus besoin de 2FA…
#6.1
Cela implique trois choses: (I) que tous les clients possède une biclef, et dont probablement un certificat X509. Ce qui est complètement déraisonnable a l’échelle de l’Internet; (ii) que les clients recourent à un système de tiers de confiance (autorité de certification) qui rend impossible toute idée de pseudonymisation (à la plus grande joie des états policiers et/ou autocratiques), et (iii) que les serveurs ré-authentifient (cryptographiquement) le client a chaque requête HTTPS. Ce qui augmenterait la charge des systèmes d’authentification de plusieurs ordres de grandeur et ralentirait d’autant le Web dans son ensemble.
C’est pas demain la veille et c’est tant mieux XD
#6.2
#6.3
Je ne suis pas sûr que la grande majorité des utilisateurs se rendent compte de l’importance d’une clé privée.
De plus installer de façon sécurisée une clé privée sur les PC/Smartphone/tablette, … Compliqué on n’a pas tous des clé usb chiffrées et des processus de transfert sécurisé vers les terminaux.
#7
Quitte à traduire, on peut utiliser le terme de serveur mandataire inverse ou relais inverse.
#8
Et si la plus des URL contiennent PayPal, facebook ou Google pourquoi les services de nom n’ont pas une alerte quand un achat de domaine est effectué ?
#8.1
Parce qu’il est impossible de surveiller tous les domaines de squatting possibles. Et que si c’était possible alors une autre façon de les attaquer serait de les forcer à les acheter en masse (avec une cascade de conséquences), sachant qu’entre l’utf, l’idn, et le fait que personne ne fait attention à l’URL (qui n’est d’ailleurs pas toujours visible) il y a virtuellement une infinité de domaines frauduleux possibles pour un domaine légitime.
#9
Info intéressante, surtout au vu de la généralisation du MFA (perso je l’active systématiquement).
Après, une bonne pratique je m’efforce d’appliquer : jamais d’ouverture d’un lien depuis une communication diverse (mail, SMS, etc). Toujours accès direct au site via les favoris ou bien taper l’URL.
En plus ça fait du tracking en moins vu que les liens envoyés dans les mails ou SMS intègrent généralement des URL de tracking ou des réducteurs d’adresse opaques.
Perso c’est un truc que j’ai détesté voir arriver sur les navigateurs : masquer des infos de l’URL en laissant juste le domaine de base et plus le contenu de la requête. Je désactive systématiquement ces options stupides, on ne sait plus où on va sinon…
#10
Tout simplement car le registrar n’a aucune connaissance du sous domaine qui va pouvoir être utilisé par le vilain personnage. C’est mechant.pirate que tu
achètesloues, pas facebook.mechant.pirate#10.1
Les registar je sais pas, mais certains services en ligne ont des alarmes. Quand j’ai migré ma boite mail chez Infomaniak et recréé mes alias, ma possibilité d’envoyer des mails a été suspendue à titre préventif car mes alias pouvaient être assimilés à de l’usurpation (du genre [email protected], [email protected]…).
Un bref échange avec le support m’a permis de comprendre qu’ils ont un alerting en ce sens et depuis j’ai pris l’habitude de faire des alias moins tendancieux.
#11
Ce que je ne saisis pas comment fonctionne le MITM: il faut avoir cliqué sur un lien qui n’est pas d’origine. Mais est-ce que cette technique fonctionne quand on va directement sur le site ?
#11.1
Si c’est du MITM non : le serveur qui fait l’attaque est entre ton pc et le site que tu tentes de joindre.
C’est par le lien vérolé que tu joins le serveur qui fait l’attaque. Si tu vas directement sur le site légitime, il ne peut donc y avoir d’attaque par MITM.
#11.2
Sauf avec un DNS menteur
#11.3
Ah oui, je n’avais pas pensé à ça.
#12
Imaginons qu’un service de gestion de dns ait ce genre de choses en place, c’est inefficace car tu peux gérer toi même tes dns sur ton serveur. Donc c’est impossible à contrôler car aucune idée de ce que fabrique le client avec le NDD, vu qu’il gère tout sur ses propres machines ensuite
#13
Bah justement l’intérêt est de savoir exactement où tu es
Sans tu pourrais croire être sur apple.icloud.com y compris en connaissant parfaitement le rôle du point et du slash, c’est facile de voir un slash là où y’en n’a pas quand ton cerveau s’attend logiquement à ce caractère :-/
Ça, c’est la version facile, tu peux aussi avoir de l’ascii spoofing :
Sur le premier “facebook” les consonnes sont OK, toutes les voyelles sont usurpées (en fait des caractères cyrilliques quasi identiques aux lettres habituelles latines).
Avec ce système ton navigateur va afficher en gras la version “échappée” de l’host :
Sans tu pourrais rester sur le truc un peu long sans te rendre compte de l’host foireux à la fin…
#14
Le titre me paraît incomplet. Il aurait fallu rajouter “malveillants” ou quelque chose d’équivalent.
#14.1
Je n’avais pas réalisé, pensant que le fait qu’il débute par “Hameçonnage : ” était explicite, ce que précise bien le chapeau de l’article…
#15
L’erreur ne serait-elle pas d’obtenir un secret par un canal pour ensuite le renvoyer par un autre canal avant de s’assurer que ce canal est sûr ? le secret devant servir à cela justement. C’est ballot :]
Ne peut-on pas l’utiliser comme salt pour re-generer les paires de clés public/privée au niveau TLS et les activer avant d’envoyer le cookie ?