Vous n'installeriez jamais une application capable de se connecter à vos documents Google, d'enregistrer vos frappes dans votre navigateur, d'intercepter les requêtes en transit, de fonctionner en permanence, de se mettre à jour en arrière-plan ET d'être suffisamment puissante pour voler vos mots de passe, n'est-ce pas ? Eh bien, c'est plus ou moins ce que les extensions de navigateur peuvent faire, et elles créent des vulnérabilités qui dépassent le cadre d'un seul ordinateur, voire d'une seule entreprise.
Il y a quelques mois, un employé de Vercel a installé l'extension de navigateur Context.ai, relativement récente et très populaire, qui proposait une « suite bureautique IA ». Comme elle nécessitait une autorisation OAuth pour se connecter aux applications, lorsqu'un écran d'autorisation lui a demandé d'accorder à l'outil l'accès à son compte Google, il a cliqué sur « Autoriser ». Il ne s'agissait pas d'une extension approuvée en interne par Vercel, mais elle n'était pas non plus bloquée.
Fin février, un employé de Context.ai a téléchargé un programme de triche pour Roblox qui contenait un logiciel d' . Ce logiciel malveillant a mis la main sur le jeton OAuth de Vercel, qui est devenu le point d'entrée d'une attaque à grande échelle contre Vercel. L'attaquant n'a pas eu besoin de pirater Vercel. Il lui a suffi de pirater la start-up spécialisée dans l'IA à laquelle un employé de Vercel avait déjà fourni les clés d'accès.
Un logiciel malveillant a dérobé des données recueillies par une extension de navigateur « fantôme ». Ce scénario vous semble-t-il familier ? Cela ressemble à une attaque de la chaîne d'approvisionnement, et c'est bien de cela qu'il s'agit.
En quoi la faille de Vercel constituait une attaque de la chaîne d'approvisionnement
Les extensions de navigateur sont devenues l’un des vecteurs d’attaque les plus sous-estimés dans le domaine de la sécurité d’entreprise, et la faille de Vercel n’en est que le dernier exemple en date. L’attaque a suivi un schéma bien connu du secteur de la sécurité dans le domaine des dépendances open source : un code tiers, considéré comme fiable par défaut, est compromis en amont. Nous avons donné un nom à ce schéma et développé toute une catégorie d’outils autour de celui-ci, mais le secteur dans son ensemble ne les a pas encore appliqués aux extensions de navigateur.
Une attaque par la chaîne d'approvisionnement repose sur plusieurs éléments clés. Il faut du code tiers s'exécutant avec des privilèges réels, une confiance implicite, et des victimes n'ayant aucun lien direct avec la source de la compromission initiale. La faille de Vercel remplit ces trois conditions. Context.ai était un produit réel remplissant une fonction réelle, et l'accès OAuth qui lui avait été accordé à Google Workspace constituait une demande raisonnable au regard de ce qu'il cherchait à faire (même si l'on peut soutenir que cela représentait un peu trop de confiance et de pouvoir). Cela signifiait qu'un jeton OAuth hautement privilégié se trouvait dans le backend AWS de Context.ai, à seulement un appareil d'employé compromis de devenir la propriété d'un attaquant.
Lorsqu’un employé de Context.ai a installé un logiciel de vol d’informations sur son propre ordinateur, la confiance qu’il avait accordée à une extension auparavant légitime a servi de porte d’entrée vers les environnements internes de l’entreprise. La faille initiale s’est produite ailleurs, mais c’est Vercel qui en a fait les frais. C’est ce que l’on appelle une attaque de la chaîne d’approvisionnement.
Le cas de Vercel n'est pas la première attaque par logiciel malveillant à utiliser des extensions de navigateur dans le cadre d'une attaque de la chaîne d'approvisionnement. Par exemple, la violation de Cyberhaven fin 2024 était une version ciblée d'un scénario similaire, les extensions destinées aux développeurs étant spécifiquement dans le collimateur des attaquants. L'extension Chrome de Cyberhaven a été compromise via une attaque de phishing visant un compte de développeur, et une mise à jour malveillante a été diffusée aux utilisateurs avant que quiconque ne s'en aperçoive. La version malveillante est restée active pendant environ 24 heures.
Le modèle de mise à jour silencieuse présente davantage de risques
Le modèle de mise à jour des extensions est quelque peu risqué d'un point de vue sécuritaire. Contrairement aux logiciels du système d'exploitation, les extensions de navigateur se mettent à jour de manière silencieuse et automatique. Le code qui s'exécute aujourd'hui sur votre navigateur n'est peut-être plus celui de l'application que vous aviez acceptée lors de son installation. Contrairement aux autres mises à jour logicielles qui vous invitent à effectuer la mise à jour (pendant des mois, alors que vous continuez à cliquer sur « Mettre à jour plus tard »), aucune invite ne demande le consentement de l'utilisateur pour la mise à jour. La seule fois où vous recevriez une notification, c'est lorsque l'extension demande des autorisations supplémentaires. Une extension qui était propre le mois dernier pourrait recevoir une mise à jour malveillante ce soir, et tous les utilisateurs qui l'ont installée la recevraient automatiquement. Si elle disposait déjà de nombreuses autorisations, vous seriez en difficulté. Imaginez si les dépendances logicielles se mettaient à jour automatiquement et en silence sur votre machine de développement.
Ce qui n'a pas fonctionné
Les entreprises ont souvent tenté soit de créer des listes d'extensions autorisées (en bloquant tout le reste), soit l'inverse, c'est-à-dire des listes d'extensions bloquées. Mais dans les deux cas, la mise à jour et la gestion de ces listes se heurtent à des obstacles évidents. Environ la moitié des auteurs d'extensions sont inconnus, et la plupart des éditeurs n'ont publié qu'une seule extension ; la gestion des extensions sur la base de leur réputation ne fonctionne donc que pour une petite partie d'entre elles. De toute façon, même les grandes entreprises publient des extensions qui ne sont pas irréprochables. Il est impossible de maintenir manuellement une liste interne précise et à jour.
SCA a été mise au point pour résoudre ce problème au niveau des paquets. Les mécanismes qui s'appliquent aux dépendances open source se basent sur ce que fait le paquet (et non sur son nom ou les fonctionnalités annoncées). Approuver des paquets npm sur la seule base de leur nom, sans analyse du code ni renseignement sur les menaces, ne constituerait pas une sécurité de la chaîne d'approvisionnement pour les dépendances. Mais remplacez « paquet npm » par « extension Chrome », et c'est plus ou moins l'approche adoptée ces dernières années en matière de sécurité des navigateurs.
Considérons les extensions de navigateur comme n'importe quel autre vecteur de la chaîne d'approvisionnement
Même si les boutiques en ligne ne le montrent pas, la confiance accordée au moment de l'installation ne suffit pas. Nous devons appliquer ici la même philosophie que pour la sécurité des paquets logiciels. Les entreprises doivent savoir ce qui est installé sur l'ensemble de leurs machines et elles ont besoin surveillance continue qu'une extension apparemment inoffensive qui deviendrait malveillante ne passe pas inaperçue.
La plupart des équipes de sécurité sont capables de définir un modèle de menace de la chaîne d’approvisionnement pour les dépendances. Elles savent que les comptes des responsables de maintenance peuvent être compromis et qu’un paquet qui était sain au trimestre dernier peut constituer un vecteur d’attaque aujourd’hui (et nous avons d’ailleurs assisté attaques de la chaîne d’approvisionnement à de nombreuses attaques de la chaîne d’approvisionnement très médiatisées). Cependant, en tant que secteur, nous n’avons pas appliqué ces connaissances aux extensions de navigateur dans la même mesure.
Ce qui fonctionne pour les dépendances peut également s'appliquer aux extensions de navigateur. analyse des dépendances logicielles analyse des dépendances car les renseignement sur les menaces sous-jacentes renseignement sur les menaces jour : la vérification s'effectue par rapport à des bases de données actualisées à mesure que de nouvelles menaces sont découvertes, plutôt que par rapport à une liste compilée au trimestre dernier. Le blocage des extensions de navigateur avant leur installation doit fonctionner de la même manière. attaques de la chaîne d’approvisionnement rapidement, et une liste blanche qui était exacte le mois dernier ne sait pas qu’une extension a changé de mains ou a reçu une mise à jour malveillante la semaine dernière.
Les entreprises ont également besoin de savoir précisément ce qui est installé sur chaque appareil utilisé par les développeurs. Les gestionnaires de paquets laissent des traces, telles que des fichiers de verrouillage et des listes de dépendances stockées dans les référentiels, mais ce n'est pas le cas des extensions de navigateur. La seule façon de s'en assurer est de procéder à un audit systématique de tous les appareils au sein de l'entreprise. Il est impossible de réagir à des menaces dont on ignore l'existence, et de nombreuses entreprises ne disposent pas des outils nécessaires pour y parvenir.
Enfin, tous les membres d'une organisation, des ingénieurs aux responsables des ressources humaines, doivent être conscients des risques liés aux extensions de navigateur. Si les failles de sécurité liées aux dépendances font beaucoup parler d'elles, ce n'est pas le cas de la sécurité des navigateurs. Même si l'on sait généralement que ces derniers ne sont pas très sûrs, on ignore souvent l'existence de failles majeures telles que le vol d'identifiants. Nous devons sensibiliser nos équipes et nos organisations aux risques et aux bonnes pratiques (en leur envoyant cet article, par exemple).
Prévenir la prochaine attaque de type Vercel visant la chaîne logistique
La faille Vercel ne sera pas le dernier incident dans lequel une extension de navigateur fera partie de la chaîne d'attaque. La surface d'attaque est trop lucrative, et les mesures de sécurité sur lesquelles s'appuient la plupart des organisations sont trop limitées pour que la situation change d'elle-même. Il faut considérer la sécurité des extensions de navigateur comme le problème de chaîne d'approvisionnement qu'elle est déjà, de préférence avant la prochaine attaque (et non après).
Aikido utilise un modèle de sécurité de la chaîne d'approvisionnement pour protéger les appareils des développeurs. Les extensions malveillantes sont bloquées avant même d'être installées ; celles dont la nature malveillante est connue sont vérifiées par rapport à Aikido avant d'atteindre l'appareil. La base de données Aikido qui alimente ce système identifie jusqu'à 100 000 paquets malveillants par jour ; elle est accessible au public et peut être consultée gratuitement sur intel.aikido.dev.
Découvrez-en davantage sur Aikido ou consultez le fluxAikido pour voir en temps réel ce qui a été détecté dans les écosystèmes open source.
