Si certains spécialistes dénoncent leur introduction et pointent les dangers qu’ils apportent au quotidien, d’autres considèrent que la panique est exagérée. Cependant, une bonne partie est d’accord sur un point : était-il vraiment utile de permettre de créer des sites en .zip et .mov ? 

Deux nouveaux domaines de premier niveau qui interrogent

Dans un post de blog publié début mai, l’entreprise Google a annoncé le lancement de huit nouveaux domaines de premier niveau. Les domaines de premier niveau, aussi appelés extensions ou encore TLD, de l’anglais Top-Level Domain, sont les derniers éléments d’un nom de domaine. Par exemple, dans le cas du site de L’Éclaireur, le « .com » est le TLD. Il en existe des milliers et tous n’ont pas les mêmes règles. Certains sont liés à des pays, comme le « .fr », d’autres sont plus ouverts et peuvent être choisis par n’importe qui pour son site web, comme « .com » ou « .net » et d’autres encore demandent à ce que certaines règles soient respectées, comme « .pro ». Enfin, certains sont encore plus restreints et nécessitent une validation, puisqu’ils servent à confirmer qu’un site correspond bien à l’activité reliée au domaine. Par exemple, « .edu » est réservé aux institutions éducatives approuvées par les États-Unis et « .gov » est réservé aux organismes gouvernementaux américains.

Si, en France, on retrouve le plus souvent des sites en « .com », « .fr », « .org » ou « .net », il existe de nombreux TLD plus rares et originaux. Depuis 2012, ceux-ci se multiplient et il est désormais possible d’avoir des sites en « .fun », « .art », « .paris », « .xyz », « .site », etc. Depuis début mai, à l’initiative de Google, nous pouvons désormais utiliser huit domaines de premier niveau supplémentaires pour nos sites web : .dad, .phd, .prof, .esq, .foo, .nexus, .zip, .mov. Si la majorité d’entre eux sont plutôt légers et humoristiques, les deux derniers ont provoqué une certaine grogne, notamment sur le choix du .zip. 

Le problème ? Ces deux TLD sont également des extensions de noms de fichiers. Le .zip correspond à des fichiers compressés, tandis que le .mov est une extension pour les fichiers vidéo. Permettre à des sites web d’avoir également ces extensions crée donc de nouvelles questions pour les utilisateurs : sont-ils face à un fichier ou à une adresse qui mène à un site web ? Une confusion qui ouvre potentiellement la porte à de nouveaux abus de la part d’acteurs malveillants. 

Des chercheurs en sécurité préoccupés

Car il y a de multiples façons pour des pirates potentiels de profiter de ces nouveaux TLD. Imaginez par exemple un tutoriel qui explique qu’il faut télécharger « programme.zip » ou un email envoyé à votre famille où vous leur expliquez que pour voir vos souvenirs de vacances, ils doivent télécharger et décompresser « photos.zip » et regarder « vacances.mov » que vous avez mis en pièce jointe. 

Si « .zip » ne désigne plus seulement une extension de fichiers, mais également un domaine, cela signifie que « programme.zip », « photos.zip » et « vacances.mov » peuvent être considérés comme un nom de domaine pour un site web. Et de nombreux logiciels et sites web, pour faciliter la vie de l’utilisateur, transforment automatiquement ce qui ressemble à un nom de domaine en lien clicable menant au site web auquel il correspond. 

En principe, il suffirait donc à des acteurs malveillants d’enregistrer des noms de domaine qui correspondent à des fichiers .zip ou .mov populaires pour réussir à piéger de nombreux internautes et les mener sur des pages web malveillantes ou leur faire télécharger un malware. Le tout sans action supplémentaire de leur part, puisque la crainte vient du fait qu’il y a des risques que de vieilles publications sur Internet, qui parlaient à la base de fichiers, se retrouvent à pointer automatiquement vers des sites web maintenant que .zip et .mov sont des TLD acceptés. Des domaines potentiellement malveillants ont déjà été repérés, dont plusieurs qui font référence à des produits de Microsoft.

Un chercheur en sécurité, Bobby Rauch, a démontré d’autres manières d’abuser de ces nouveaux domaines. Il existe une particularité méconnue : lorsque l’on ajoute un @ dans une URL, tout ce qui est entre « https:// » et l’arobase est considéré comme des identifiants de connexion utilisateur, tandis que tout ce qui se trouve après l’arobase est considéré comme un nom de domaine. Par défaut, les navigateurs ignorent tout ce qui concerne les informations utilisateur et ne s’occupent que du nom de domaine. Bobby Rauch explique que si vous entrez https://google.com@bing.com dans la barre d’adresse de votre navigateur, vous allez en réalité être redirigé vers Bing, et non pas vers Google vu que le « google.com » est ignoré dans cet exemple. 

