Les dangers des raccourcisseurs d’URL

I. Présentation

Dans cet article, je vais vous exposer quelques dangers relatifs à l'utilisation des raccourcisseurs d'URL (URL Shortener) au travers plusieurs exemples concrets.

II. Qu'est-ce qu'un raccourcisseur d'URL ?

Les raccourcisseurs d'URL, ou URL Shortener sont des applications en ligne qui permettent aux utilisateurs de créer une URL assez courte, redirigeant vers une URL plus longue. Par exemple l'application web bit.ly va, pour l'URL https://thehackernews.com/2018/09/twitter-account-hacked.html me fournir l'URL courte suivante : https://bit.ly/2xcoe0N

Lorsque que l'utilisateur clique sur l'URL https://bit.ly/2xcoe0N, il requête le service bit.ly, qui stocke dans ses bases de données la correspondance 2xcoe0N = https://thehackernews.com/2018/09/twitter-account-hacked.html, et le redirige vers l'URL longue via une redirection 301 :

Ces URL sont plus facile à retenir, mais aussi à partager sur les réseaux sociaux, lors de la saisie d'URL sur mobile, la transmission de liens par mail, etc. Les raccourcisseurs d'URL sont aujourd'hui largement utilisés et nombre d'applications possèdent des intégrations natives ou via modules de ceux-ci. Prenons l'exemple de Google Maps, qui possède son propre raccourcisseur d'URL afin de partager des trajets :

Il existe beaucoup de raccourcisseurs d'URL aujourd'hui, parmi les plus utilisés: bit.ly, buff.ly, TinyURL, ow.ly... Certains services tels que bit.ly assurent qu'un lien court créé n'expirera jamais :

III. Quels sont les dangers ?

