Article original : Cache Deception: How I discovered a vulnerability in Medium and helped them fix it
Par Yuval Shprinz
Dans mon précédent article, j'ai essayé de démontrer à quel point le reverse engineering des applications Android peut être puissant et cool. Je l'ai fait en montrant comment modifier l'application de Medium pour que toutes les histoires nécessitant un abonnement soient disponibles gratuitement.
Eh bien, il y avait un peu plus à cette histoire :)
Alors que je travaillais vers mon objectif souhaité, j'ai trouvé une grande collection de points de terminaison d'API que Medium avait déclarés dans leur code, ce qui a révélé une vulnérabilité de Cache Deception après une courte itération sur eux. J'étais particulièrement excité par cette découverte car les attaques basées sur le cache sont exceptionnellement géniales, et cela aurait pu être un excellent ajout à mon histoire.
Malheureusement, il a fallu trois mois à Medium et quelques rappels pour répondre, donc j'ai dû attendre un peu pour la divulgation publique.
Dans cet article, je vais essayer d'expliquer intuitivement ce qu'est la Cache Deception, décrire le bug chez Medium, et référencer deux articles exceptionnels sur les attaques basées sur le cache.
Cache Deception
Les navigateurs web mettent en cache les réponses statiques des serveurs pour ne pas avoir à les demander à nouveau — économisant ainsi du temps et de la bande passante.
Selon un principe similaire, les serveurs et les CDN (Content Delivery Networks, comme Cloudflare par exemple) mettent également en cache les réponses (leurs propres réponses), pour ne pas avoir à perdre du temps à les traiter à nouveau. Au lieu de transmettre au serveur une requête que le CDN connaît déjà (par exemple, une image statique), il peut retourner une réponse immédiatement au client et réduire à la fois la charge du serveur et le temps de réponse.
Lorsque les serveurs mettent en cache des réponses statiques, tout le monde en bénéficie. Mais que se passe-t-il lorsqu'un serveur met en cache une réponse non statique contenant des informations sensibles ? Le serveur commencera à servir la réponse mise en cache à tout le monde à partir de maintenant, rendant ainsi publiques toutes les informations sensibles qu'elle contient !
C'est donc essentiellement ce qu'est la Cache Deception — faire en sorte que les serveurs mettent en cache des données sensibles, en exploitant des règles de mise en cache mal configurées. Une fois les données sensibles mises en cache, un attaquant peut revenir pour les voler, par exemple.
Mise en cache des profils utilisateurs
Medium utilise la bibliothèque Retrofit pour transformer leurs API HTTP en interfaces Java pour leur application Android, donc essentiellement chaque point de terminaison se trouve bien dans leur code avec tous ses paramètres disponibles spécifiés. J'ai extrait tous ces points de terminaison dans une liste qui s'est avérée contenir environ 900 points de terminaison.
Cette liste était un vrai trésor, donc je n'ai pas pu m'empêcher de passer un peu de temps à l'itérer. Parmi d'autres choses, j'ai cherché des URL se terminant par une entrée contrôlée par l'utilisateur, car il existe une mauvaise configuration courante des services de cache pour mettre en cache chaque chemin de ressource qui ressemble à un fichier. Souvenez-vous, notre objectif est de trouver des points de terminaison qui contiennent à la fois des informations sensibles et sont mis en cache par les serveurs de Medium. Donc, trouver un point de terminaison d'API qui est mis en cache serait génial.
Il s'est avéré que Medium mettait effectivement en cache les chemins qui ressemblaient à des fichiers par défaut, mais seulement pour les ressources qui étaient directement sous le répertoire racine du site, des URL comme https://medium.com/niceImage.png.
Heureusement, ma belle liste contenait un point de terminaison qui répondait aux exigences ci-dessus — les pages de profil utilisateur. En définissant mon nom d'utilisateur sur « yuval.png », l'URL de ma page de profil est devenue https://medium.com/@yuval.png, et lorsqu'une personne la visitait, sa réponse était mise en cache pendant un certain temps (4 heures, puis le serveur la supprimait). Et c'était en fait tout le bug, définir des noms d'utilisateur se terminant par une extension de fichier — afin de provoquer la mise en cache des pages de profil.
Quelles informations sensibles peuvent être extraites des réponses mises en cache des visites sur ma page de profil ?
- Les jetons CSRF. Ceux-ci sont intégrés dans le document retourné. (Cross-Site Request Forgery en termes simples)
- Des informations sur qui a consulté mon profil. L'utilisateur actuellement connecté peut également être extrait des documents retournés.
Le fait que chaque réponse mise en cache était là pendant 4 heures et bloquait d'autres réponses d'être mises en cache n'était pas un problème, car en utilisant un simple script, les noms d'utilisateur peuvent être changés répétitivement (et générer de nouvelles URL qui ne sont pas encore mises en cache).
Notez que ce bug aurait également pu être utilisé par des utilisateurs souhaitant masquer l'option « bloquer l'utilisateur » sur leur propre page de profil, s'ils l'entraient répétitivement (à nouveau, en utilisant un script). Cela fonctionnerait car les utilisateurs n'ont pas l'option de se bloquer eux-mêmes sur leur propre profil et ainsi les autres ne l'auraient pas non plus lorsqu'ils reçoivent une réponse mise en cache qui a été créée pour le propriétaire du compte.
Chronologie du rapport
J'ai envoyé mon rapport à Medium via leur programme de bug bounty, et voici la chronologie :
24 août — J'ai envoyé mon rapport initial et reçu un email automatique indiquant que Medium essaierait de me répondre dans les 48 heures.
14 septembre — Je leur ai demandé si quelque chose n'était pas clair puisqu'ils n'avaient pas encore répondu.
1er novembre — J'ai envoyé un autre message, disant que cela me convenait si mon rapport était rejeté, et demandant une réponse pour savoir qu'ils l'avaient reçu.
20 novembre — Réponse de Medium ! S'excusant pour le retard et récompensant mon bug avec 100 $ et un t-shirt.
Je suppose que cela leur a pris un certain temps car la Cache Deception n'est pas le type habituel de bug que les gens signalent — mais j'espérais simplement une réponse rapide me demandant plus d'explications ou quelque chose. J'ai supposé que personne ne lisait leur boîte de réception.
P.S. le bug n'a été récompensé que de 100 $ car le programme de Medium est petit, pas parce qu'il est nul :P
Attaques basées sur le cache — Lectures complémentaires
Les attaques basées sur le cache sont connues depuis longtemps, mais étaient considérées comme principalement théoriques jusqu'à la publication récente de deux travaux exceptionnels par Omer Gil et James Kettle. Si le sujet vous intéresse, ne manquez pas ceux-ci :
Web Cache Deception Attack — Omer Gil, février 2017
Tout en le démontrant sur PayPal, Omer revendique le terme Cache Deception pour ce nouveau et incroyable vecteur d'attaque.
Practical Web Cache Poisoning — James Kettle, août 2018
Le Cache Poisoning est connu depuis des années, mais en publiant sa recherche approfondie, James l'a rendu pratique. Consultez également son article de suivi sur le sujet « Bypassing Web Cache Poisoning Countermeasures ».
À la prochaine… ???