Sur les réseaux sociaux tournent en permanence des tentatives d’arnaques renvoyant vers de faux sites. Certaines se renouvellent, d’autres existent depuis des (dizaines) d’années. C’est le cas des redirections avec les URL contenant un « @ ». La SNCF en est victime, mais c’est aux utilisateurs de faire attention. Sur ce coup, Firefox tire son épingle du jeu.
Tout le monde le sait, les arnaques sont nombreuses sur Internet et peuvent prendre différentes formes. Il est important d’être sur ses gardes, surtout quand l’offre paraît trop belle pour être vraie (spoiler : c’est très souvent le cas).
Dans notre dossier sur les noms de domaine, nous avons abordé plusieurs techniques différentes utilisées par des personnes malveillantes.
- C’est quoi un nom de domaine, les différences entre ccTLD et (New) gTLD
- Les abus sur les noms de domaine toujours plus nombreux et sophistiqués
Regarder plus loin que le nom de domaine
Celle dont nous parlons aujourd’hui n’exploite aucune faille. Elle ne nécessite donc aucune configuration particulière et les sites qui en sont victimes ne peuvent donc rien y faire. L’arnaque repose sur un détournement de la syntaxe des URL. L’histoire n’est pas nouvelle, loin de là, puisqu’on en parlait déjà dans les années 2000, mais il est facile pour certains de tomber dans le panneau. Un rappel ne peut donc pas faire de mal.
Un nom de domaine est composé de deux éléments : un nom (ou radical) et une extension pour former un ensemble « nom.extension ». On peut ajouter des informations supplémentaires comme un sous domaine – sousdomaine.nom.extension –, cibler une page précise – nom.extension/mapage.html –, ou une combinaison des deux. Dans tous les cas, le plus important pour savoir où on se trouve est le couple nom.extension.
Des détournements classiques et bien connus consistent à modifier une lettre – un 0 (zéro) à la place d’un o (lettre o), un I (i majuscule) à la place d’un l (la lettre entre k et m)… – ou utiliser un nom de domaine proche de l’original. Dans l’arnaque dont il est aujourd’hui question, rien de tout cela ; le nom de domaine est tout ce qu’il y a de plus légitime.
[email protected]
Dans notre exemple, il s’agit de la SNCF, dont la bonne adresse est sncf.com, mais cela pourrait fonctionner avec n’importe quel autre site.
Comme vous pouvez le voir, des caractères supplémentaires se trouvent après l’extension. Cela arrive tout le temps, car les URL servent aussi à faire passer des paramètres et autres traceurs. Mais le « @ » à une signification particulière dans les URL, comme l’explique l’IETF. Le document date de 1994, autant dire que le sujet n’est pas récent.
On va simplifier un peu l’exemple de la RFC de l’IETF en prenant comme exemple : « //<user>:<password>@<host> » (host représente le nom de domaine, sncf.com dans notre exemple).
Il s’agit en fait d’une méthode d’identification directement via l’URL. On pourrait imaginer une adresse du genre « sebastien:[email protected] ». Dans ce cas, le site visé se trouve après l’@, les paramètres d’identification avant.
Des pirates détournent cette fonction en essayant de faire passer de faux sites pour de vrais sites. Dans l’image ci-dessus, on peut voir que l’URL est de la forme « [email protected] ». Beaucoup de personnes risquent de penser, à tort, que sncf.com est le site cible, alors que c’est l’identifiant (qui ne sera pas utilisé dans le cas présent) !
Résultat des courses, on est redirigé vers le site malveillant, pensant arriver sur celui de la SNCF (ou d’un autre site légitime, vous avez compris l’idée). La prévisualisation dans WhatsApp laisse apparaitre un message alléchant, que l’on pourrait croire venant de la SNCF : « Cadeau de Noël - Voyage gratuit pendant un an ».
Les attaquants mettent alors en place un site reprenant les couleurs et la mise en page de celui de la SNCF. Ils peuvent ensuite récupérer des informations de ceux qui se laissent avoir.
Quand c’est trop beau pour être vrai… c’est probablement une arnaque
Sans même avoir regardé l’URL, on se doute bien que l’offre pue l’arnaque à des km. Mais certains pourraient être tentés et se dire « au pire, on peut essayer ». C’est généralement l’occasion pour les pirates de récupérer des données personnelles. Dans le cas présent, il faut partager « l’arnaque » sur WhatsApp à un maximum de contacts, sans jamais rien obtenir en retour évidemment.
La SNCF est régulièrement la cible d’arnaques avec de fausses promotions, parfois avec des petits montants de quelques euros à payer. Là encore, il ne faut pas se dire qu’on ne risque que 2 euros par exemple. Une fois vos données bancaires récupérées, les pirates peuvent souvent faire bien plus de dégâts.
Firefox affiche un message d’alerte
On s’étonne quand même que les navigateurs redirigent les internautes sans autre forme de procès ni afficher le moindre message d’avertissement, d’autant que cette technique de manipulation existe depuis maintenant 20 ans. Ce n’est pas tout à fait exact, car il y a une exception : Firefox, qui demande une confirmation. Nous avons testé avec cette URL : « http://[email protected] », et un message d’alerte apparait :
« Vous êtes sur le point de vous connecter au site « next.ink » avec le nom d’utilisateur « youtube.com », mais ce site web ne nécessite pas d’authentification. Il peut s’agir d’une tentative pour vous induire en erreur.
« next.ink » est-il bien le site que vous voulez visiter ? »
Brave, Edge, Chrome et Safari n’en ont que faire et renvoient sans broncher vers le site derrière l’@ (aussi bien sous Windows que Linux). Il faut dire que c’est le comportement attendu par défaut selon la notice de l’IETF, mais les navigateurs feraient bien de prendre exemple sur Firefox.
Mozilla prend en effet le parti de prévenir les utilisateurs, ce qui peut être utile pour les néophytes. Pour les aguerris (qui savent ce qu’ils font), il est possible de désactiver cette confirmation en ajoutant une entrée dans about:config : network.http.phishy-userpass-length, avec une valeur numérique à 255.
Commentaires (51)
#1
En fait, j'ai même pensé à une erreur de LibRedirect (extension Firefox), que j'ai accusé trop rapidement de penser que https://youtube.com@…/ était une URL YouTube à rediriger ailleurs.
Euh sinon, plus sérieusement, le comportement de Firefox me paraît très sensé, d'autant plus que même si je fais partie de la catégorie « utilisateurs avancés », je n'utilise quasiment jamais cette syntaxe. Il vaut mieux laisser le navigateur poser la question, et les gestionnaires de mot de passe pré-remplir ce qu'il faut…
#1.1
C'est une syntaxe qui est clairement à oublier, mais qui devait être pratique il y a 30 ans
#1.4
Ce fus ma toute première correction car ça m'a bien fait peur
#1.6
Même avec un serveur qui attend une authentification, firefox avertit : https://cadeau:[email protected]/HTTPAuth/
Vous êtes sur le point de vous connecter au site « authenticationtest.com » avec le nom d’utilisateur « cadeau ».
#1.2
Blague à part, si j'apprécie grandement le rick roll en général, ici, il gâche complètement l'effet de vouloir montrer l'impact du @ sur l'URL, puisque le texte et le lien vers lequel il redirige ne sont pas les mêmes, et que le "vrai" lien ne contient même pas de @. Eventuellement un https://[email protected]/watch?v=dQw4w9WgXcQ aurait été plus adapté (tout en conservant la "blagounette")
#1.5
#1.3
#2
#2.1
#2.2
Mais effectivement ça s'applique également pour ce type de redirection.
#3
Hors comme le hacker contrôle de toutes façons le serveur, il pourrait très bien envoyer un header indiquant qu’une authentification est requise.
Après, franchement, cette syntaxe est tellement peu utilisée que ça ne mangerait pas de pain d’afficher un message à chaque fois.
#3.1
Pour ma part, je pense qu'il serait plus simple de bannir cette utilisation tant elle est peu usitée dans ce genre de contexte. Et si vraiment il y en a besoin, le public cible doit être très restreint et devrait aller modifier lui-même les paramètres du navigateur pour l'autoriser.
#3.2
https://cadeau:[email protected]/HTTPAuth/
Vous êtes sur le point de vous connecter au site « authenticationtest.com » avec le nom d’utilisateur « cadeau ».
#4
Puis dès que j’ai vu //USER:MDP@DOMAINE , mais bien sur, c’est exactement comme ça que je me connecter à mon ftp (ftp://USER:MDP@DOMAINE)
Sauf que c’est bien « : » entre le login et mdp, hors, on parle là d’avoir un « . » (type sncf.com) à la place.
Du coup, y a une explication ?
#4.1
Donc l'identifiant serait « sncf.com » (c'est autorisé) sur le site wpme.cc (NE PAS CLIQUER)
#4.2
#4.3
#4.4
≺protocol≻:[//[≺user≻:[≺password≻]@]≺host≻[:≺port≻]]/≺path≻[?≺query≻][#≺fragment≻]
(les [] indiquent ce qui est optionnel)
URL (wikipédia)
#4.5
#4.6
Sinon dans le texte, c'est précisé : « schéma de représentation (spécifique au protocole de communication utilisé pour accéder à cette ressource) »
Je ne comprends pas bien la différence, tu peux m'expliquer ? (ou sinon un lien qui explique ça, sur ton blog ?)
#4.7
#5
#5.1
"http://[email protected]" redirige bel et bien sur next.ink
mais "[email protected]" redirige sur une recherche Google (Google étant le moteur de recherche enregistré dans mon Vivaldi) de "[email protected]".
Bref, ça semble plus subtil que cela.
Edit: j'ai rien dit, j'avais pas mis http(s) devant. Avec, ça redirige direct. My bad.
#5.2
Dans le temps, Opera (v.6 à v.10 environ) proposait aussi ce genre de message, mais c'était parce qu'à l'époque le username et l'éventuel mot de passe restaient affichés en barre d'adresses (des * pour le mdp). Le dialogue de confirmation de chargement avait disparu des versions 11 et 12 d'Opera…
#5.3
C'est quoi leur justification pour ne pas mettre ce message ?
#5.4
#5.5
Là, en fait, Firefox ne fait que conserver un vieux truc qui avait probablement une utilité réelle il y a 20 ans. Là, ce n'est plus le cas.
#5.6
#5.7
Après sans connaître cette syntaxe en http, je l'ai tellement utilisée en FTP que si je l'avais vu j'aurai tiqué à coup sûr!
#5.8
Là, l'antique comportement de Firefox que tu trouves rassurant ne fait que masquer un petit symptôme marginal sans résoudre un problème plus global.
#5.9
Les autres comportements que tu cites (lien trompeurs, redirections, etc.) sont des comportements très utilisés aujourd'hui, et il serait bien difficile de trier le bon grain de l'ivraie.
#6
Utilisateur du panda roux depuis des éons, j'ai pris l'habitude depuis longtemps de vérifier que ce qui est en surbrillance est bien le site où je souhaite me rendre, sinon j'évite.
Bref, merci FF !
#7
#8
Gros merci d'avoir laissé cet article en accès public !
#9
#9.1
#9.2
#9.3
#10
Par contre, j'ai déjà obtenu ce message de la part de Firefox (d'où l'intérêt de continuer à utiliser ce navigateur, mais ça c'est un autre problème). De toute façon, les sites que j'ai visité étaient bien légitimes.
Sincèrement, il faut vraiment être prudent quand on "surfe" sur internet.
#11
Si je copie-colle l'adresse, j'ai bien l'alerte. Mais bizarrement, si je clique sur le lien, j'ai bien Youtube qui s'ouvre, sans aucune alerte (par contre aucun risque d'être phishé car grâce aux LIDD d'hier j'ai installé LibRedirect, qui me charge un front-end visiblement trop utilisé pour être opérationnel
#11.1
#12
#12.1
#12.2
Après, c'était en interne de mon entreprise, mais tout de même...
#13
#13.1
#14
J'arrive sur l'URL de test sans avertissement
#14.1
Tu as cliqué (RickRoll) ou tu as copié/collé (vrai test) ?
#14.2
Et je ne pige pas la différence :(
#14.3
- le lien : http://youtube.com/watch?v=dQw4w9WgXcQ
- le texte : http://[email protected]
Du coup, quand tu cliques sur le lien, tu es redirigé vers http://youtube.com/watch?v=dQw4w9WgXcQ. Le lien ne contient pas le @ => pas d'alerte. Le texte en contient un, mais on s'en fou, car ce n'est que du texte...
#14.4
Merci :)