Plusieurs problèmes bien connus concernent les raccourcisseurs d'URL, le premier étant bien entendu que l'utilisateur qui clique sur un lien court ne peut pas savoir où il va atterrir, il s'agit donc d'un outil facilitant le phishing, notamment pour les cas où une charge utile (Javascript par exemple) est exécutée dés le premier accès et sans action supplémentaire de l'utilisateur. Cela peut également être intéressant pour l'exploitation de vulnérabilité CSRF (voir https://ogma-sec.fr/dvwa-csrf-file-inclusion-solutions-explications-protections/). Bref. Pour cela, plusieurs services en ligne existent et permettent de vous afficher la destination finale d'un lien court avant tout accès (https://checkshorturl.com/expand.php), il faut cependant avoir le réflexe de les utiliser.

Il est également possible d'obtenir des métriques intéressantes sur un lien pour certains services en ajoutant un "+" à la fin de l'URL courte (par exemple https://bit.ly/2xcoe0N+). Bit.ly et goo.gl proposent notamment cette fonctionnalité, qui permet également de voir la destination finale du lien sans y accéder. :

On peut ainsi facilement voir, sans accéder directement à l'URL cible, si nous somme le seul à avoir cliqué sur le lien, quelles sont les populations ciblées, quand le lien a été créé, etc. Un autre problème se pose cependant. Une URL peut être une donnée sensible, elle peut contenir des informations importantes en paramètre (transmission de paramètres GET, qui sont présents dans l'URL), notamment :

• un identifiant de connexion
• une adresse mail
• un token ou jeton de session
• toute autre données personnelles

Par exemple :

https://monsite.fr/login.php?user=admin&pass=MonPassword123@

Il est aussi fréquent que les raccourcisseurs d'URL soient utilisés pour "résoudre" des URL qui ne sont pas directement exposées sur internet, au sein d'une même équipe dans une entreprise par exemple. Cela peut exposer des informations concernant l'infrastructure interne d'une entreprise. Enfin, la notion de complexité de l'URL (ou plutôt de ses paramètres) est ici à rappeler. Certains services, par exemple de partage de documents (DropBox, Google Drive, One Drive), possèdent une fonctionnalité de partage de documents simple d'utilisation. Si je suis le propriétaire d'un document et que je souhaite le partager avec une personne (non authentifiée sur le service), la fonctionnalité de partage de document par URL va créer une URL telle que celle-ci :

https://1drv.ms/f/s!AuxYRKDNC_FxgXdUkb9vYMbmbmNV

Je n'ai plus qu'à envoyer ce lien à la personne concernée pour qu'elle puisse accéder à mon document. La sécurité de l'accès à la donnée cachée derrière ce lien réside donc dans la robustesse (taille + alphabets et entropie des caractères) du jeton présent dans l'URL (AuxYRKDNC_FxgXdUkb9vYMbmbmNV). Si cette information est connue par une autre personne, elle pourra accéder à la donnée. Il est donc dans l'intérêt de l'utilisateur de créer des jetons longs et complexes. On retrouve le même principe dans les liens de réinitialisation de mot de passe envoyés par mail, qui utilisent uniquement un jeton pour retrouver le compte souhaitant réinitialiser son mot de passe, exemple :

https://monsite.fr/resetpassword.php?token=dhfjkenpzdmQSLHQPCEUCNZMfqsdfnpcNDMSQLKDJENMmqlfsqmfk

Les raccourcisseurs d'URL viennent ici casser la complexité des jetons car ils permettent de cacher une URL complexe derrière une URL "courte" contenant comme donnée inconnue uniquement quelques caractères (par exemple, 6 caractères pour bit.ly).

IV. Le projet URLTeam

Les URL courtes sont donc plus simple à "casser" (brute forcer), c'est d'ailleurs l'objectif du projet URLTeam (https://www.archiveteam.org/index.php/URLTeam) qui va chercher à retrouver toutes les possibilités de liens raccourcis afin de voir si ceux-ci redirigent vers une URL ou non. Grâce à un traitement réparti sur des centaines de machines volontaires (à l'image d'un botnet), n’importe qui peut mettre sur son système un petit script qui va participer à la résolution des URL raccourcies. Les résultats du projet (URL nouvellement résolues) sont publiés sur archive.org : https://archive.org/search.php?query=subject%3A%22urlteam%22 Vous pouvez d'ailleurs suivre en direct le nombre de liens retrouvés pour chaque services (https://tracker.archiveteam.org:1338/status), soit plus de deux milliards de liens résolus pour bit.ly, plus d'un milliard pour tinyurl, etc.

Il faut donc considérer que chaque URL saisie dans un service de raccourcisseur d'URL est publique (dans le sens "référencée quelque part"). Je me suis donc penché sur le contenu des archives de l'URLTeam afin de voir ce qu'il pouvait y avoir d'intéressant, et je n'ai pas été déçu du voyage. URLTeam publie donc plusieurs fois par mois les nouvelles URL résolues grâce à son réseau de machines volontaires :

Attention, les URL nouvellement résolues ne sont pas à confondre avec les URL courtes récemment créées. Nous avons vu que la plupart des services ne font jamais expirer leurs liens courts, ceux-ci peuvent donc être résolus par brute force bien après leur création. Une seule archive "URLTeam Release" pèse en général plusieurs centaines de mégaoctets et ne contient que des documents texte remplis de liens :

Je me suis donc créé un petit script qui se charge de récupérer les dernières archives publiées par l'URLTeam et de les décompresser correctement pour me laisser uniquement les fichiers textes :

Cela me permet ensuite d'utiliser d'autres scripts et des commandes grep pour y trouver des informations intéressantes. J'ai par exemple créé un script qui se charge de récupérer tous les liens d'applications de partage de document (Owncloud, Google Drive, One Drive, Dropbox), qui possèdent des formats d'URL facile à identifier, puis de voir si les liens amènent vers des documents encore valides. Par exemple, un lien partagé Dropbox ressemble à cela  :

L'accès à cela un lien peut mener à:

• un document valide et accessible ;
• une demande d'authentification ;
• une page d'erreur 404 ou un document expiré.

Pour chaque service, je n'ai donc qu'à observer les différents comportements possibles et filtrer les réponses pour ne récupérer que les liens valides. Voici un exemple de sortie :

Pour une seule archive, je récupère en général plusieurs centaines de document Google Drive et Dropbox valides et quelques dizaines de documents Owncloud et One Drive. Il est alors très facile de découvrir des photos de famille, des documents "sensibles" (factures, fiche de paie, CV), des documents partagés collaboratifs, parfois des scans de cartes d'identité ou documents bancaires. ..

Le nombre de documents accessibles trouvés par archive est assez impressionnant. Il est certains qu'un attaquant qui cherche des données sur une entreprise ou un utilisateur précis perdra son temps, mais l'obtention de documents a priori privés peut facilement faire des utilisateurs propriétaires de ces documents des cibles, notamment pour du phishing, chantage et du vol de compte. J'ai également gardé plusieurs commandes grep qui permettent de filtrer :

• des extensions sensibles (.zip, .bak, .save, .sql)

• des adresses mail (par milliers)

• des adresses mail en .gouv/.gov

• des noms de domaines .gouv/.gov (avec résolution DNS pour trouver d’éventuels noms de domaines résolvant des adresses IP internes par exemple)
• des login/mots de passe stockés dans les URL (par centaines...)
• des liens de réinitialisation de mot de passe (parfois encore valides)
• etc.

Enfin, il m'est apparu que certains services utilisent des raccourcisseurs d'URL lors de leur communication avec leur utilisateur, notamment pour les liens de réinitialisation de mot de passe envoyés par SMS, pour les authentifications "rapides" par mobiles, ce qui permet de trouver des centaines de login/mots de passe valides d'utilisateurs, cela m'a par exemple permis d'accéder à des comptes icloud car une URL contenant les identifiants de l'utilisateur a été utilisée dans un raccourcisseur d'URL par un service web (auto-login?sms=true) :

Bref, on y trouve tout et n'importe quoi. Le problème ici est que les utilisateurs ne sont pas conscient du danger. Également, certains services ne devraient pas pouvoir être utilisés sur des raccourcisseurs d'URL, notamment les services de partage de fichiers car cela casse la sécurité de leur token, initialement assez robustes pour éviter d'être cassés par une attaque de type brute force. La seule leçon à retenir est donc la suivante : Si vous utilisez un raccourcisseur d'URL, considérez que le lien soumis est désormais totalement public, abstenez-vous donc dans certains cas.