Nous avons déjà écrit sur les Références Directes à un Objet non Sécurisé. En voici une autre, qui aurait pu donner au chasseur de bugs, Pouya Darabi, la possibilité de supprimer les images Facebook d’un tiers.
Heureusement pour le tout le monde, Darabi l’a signalé auprès du réseau social, qui a rapidement corrigé ce bug Facebook, et lui a versé une prime bug bounty de 10 000 $.
Les Références Directes à un Objet non Sécurisé, au niveau de sites web, sont un moyen de s’emparer d’une requête web qui vous permet d’accéder à un élément qui vous appartient, comme une vidéo, un article ou une image…
…puis de modifier délibérément les données de cette requête, pour qu’elle se référence à un objet appartenant à quelqu’un d’autre, mais de telle sorte que le serveur autorise cette dernière, vous permettant ainsi implicitement d’avoir accès aux données d’une autre personne.
De cette façon, vous duper le serveur qui vous donne alors accès à des données, qui seraient normalement verrouillées ou invisibles.
Comme Mark Stockley l’a très bien expliqué en 2016 en décrivant une faille de longue date, au niveau de l’administration des noms de domaine au sein d’American Samoa (.AS):
Les Références Directes à un Objet non Sécurisé représentent un type de défaut qui vous permet d’accéder, ou de changer des données qui ne sont pas sous votre contrôle, en modifiant d’autres qui par contre le sont.
Par exemple, imaginez une image à laquelle vous ne pouvez pas accéder, au niveau d’un serveur que vous voulez pirater, et qui est publiée via une URL comme celle-ci :
https://example.net/photos/7746594545.jpg --- HTTP request generated: --- GET /photos/7746594545.jpg HTTP/1.1 Host: example.net
Maintenant, imaginez qu’après vous être connecté à votre propre compte, vous pouvez éditer vos propres images personnelles avec une URL spécifique, associée à un cookie de session, comme celui-ci :
https://example.net/api/edit/?image=4857394574.jpg --- HTTP request generated: --- GET /api/edit/?image=4857394574.jpg Host: example.net Cookie: authtoken=HRCALAGJEOWRGTMW
Dans cet exemple inventé, authtoken est un cookie de session qui indique au serveur que c’est bien vous, et que vous avez déjà été identifié.
Imaginez que le serveur valide uniquement votre authtoken, et ne vérifie pas l’image spécifique 4857394574 sur votre compte, pour s’assurer que vous êtes vraiment autorisé à la modifier.
Vous pourrez alors, sans aucun doute, modifier et répondre à la requête, en mentionnant le nom original de l’image interdite, comme ci-dessous :
https://example.net/api/edit/?image=7746594545.jpg --- HTTP request generated: --- GET /api/edit/?image=7746594545.jpg Host: example.net Cookie: authtoken=HRCALAGJEOWRGTMW
En d’autres termes, dans cet hypothétique exemple, vous finissez par être identifié comme étant autorisé à éditer tous les fichiers image, simplement parce que vous avez eu le droit d’en éditer certaines.
Cela revient à s’enregistrer dans un hôtel, à obtenir une clé qui ouvre votre chambre, et puis à se rendre compte finalement qu’elle ouvre toutes les autres chambres de votre étage, à cause d’une erreur de codage de la clé.
Généralement, ce type de défaut se produit lorsque le logiciel est testé pour s’assurer qu’il passe avec succès tous les tests qu’il est censé réussir, mais il n’est pas testé pour s’assurer qu’il ne passe pas justement, là où il est supposé échouer.
Le bug Facebook
Darabi a remarqué que lorsqu’il a créé un sondage Facebook avec une image jointe, il pouvait modifier la requête HTTP sortante pour faire référence aux images d’autres personnes, et pas seulement à la sienne, et ce en réécrivant certains champs dans le formulaire HTTP concerné (cliquez sur l’image pour voir l’original) :
Le sondage apparaîtra alors avec l’image de quelqu’un d’autre à la place.
Ce type de substitution d’image n’est pas un problème si l’image substituée est destinée à être rendue publique à un moment ou à un autre, donc cela ne semble pas être un bug Facebook majeur et un véritable problème, tout du moins pour commencer…
…mais lorsque Darabi a supprimé le sondage, ce qu’il était autorisé à faire car il l’avait créé, Facebook a gentiment supprimé les images qui y étaient attachées, en supposant apparemment que l’identification autorisant la suppression du sondage s’étendait aux objets image référencés dans le sondage.
Nous arrivons donc à la Référence Directe à un Objet non Sécurisé.
Quoi faire ?
Si vous êtes un utilisateur Facebook, vous n’avez rien à faire.
Grâce au signalement de ce bug Facebook par Darabi (récompensé par une prime de 10 000 $), cette vulnérabilité avait déjà été corrigée, ce qui vous empêche de mettre en place un sondage qui supprime les images d’autres utilisateurs.
Si vous êtes développeur, pensez à tout tester.
Parfois, un système “fail-soft“, dans lequel un code défaillant réduit la sécurité, s’avère approprié, comme par exemple le déverrouillage automatique des issues de secours si votre logiciel de sécurité plante, ou bien si l’alimentation électrique tombe en panne.
Dans d’autres cas, vous préférez des systèmes “fail-hard“, ou “fail-closed“, qui n’accepteront aucun mot de passe d’identification si vous pensez que certains d’entre eux ont été compromis.
En particulier, s’il existe des cas particuliers, au sein de votre logiciel, que le développeur vous assure “ne peuvent pas se produire”, partez du principe que non seulement ils pourraient éventuellement se produire, mais qu’ils se produiront très certainement, et testez-les donc en conséquence …
Billet inspiré de How one man could have deleted any image on Facebook, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.