[Hackfest::Archive] La cuillère n’existe pas
Depuis quelques jours, un dossier particulier fait beaucoup de bruit sur Internet. Il est question d’une problématique de redirection sur un site hors domaine à partir d’une URL du domaine usa.gov. En fait, l’URL de laquelle part toute la polémique est:
Depuis quelques jours, un dossier particulier fait beaucoup de bruit sur Internet. Il est question d’une problématique de redirection sur un site hors domaine à partir d’une URL du domaine usa.gov. En fait, l’URL de laquelle part toute la polémique est:
1.usa.gov/[Données supplémentaires]
Il faut savoir que les URLs 1.usa.gov/ sont obtenues par l’utilisation d’un service pour obtenir de “petites” URLs. Ainsi, lorsqu’un utilisateur visite la page en question, ce dernier est redirigé sur une page du gouvernement vulnérable à une redirection hors domaine. Il tombe ainsi non pas sur un site gouvernemental mais sur une page sous le contrôle d’un possible pirate. Le groupe de recherche Dell SecureWorks Counter Threat Unit offre une analyse complète de la problématique sur sa page. Ainsi, le présent article ne s’intéresse pas à la faille de redirection elle même car toute le monde en parle. L’article s’intéresse plutôt à une autre problématique, que personne ne semble soulever pour l’instant, qui pourrait certainement faire surface dans les jours à venir.
En lisant sur cette problématique, un détail important a attiré mon attention. Voici un extrait du site de Dell cité plus haut:
The 1.usa.gov short URL service is run by the U.S. government, in partnership with bitly.com.
Ainsi, l’obtention d’une short URL de type 1.usa.gov est possible en raison d’une collaboration entre le gouvernement et le service bitly.com. Le gouvernment peut donc faire une utilisation tout à fait légitime, requise dans le monde d’aujourd’hui, de ce service. Cependant, la lecture de cet énoncé soulève une question importante:
Est-il possible que des employés du gouvernement aient utilisé ce service dans le but de créer des short URLs pointant vers des serveurs et ressources internes des différents organismes gouvernementaux?
Si l’utilisation de ce service est connu et acceptée comme normale dans les différents organismes, il est plus que possible que certaines personnes aient utilisé ce service dans cet objectif. Ainsi, il serait, peut-être, possible de mettre en place une attaque de force brute contre le service en question dans le but de déterminer quels sont les short URLs valides pour l’URL de base 1.usa.gov. Dans la situation où une URL ou une référence à une ressource interne était découverte, ceci causerait donc une fuite d’information, pouvant aller de la divulgation d’adresses interne jusqu’à l’accès à des ressources internes advenant le cas où celle-ci seraient mal sécurisées.
Pour mieux comprendre la situation, prenons par exemple les URLs suivantes:
- 1.usa.gov/a
- 1.usa.gov/b
- 1.usa.gov/c
- 1.usa.gov/d
- 1.usa.gov/e
Dans un monde parfait, où il n’y a pas de problème de sécurité, l’ensemble de ces URLs devrait faire référence à des site publics. Ainsi, lorsque qu’un utilisateur visite le premier lien, ce dernier peut être redirigé vers: http://www.nasa.gov/mission_pages/chandra/multimedia/index.html (ceci n’est qu’un exemple). La redirection est rendu possible car le service de short URLs conserve une table associative entre les short URLs et les URLs complets. Ainsi, une visite à 1.usa.gov/a cause une redirection vers le site associé chez le fournisseur de short URLs. Maintenant, imaginons qu’un employé gouvernemental, bien intentionné, a utilisé le service de _short URLs _pour obtenir une petite URL pointant vers:
topsecret.usa.gov/ceciEstUnDossierSuperTopSecretAvecUneURLBeaucoupTropLongPourQuUnePersonneAccepteDeLaTaperSurUnClavier.aspx?param1=1¶m2=2¶m3=3¶m4=4
Ceci pourrait ainsi causer une association entre l’URL: 1.usa.gov/x, beaucoup plus plaisante à utiliser, et l’URL contenant une référence à une ressource de nature confidentielle citée plus haut. Hors, que ce passerait-t-il si un pirate connaissant l’utilisation des short URLs _au gouvernement américain montait une attaque de force brute pour découvrir l’ensemble des URLs associées aux _short URLs? Et bien, l’attaquant tomberait inévitablement sur l’URLs pointant sur une ressource confidentielle du domaine fictif: topsecret.usa.gov résultant en une fuite d’informations confidentielles. _Et que ce passe-t-il si une faille est découverte dans le service de _short URLs menant à la divulgation de toutes les associations en les short URLs_de type _1.usa.gov et les long URLs associées? Dans ce cas, nul besoin pour un pirate d’user de la force brute ce qui rendrait la découverte de l’information encore plus facile.
Bref, l’utilisation de ce vecteur pour découvrir de telles informations est équivalente à la découverte d’informations “oubliées” par les programmeurs dans les commentaires d’une page web par exemple. Il n’en demeure pas moins qu’il est question d’une possible divulgation d’informations confidentielles.
Au final, ce qui est, présentement, une campagne de spam utilisant des URLs de confiance pourrait très bien se transformer en fuite d’information pour les organismes utilisant le service de short URLs. La vrai question est de savoir si les employés qui connaissent ce service ont été oui ou non conscientisé aux risques de l’utilisation de ce service. Dans l’éventualité ou ce risque n’a pas été pris au sérieux, cela pourrait avoir des conséquences importantes.