En bref : traversée de chemin .tgz de cdnjs jusqu'à l'exposition de GITHUB_REPO_API_KEY dans l'environnement
- Approuvé car Cloudflare : Tout le monde fait confiance à cdnjs parce que Cloudflare le fait tourner, mais la trouvaille de RyotaK en 2021 a transformé un nom de fichier .tgz forgé en traversée de chemin (path traversal) qui a écrasé un script exécuté régulièrement et exposé GITHUB_REPO_API_KEY et WORKERS_KV_API_TOKEN depuis /proc/self/environ.
- Le comportement, pas la source : cside ne se fie pas à des listes blanches de sources : son agent dans le navigateur observe le comportement à l'exécution de chaque script sur 100 % des sessions, surveille plus de 60 attributs avec l'IA et tient compte du contexte historique, ce qui aurait précisément permis de détecter l'exécution de commandes arbitraires transitant par le CDN auquel plus de 12 % d'internet fait confiance.
- Vérifier, pas faire confiance : Le post-mortem de Cloudflare est un modèle de transparence, mais l'exploit se serait exécuté directement dans le navigateur et aurait contourné le WAF, donc la question est de savoir si faire confiance aux sources reste un modèle défendable côté client, ou si vérifier ce qu'elles délivrent est la seule approche défendable.
Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur par cside. Elle couvre tout ce qui suit en un seul déploiement.
Vérifier que vos sources de scripts tiers sont fiables est important. Mais cela seul peut ne pas suffire.
C'est ce que le monde a appris en 2021, lorsqu'une vulnérabilité majeure dans le cdnjs de Cloudflare a été signalée. Voici le récapitulatif de ce qui s'est passé, et comment.
Cdnjs est l'un des réseaux de diffusion de contenu (CDN) JavaScript les plus utilisés aujourd'hui. Plus de 12 % de tous les sites web sur internet injectent au moins un script via cdnjs. Un chercheur utilisant le pseudonyme « RyotaK » a partagé une vulnérabilité de chaîne d'approvisionnement dans cdnjs, permettant à n'importe qui sur internet d'apporter des modifications aux bibliothèques cdnjs en suivant une séquence d'étapes spécifiques. Voici l'intégralité de ses conclusions.
La vulnérabilité existait au sein du serveur de mise à jour des bibliothèques cdnjs. Ce module spécifique aide les développeurs à intégrer en toute sécurité des packages populaires dans leurs sites.
La vulnérabilité en détail
En publiant un fichier .tgz dans le registre npm avec un nom de fichier conçu pour exploiter cette faille de traversée de chemin, un attaquant pouvait amener le serveur de mise à jour des bibliothèques cdnjs à traiter le fichier malveillant. Cela aurait écrasé un fichier de script exécuté régulièrement, entraînant une exécution de commandes arbitraires sur les serveurs de Cloudflare.
Pour prouver l'exploitabilité, une démonstration a été planifiée. Elle consistait à créer un fichier .tgz qui, lors de son traitement par le mécanisme de mise à jour de cdnjs, écraserait un script anodin avec du code malveillant. Cependant, avant d'exécuter ce plan, le chercheur a découvert un autre vecteur d'attaque puissant via les mises à jour de dépôts Git, impliquant des liens symboliques susceptibles de lire des fichiers arbitraires depuis le serveur de mise à jour.
Une erreur survenue pendant le processus de démonstration a révélé quelque chose de pire. Un lien symbolique censé pointer vers un fichier inoffensif a été dirigé par erreur vers /proc/self/environ, exposant des variables d'environnement sensibles, notamment GITHUB_REPO_API_KEY et WORKERS_KV_API_TOKEN. Cela a montré comment un attaquant pouvait accéder à la majeure partie de l'infrastructure de cdnjs.
Les risques potentiels
Cela aurait pu entraîner une exécution de code à distance sur les serveurs de Cloudflare et la possibilité d'exécuter du code malveillant dans les scripts utilisés par tous les utilisateurs finaux. Cela contourne les pare-feux applicatifs web (WAF) et tout autre mécanisme de filtrage, puisque le code s'exécute directement dans le navigateur.
Comme mentionné précédemment, cela aurait exposé plus de 12 % des sites web et l'ensemble de leurs visiteurs à un danger immédiat en cas d'exploitation (une fois les caches expirés).
Cloudflare a réagi rapidement et a pris les mesures appropriées avant que quiconque ne puisse exploiter la faille. L'entreprise est reconnue pour ses post-mortems détaillés et très transparents ainsi que ses divulgations d'incidents. L'intégralité des détails peut être consultée ici.
La meilleure approche
Tout cela démontre qu'on ne peut pas simplement faire confiance aux sources.
Même les meilleurs au monde sont sujets aux erreurs. Une approche plus sûre et plus sécurisée consiste à vérifier ce que ces sources délivrent.
C'est pourquoi cside existe. Nous proposons un petit script à ajouter à une page web, qui fait 2 choses :
- Réécrire les sources des scripts pour les faire transiter par cside. cside s'insère ainsi dans le flux de la requête entre l'utilisateur et le script tiers, permettant une visibilité totale sur les scripts servis. cside inspecte chaque script en profondeur, sur 100 % des sessions, au lieu de se contenter de mettre les sources sur liste blanche. Dans certains cas, des optimisations peuvent même être réalisées grâce à la mise en cache des scripts statiques.
- Effectuer des vérifications comportementales côté navigateur.
cside surveille également plus de 60 attributs et utilise l'IA pour signaler en temps réel tout indicateur d'intention malveillante. Notre solution tient également compte du contexte historique, ce qui permet de repérer plus facilement les changements dans le temps comme des détournements potentiels. cside utilise aussi l'IA pour analyser le code des scripts tiers. La combinaison de nos mécanismes de détection signifie que nous pouvons repérer la tentative en quelques millisecondes et la bloquer avant toute opération malveillante, ou alerter si un comportement dangereux se manifeste.
