La bibliothèque Polyfill détournée, des centaines de milliers de sites touchés
Chaine d'approvisionnement, cas d'école
Une société chinoise avait racheté le site Polyfill.io et le service qui y était hébergé, utilisé par de nombreux sites. Son usage a été détourné, allant des contenus pornographiques à la diffusion de malwares. Depuis, plusieurs domaines ont été suspendus et des entreprises comme Cloudflare et Google sont intervenues.
Le 05 juillet à 16h47
6 min
Sécurité
Sécurité
Un polyfill est un morceau de code, souvent écrit en JavaScript, utilisé pour fournir des fonctionnalités récentes à d’anciens navigateurs. Une technique utile depuis longtemps pour s’assurer que les internautes ont tous au moins les fonctions de base, même depuis des appareils anciens. Même si leur usage baisse graduellement, on les trouve encore dans des centaines de milliers de sites.
Le site Polyfill.io était particulièrement connu. Il avait été construit pour être une vaste bibliothèque de polyfills, afin que chaque développeur trouve son bonheur. En février cependant, le nom de domaine et compte GitHub ont été rachetés par l’entreprise chinoise Funnull.
Le créateur du projet, Andrew Brett (employé chez Fastly), recommandait alors de supprimer immédiatement toutes les références à Polyfill.io. Il ajoutait que son usage n’était plus nécessaire, les nouvelles technologies étant rapidement adoptées par tous les navigateurs.
Tout s’enchaine rapidement
Le 25 juin, la société Sansec a abordé pour la première fois les dégâts provoqués par le détournement. Il s’agit d’une authentique attaque contre la chaine d’approvisionnement. Funnull – qui serait menée par un groupe cybercriminel – a utilisé les liens vers son site nouvellement acquis pour diffuser des contenus malveillants. Entre temps, le CNAME de polyfill.io a été modifié pour polyfill.io.bsclink.cn, possédé et maintenu par Funnull.
Dans son billet initial, Sansec indiquait qu’environ 100 000 sites intégraient la bibliothèque Polyfill. BleepingComputer reprend alors les recherches de Sansec dans un article. Le 26 juin, les deux sites écopent d’une attaque par déni de service distribué. On apprend que d’autres domaines sont concernés pour les redirections, dont bootcdn[.]net, bootcss[.]com et staticfile[.]org.
Le 27 juin, de nombreux évènements se produisent. Le registraire Namecheap suspend le domaine Polyfill.io, rendant inopérant cdn.polyfill.io, utilisé par les sites souhaitant se servir de la bibliothèque. Le même jour, Cloudflare passe à l’attaque. Elle met en place des redirections automatiques vers des miroirs sûrs, créés par ses soins quatre mois plus tôt. Peu de temps après, Fastly fait de même. Même uBlock Origin a réagi en ajoutant le domaine à sa liste de filtres.
Dans le même laps de temps, Google envoie des messages d’avertissement aux annonceurs. La firme y indique qu’un problème de sécurité a été détecté et qu’il serait judicieux de contrôler où renvoient les publicités. Les annonceurs sont prévenus qu’en cas de renvoi vers les domaines épinglés, les publicités correspondantes seront désactivées. Cependant, dans un message du forum d’assistance de Shopify, on peut constater que des publicités étaient déjà désactivées pour cette raison à partir du 18 juin.
Un problème plus large
Dès la publication du billet de Sansec, le compte X officiel de Polyfill commence à publier des messages. « Nous avons trouvé des messages médiatiques calomniant Polyfill. Nous souhaitons expliquer que tous nos services sont mis en cache dans Cloudflare et qu'il n'y a aucun risque pour la chaîne d'approvisionnement », peut-on ainsi lire sur le compte le 25 juin. Rebelote les 26 et 27 juin. Le 1ᵉʳ juillet, le compte avertit d’un nouveau domaine. Même chose ce matin, avec un autre domaine. Ces domaines sont suspendus l’un après l’autre par Namecheap.
Le 2 juillet, la société de sécurité Censys publie ses propres découvertes. Elle y déclare avoir détecté 384 779 sites (en baisse constante) embarquant au moins un lien vers Polyfill.io, parmi lesquels des enseignes très connues comme Hulu, Mercedes-Benz et WarnerBros. 237 700 de ces sites sont hébergés par l’Allemand Hetzner. 182 noms de domaine finissent même en « .gov », donc des sites gouvernementaux anglo-saxons.
Censys revient aussi sur les domaines évoqués par Google dans ses alertes : bootcdn[.]net, bootcss[.]com, staticfile[.]net et staticfile[.]org. Tous sont a priori entre les mains des mêmes auteurs que pour l’attaque de la chaine d’approvisionnement. Les chercheurs ont même trouvé des traces du détournement de cdn.bootcss.com dès juin 2023. C’est le seul domaine à avoir montré une activité malveillante. Censys, qui souhaite éviter la spéculation, estime quand même possible que ces domaines soient gardés « sous le coude » pour des activités similaires futures.
La confiance dans les scripts
Dans ses messages sur X le 25 février dernier, Andrew Brett posait la question : « Si vous possédez un site web, charger un script implique une incroyable relation de confiance avec ce tiers. Leur faites-vous vraiment confiance ? »
L’interrogation revient régulièrement dans les publications des chercheurs au sujet de l’affaire Polyfill. Beaucoup rejoignaient Brett sur l’idée que la bibliothèque n’était presque plus nécessaire aujourd’hui, tant le paysage des navigateurs avait évolué, avec des mises à jour fréquentes.
Certains chercheurs y voient l’occasion d’une vaste réflexion sur la réelle utilité de la bibliothèque aujourd’hui. D’autant qu’en cas de nécessité, les points de terminaison créés par Cloudflare et Fastly pourront faire le travail. Mais les développeurs sont invités à réfléchir, de manière générale, sur les scripts présents dans les sites : sont-ils absolument nécessaires ?
La question se pose d’autant que toutes les sociétés de sécurité ont averti du même danger : les attaques contre les chaines d’approvisionnement se multiplient. Un composant comme Polyfill, présent dans des centaines de milliers de sites, représente du pain bénit pour des acteurs malveillants, qui se retrouvent en capacité de contaminer de nombreux appareils. Il ne semble pas y avoir eu réellement de dégâts, mais le détournement de Polyfill résonne comme un avertissement.
La bibliothèque Polyfill détournée, des centaines de milliers de sites touchés
-
Tout s’enchaine rapidement
-
Un problème plus large
-
La confiance dans les scripts
Commentaires (15)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 05/07/2024 à 17h32
Alors j'imagine qu'ils utilisent Subresource Integrity, mais je ne suis pas allé vérifier à chaque fois.
Le 05/07/2024 à 20h24
C'est un vœu pieux, mais ne pas utiliser un marteau pour écraser une mouche est une bonne habitude.
Le 05/07/2024 à 21h17
Le SCA a de beaux jours devant lui.
Le 05/07/2024 à 21h38
La grosse différence entre les deux ? D'un côté, tant qu'il n'y a pas eu récupération des dépendances depuis le site polyfill aucun soucis (pour schématiser pour les connaisseurs, pas de npm install). La faille peut se propager, mais il faut une action (mise à jour du site).
Pour l'autre, un site, sans rien faire, devient vulnérable du jour au lendemain.
Le 05/07/2024 à 22h03
C'est acceptable pour des petits projets à durée de vie très courte, pour de la preuve de concept, mais ça s'arrête là.
Que des .gov ou des grands comptes utilisent ce type de cdn, cela me laisse dubitatif.
Le 05/07/2024 à 20h37
Le 05/07/2024 à 20h42
Je ne sais pas si ça à changé maintenant mais ce serait une bonne idée de faire attention de charger que ce qu'il faut.
Et réflexe du vieux ex-dev, charger une bibliothèque pour en utiliser 2 fonctions simples à coder, voir dont le code est trouvable, ben j’optai toujours sur la solution dont j'avais la maitrise. Mais ce comportement n'existe que dans de très rares cas à des fin de forte optimisation ou de sécurité aujourd'hui.
Le 06/07/2024 à 09h48
Ou tout coder soi même (ce qui semble vraiment compliqué) ?
Modifié le 06/07/2024 à 10h54
Après, dans tous les cas, on est pas censé mettre en prod de "latest", que ce soit des images de container ou des versions d'une bibliothèque. C'est une affreuse perte de maîtrise et un gros risque à s'exposer à des breaking changes quand ce ne sont pas des problèmes de sécu comme ici.
La supervision des mises à jour, ça s'automatise comme un rien. Les gestionnaires le font eux-même et des outils comme Dependabot chez GitHub le gèrent aussi. Et dans le cas des libs importées comme ça depuis l'extérieur, à mes yeux c'est une pratique aux antipodes de la sécurité. À voir aussi si les solutions SAST/SCA les vérifient ou non, j'ai un doute là dessus mais cela serait un minimum.
Le 06/07/2024 à 13h40
Modifié le 07/07/2024 à 10h46
Perso, juste avec du CSS et du HTML j'ai pu faire des templates Hugo qui ont des éléments interactifs comme un carrousel, déplier / replier des informations, et afficher des petites pop-up sur un "?".
Le seul élément JS que j'ai fini par mettre, c'était pour intégrer un fil Mastodon depuis le flux RSS de ce dernier.
Tout ceci me semble être la solution de facilité sacrifiant sur cet autel la maîtrise et la sécurité.
Le 07/07/2024 à 18h41
Le 08/07/2024 à 00h56
Modifié le 08/07/2024 à 08h15
Mais ce que j'ai le plus constaté, c'est qu'en réalité l'optim vient plutôt des coûts. Quand ceux-ci ne sont plus invisibles, on prend conscience qu'une bécane overkill pour faire tourner deux pauv' appli ça coûte très cher. Et je ne parle pas que de la facture du CSP
Modifié le 08/07/2024 à 10h09
Du coup, mes applis sont moches, semblent vieilles, mais ... elles fonctionnent internet coupé.
Ma dernière découverte (car au boulot nos sites DMZ n'ont par défaut pas le droit d'aller sur internet): Wordpress dépend d'internet, mais ses plugins, c'est pire! Et encore, quand ce n'est pas le presta lui-même qui héberge des scripts chez lui.
Vivement NIS2!