Vous n'installeriez jamais une application capable de se connecter à vos documents Google, de lire vos frappes au clavier dans votre navigateur, d'intercepter les requêtes en transit, de fonctionner en continu, de se mettre à jour silencieusement ET qui pourrait être suffisamment puissante pour voler vos mots de passe, n'est-ce pas ? Eh bien, c'est plus ou moins ce que peuvent faire les extensions de navigateur, et elles créent des vulnérabilités qui dépassent un seul ordinateur, voire une seule entreprise.
Il y a quelques mois, un employé de Vercel a installé l'extension de navigateur Context.ai, relativement nouvelle et populaire, qui offrait une « suite bureautique IA ». Elle nécessitait une autorisation OAuth pour se connecter aux applications. Ainsi, lorsque l'écran d'autorisations leur a demandé d'accorder à l'outil l'accès à leur compte Google, ils ont cliqué sur autoriser. Ce n'était pas une extension que Vercel avait approuvée en interne, mais elle n'était pas non plus bloquée.
Fin février, un employé de Context.ai a ensuite installé un téléchargement de triche Roblox qui contenait un infostealer. Ce malware a trouvé 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 a eu besoin de pirater la startup d'IA dont un employé de Vercel avait déjà donné les clés.
Un malware a volé des données collectées à partir d'une extension de navigateur fantôme. Le schéma vous semble familier ? Cela ressemble à une attaque de la chaîne d’approvisionnement, et c'en est une.
Comment la brèche Vercel était 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 en matière de sécurité d'entreprise, et la brèche Vercel n'en est que le dernier exemple. L'attaque a suivi un schéma que l'industrie de la sécurité connaît bien grâce aux dépendances open source, où un code tiers bénéficie d'une confiance implicite, puis est compromis en amont. Nous avons un nom pour ce schéma et toute une catégorie d'outils conçus autour de lui, mais l'industrie dans son ensemble ne les a pas encore appliqués aux extensions de navigateur.
Une attaque de la chaîne d'approvisionnement comporte quelques ingrédients principaux. Il faut un code tiers s'exécutant avec de réels privilèges, une confiance implicite et des victimes sans relation directe avec la source de la compromission initiale. La brèche 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 était une demande raisonnable pour ce qu'il cherchait à faire (bien qu'il s'agisse sans doute d'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, à un seul appareil d'employé compromis de devenir la propriété d'un attaquant.
Lorsque cet employé de Context.ai a installé un infostealer sur sa propre machine, la confiance qu'un seul employé avait accordée à une extension auparavant légitime est devenue le chemin d'accès à leurs environnements internes. La brèche originale s'est produite ailleurs, mais Vercel en a souffert. Et c'est ce que nous appelons une attaque de la chaîne d'approvisionnement.
Le cas de Vercel n'est pas la première attaque de malware à 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, avec des extensions axées sur les développeurs spécifiquement dans le viseur des attaquants. L'extension Chrome de Cyberhaven a été compromise via une attaque de phishing sur un compte développeur, et une mise à jour malveillante a été poussé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 génère plus de danger
Le modèle de mise à jour des extensions est un peu chaotique si l'on l'examine sous l'angle de la sécurité. Contrairement aux logiciels de système d'exploitation, les extensions de navigateur se mettent à jour silencieusement et automatiquement. Le code exécuté sur votre navigateur aujourd'hui pourrait ne pas être l'application que vous avez acceptée lors de son installation. Contrairement à d'autres mises à jour logicielles qui vous invitent à mettre à jour (pendant des mois, alors que vous continuez à cliquer sur « Mettre à jour plus tard »), il n'y a aucune invite pour obtenir 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 chaque utilisateur l'ayant installée la recevrait automatiquement. Si elle disposait déjà de nombreuses autorisations, vous seriez en difficulté. Imaginez si les dépendances logicielles se mettaient à jour automatiquement et silencieusement sur votre machine de développement.
Ce qui n'a pas fonctionné
Les entreprises ont souvent essayé de créer des listes d'extensions autorisées (bloquant tout le reste) ou l'inverse, des listes d'extensions bloquées. Mais dans les deux cas, maintenir la liste à jour et pertinente présente des obstacles évidents. Environ la moitié des auteurs d'extensions sont inconnus, et la plupart des éditeurs n'ont publié qu'une seule extension, de sorte que la gestion des extensions basée sur la réputation ne fonctionne que pour une petite partie d'entre elles. Même les grandes entreprises publient des extensions qui ne sont pas irréprochables. Maintenir manuellement une liste interne précise et à jour est impossible.
L'analyse SCA a été inventée pour résoudre ce problème pour les packages. Les mécanismes qui fonctionnent pour les dépendances open source opèrent sur ce que fait le package (et non sur son nom ou sa fonctionnalité revendiquée). Approuver des packages npm uniquement par leur nom, sans analyse de code ni renseignement sur les menaces, ne serait pas considéré comme de la sécurité de la chaîne d'approvisionnement pour les dépendances. Mais remplacez « package npm » par « extension Chrome », et c'est plus ou moins l'approche de la sécurité des navigateurs ces dernières années.
Traitons les extensions de navigateur comme d'autres vecteurs de la chaîne d'approvisionnement
Bien que les marketplaces ne le reflètent pas, la confiance au moment de l'installation ne suffit pas. Nous devons appliquer la même philosophie ici que pour la sécurité des packages. Les organisations doivent savoir ce qui est installé sur toutes les machines, et elles ont besoin d'une surveillance continue afin qu'une extension apparemment propre qui devient malveillante ne passe pas inaperçue.
La plupart des équipes de sécurité peuvent articuler un modèle de menace de la chaîne d'approvisionnement pour les dépendances. Elles savent que les comptes de mainteneurs sont compromis, et qu'un package qui était propre le trimestre dernier peut être un vecteur aujourd'hui (et nous avons vu beaucoup d'attaques de la chaîne d’approvisionnement très médiatisées récemment). Cependant, en tant qu'industrie, nous n'avons pas appliqué ces connaissances aux extensions de navigateur dans la même mesure.
Ce qui fonctionne pour les dépendances peut aussi fonctionner pour les extensions de navigateur. L'analyse des dépendances logicielles fonctionne parce que le renseignement sur les menaces sous-jacent reste à jour, vérifiant les bases de données qui se mettent à jour à mesure que de nouvelles menaces sont découvertes, plutôt qu'une liste compilée le trimestre dernier. Le blocage pré-installation pour les extensions de navigateur doit fonctionner de la même manière. Les attaques de la chaîne d’approvisionnement évoluent rapidement, et une liste blanche qui était précise le mois dernier ne sait pas qu'une extension a changé de propriétaire ou a reçu une mise à jour malveillante la semaine dernière.
Les organisations ont également besoin de visibilité sur ce qui est installé sur chaque appareil de développeur. Les gestionnaires de packages laissent une trace écrite comme les fichiers de verrouillage et les listes de dépendances qui résident dans les dépôts, mais les extensions de navigateur n'ont pas cela. La seule façon de le savoir est d'auditer activement tous les appareils de l'organisation. Vous ne pouvez pas réagir à des menaces dont vous ignorez l'existence, et de nombreuses entreprises ne disposent pas des outils nécessaires pour cela.
Enfin, tous les membres d'une organisation, des ingénieurs aux RH, doivent être conscients des risques liés aux extensions de navigateur. Les vulnérabilités des dépendances ont fait l'objet de beaucoup d'attention médiatique, mais moins la sécurité des navigateurs. Bien que les gens sachent généralement qu'elles ne sont pas idéales, ils ne sont souvent pas aussi conscients de ces vulnérabilités majeures comme le vol d'identifiants. Nous devons éduquer nos équipes et nos organisations sur les risques et les meilleures pratiques (envoyez-leur cet article, par exemple).
Prévenir la prochaine attaque de la chaîne d’approvisionnement de type Vercel
La violation de Vercel ne sera pas le dernier incident où une extension de navigateur fait partie de la chaîne de destruction. La surface d'attaque est trop précieuse, et les contrôles sur lesquels la plupart des organisations s'appuient sont trop limités pour que cela change d'elle-même. Traitez la sécurité des extensions de navigateur comme le problème de chaîne d'approvisionnement qu'elle est déjà, espérons-le avant la prochaine attaque (et non après).
Aikido Endpoint applique 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 d'être installées, connues comme malveillantes, vérifiées par Aikido Intel avant qu'elles ne touchent l'appareil. Le flux Aikido Intel qui l'alimente identifie jusqu'à 100 000 packages malveillants par jour et est public et gratuit à explorer sur intel.aikido.dev.
En savoir plus sur Aikido Endpoint ou explorer le flux Aikido Intel pour voir ce qui a été détecté en temps réel dans les écosystèmes open source.