Firefox nous a affiché un message d’avertissement et a demandé que l’on confirme que l’on souhaitait bien visiter bing.com, mais ce n’était pas le cas de tous les navigateurs. Mais seule, cette technique ne suffit pas forcément à piéger des utilisateurs. Si on ajoute des barres obliques, ou slash, dans l’adresse avant l’arobase, l’entourloupe ne fonctionne plus. https://google.com/@bing.com ne redirige plus vers Bing, mais vers une page 404 de google.com. Et difficile de mimer correctement une véritable adresse web sans ces slashs.

Entrent les caractères Unicode U+2044 « ⁄ » et U+2215 « ∕ ». Ces deux caractères ressemblent à un slash, ne créent pas d’erreurs lorsqu’ils sont utilisés dans une barre d’adresse, mais ne sont pas considérés comme des slashs par les navigateurs. Il est donc possible de les utiliser pour donner l’impression visuelle d’une URL légitime, tout en utilisant la technique avec l’arobase pour rediriger l’utilisateur vers un autre site. 

Imaginons une URL qui mène au téléchargement d’un fichier zip, et qui se termine donc par .zip car le chemin d’accès contient le nom et l’extension du fichier. Désormais, avec la possibilité d’avoir des sites en .zip, il suffirait pour un acteur malveillant de modifier les slashs de l’URL présents après « https:// » pour les remplacer par U+2044 ou U+2215 et d’ajouter un arobase avant le nom du fichier pour pouvoir rediriger un utilisateur vers un site du même nom. « exemple.com/setup.zip » mènerait à un téléchargement légitime d’un fichier .zip sur le site « exemple.com », tandis que « exemple.com⁄@setup.zip », où le slash a été remplacé, nous emmènerait sur le site « setup.zip ». 

Si vous pensez qu’il est facile de remarquer un arobase dans une URL, détrompez-vous : dans le cas d’un mail, comme le montre le chercheur dans son post de blog, il est possible d’user d’astuces pour rendre l’arobase quasiment indétectable à l’œil nu. Le meilleur moyen pour se défendre est donc de passer la souris sur le lien avant de le cliquer et de vérifier s’il mène bien au site auquel on souhaite accéder et non pas à un autre site.

Plus inutiles que dangereux ?

Si les risques présentés auparavant sont bien réels, de l’avis de certains spécialistes, ils restent marginaux. En premier lieu, tous les logiciels et sites ne convertissent pas automatiquement les noms de domaine en lien cliquable. Si Twitter le fait actuellement pour les domaines en .zip et .mov, ce n’est pas encore le cas de la majorité des programmes. Mais surtout, le phishing a toujours existé et les acteurs malveillants n’ont pas attendu l’arrivée de ces nouveaux TLD pour réussir à piéger des victimes. D’autant plus que, pour pouvoir être utilisées à grande échelle, ces techniques nécessiteraient que les pirates enregistrent des milliers de domaines et ne risquent donc pas d’être favorisées par rapport à d’autres techniques plus simples. 

Comme le souligne Troy Hunt, créateur du site Have I Been Pwned, il n’y a pas besoin de caractères spéciaux ou d’astuces avancées pour réussir à faire cliquer quelqu’un sur un site malveillant. Il utilise un exemple tiré d’une présentation d’Emily Schechter, qui montre plusieurs URL qui semblent toutes probables, mais où une seule d’entre elles correspond vraiment à l’URL du blog de Google. Avec une conclusion simple : les URL sont compliquées et les humains ne sont pas vraiment doués pour reconnaître celles qui sont légitimes ou non.

Eric Lawrence, ingénieur chez Microsoft, a détaillé dans un post de blog ses pensées sur la question, considérant que la panique était exagérée, tout en étant d’accord sur le fait qu’il serait assez judicieux de pas transformer automatiquement les domaines en .zip et .mov en liens cliquables.

De son côté, Google a répondu à plusieurs publications en indiquant que « le risque de confusion entre les noms de domaine et les noms de fichiers n’est pas nouveau » et que « les applications ont des solutions pour atténuer ce problème (comme Google Safe Browsing) et ces solutions resteront valables pour les TLD tels que .zip ». L’entreprise a assuré avoir des mécanismes en place pour suspendre ou supprimer les domaines malveillants et qu’elle n’hésiterait pas à agir en cas de menace pour ses utilisateurs. 

En vérité, une bonne partie des spécialistes sont arrivés à la même conclusion : introduire .zip et .mov en tant que domaines était totalement inutile. Même si les risques ne sont pas si importants que ça, ils sont quand même là et, notamment dans le monde professionnel, rendent la vie plus difficile pour les employés et ceux chargés de sécuriser les entreprises. Le tout pour un gain difficile à quantifier : quel est le but d’avoir un site en .zip ou .mov ?

Les autres domaines introduits par Google peuvent être drôles – le .dad ouvre la porte à de nombreuses blagues – ou peuvent servir à se faire un site plus spécialisé pour montrer ses compétences, comme .phd ou .prof. Mais difficile aujourd’hui de voir une réelle utilité aux domaines qui préoccupent les spécialistes et Google n’a pas vraiment présenté d’utilisation pertinente pour ceux-ci.