Data URI : quand le phishing se fait plus furtif

Un e-mail prétendument envoyé par LCL à son client pour l’inviter à lire un message de son conseiller bancaire. Là, un lien sur lequel cliquer pour accéder à son espace de banque ligne. Dans la barre d’adresse du navigateur, un URL mentionnant explicitement l’adresse https://particuliers.secure.lcl.fr/. Pourquoi se méfier ?

Parce que quelque chose ne colle pas : le navigateur n’indique pas qu’il a établi une connexion sécurisée avec le serveur. Surtout, l’adresse, suffisamment familière pour paraître sûre à l’internaute confiant, est précédée du texte suivant : data:text/html;.

Le piège est là : pas de page HTML chargée directement, mais le code correspondant chargé directement dans l’URI, encodé en Base64. Celui-ci appelle une page HTML malveillante, dans un cadre iframe.

Les équipes de la Phishing Initiative, un service opéré par le très sérieux cabinet Lexsi, s’y seraient presque laissées tromper. Il leur a fallu quelques heures pour identifier le procédé avant de remonter les URL malveillantes dans les listes de filtrage anti-hameçonnage intégrées par les navigateurs Web, expliquant que les cas de data URI comme celui-ci s’avèrent plus complexes à traiter que les autres cas de phishing.

Le concept n’est pourtant pas nouveau. Les data URI, qui permettent à un navigateur Web de charger du code encodé directement dans un URI s’appuient sur un standard datant de 1998, le RFC 2397. Le chercheur Henning Klevjer s’est penché de près sur le sujet à l’automne 2012, et l’institut SANS n’a pas manqué d’alerter sur le risque à la même époque.

En mai 2014, une attaque par hameçonnage utilisant cette méthode de maquillage ciblait les détenteurs de comptes Google. Sans donner de chiffres, Bitdefender affirmait alors que l’opération avait permis de piéger bon nombre d’internautes.

Le sujet fait l’objet de débats récurrents, comme l’illustre une longue conversation sur les forums de la fondation Mozilla. Mais pour l’heure, Safari, Google Chrome ou encore Firefox acceptent les redirections vers des data URI. Et aujourd’hui, plus de deux heures après la remontée de l’URL malveillant par les équipes de Lexsi, les navigateurs Web continuaient de guider leurs utilisateurs dans les filets des cybercriminels à l’origine de cette campagne de hameçonnage visant les clients de LCL. A l’heure où ces lignes sont publiées, le site Web belge abritant les pages malveillantes en question a toutefois été mis hors ligne.

Certes, il est donc ici possible de bloquer le lien de redirection initial, puisqu’il est hébergé en ligne, et il est possible également de bloquer la page appelée par le cadre iframe. Mais cela n’a pas forcément besoin d’être le cas, comme le soulignait Henning Klevjer. Il y a donc trois ans, il alertait : « en utilisant cette procédure, il n’y a pas de source claire de la page de hameçonnage et de son contenu, ce qui la rend difficile à suivre ou encore à surveiller, voire à en établir l’origine ».

Surtout, lorsque la redirection initiale n’est pas hébergée, « il n’y a aucun moyen de fermer ou de retirer » l’URI en question, « sinon supprimer toutes les instances de son lien ». Alors pour lui, il fallait s’attendre à la mise en œuvre de cette méthode de maquillage pour du hameçonnage ciblé, personnalisé. Et d’appeler à la vigilance.