Connexion
Abonnez-vous

La bibliothèque Polyfill détournée, des centaines de milliers de sites touchés

Chaine d'approvisionnement, cas d'école

La bibliothèque Polyfill détournée, des centaines de milliers de sites touchés

Crédits : JJ Ying (Unsplash)

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

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.

Commentaires (15)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
« Si vous possédez un site web, charger un script implique une incroyable relation de confiance avec ce tiers. Leur faites-vous vraiment confiance ? »
C'est pour ça que je râle à chaque fois que je vois un reCaptcha (ou équivalent) sur une page d'identification. Ça a été le cas pendant très longtemps sur ÉDF par exemple.
Alors j'imagine qu'ils utilisent Subresource Integrity, mais je ne suis pas allé vérifier à chaque fois.
votre avatar
D'une manière générale, il faut maîtriser (limiter) les dépendances des projets web envers les librairies tierces.

C'est un vœu pieux, mais ne pas utiliser un marteau pour écraser une mouche est une bonne habitude.
votre avatar
Vu qu'un projet NodeJS c'est un gloubiboulga de dépendances et de dépendances transitives avec à peu près aucune maîtrise, c'est plus qu'un vœu pieu.

Le SCA a de beaux jours devant lui.
votre avatar
Si limiter les dépendances est généralement une bonne chose, le problème ici est légèrement différent. Les sites vulnérables ne le sont pas parce qu'ils ont un polyfill en dépendance. Ils le sont car ils utilisent le CDN de polyfill, qui s'est mis à fournir du contenu vérolé.

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.
votre avatar
Je plussoie ! L'un n'excluant pas l'autre, bien au contraire : la disponibilité de ces libs via des CDN facilite leur large utilisation.

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.
votre avatar
"dépendre d'un site tier est un SPOF", épisode 15752
votre avatar
Je me souvient il y a qqes années, le projet android par défaut, juste pour "Hello World" faisait x Mega, car il embarquait toutes les bibliothèques de bases.
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.
votre avatar
Quelle serait la solution ? Télécharger les scripts pour les mettre sur son serveur et monitorer les mise à jour ?
Ou tout coder soi même (ce qui semble vraiment compliqué) ?
votre avatar
Comme indiqué par @Glandos en #1, il existe déjà des mécanismes indiquant qu'on valide un checksum pour la bibliothèque chargée à distance.

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.
votre avatar
Ça pourrait parfaitement arriver un jour à jQuery ! ce truc inutile utilisé absolument partout.
votre avatar
J'ai l'impression que les dev web ne savent plus rien faire sans devoir importer 3 tonnes de lib javascript pour faire des pages web de 4 lignes de texte et deux images pour 45MB au total.

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é.
votre avatar
oui avec quelques css (:hover, transition) tu peux faire beaucoup d'effet, pour le JS, tu peux tout faire sans importer des librairies tierces.
votre avatar
Carrément d'accord... et sans parler de la lourdeur d'un code quand l'ensemble d'une bibliothèque est chargée pour qq fonctions basiques : ca n'est pas très écoresponsable.
votre avatar
J'avoue que le Green IT est une notion qui me fait sourire, car une bonne partie de ses éléments ne sont rien d'autre que de la bonne vieille optimisation qu'on a laissée derrière en se disant "pas grave, j'ai 3TB de RAM et 76CPU faut que ça serve". Et au final elle est tout autant ignorée parce que dans la tête de beaucoup, ce n'est que de la "bonne conscience".

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 :non:
votre avatar
J'ai une politique no-CDN en dev. Et très forte limitation des dépendances (quand on arrive à suivre qui dépend de qui...).

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!

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

Fermer