malveillant VS Extensions de code : l'attaque qui a exposé 3 800 dépôts internes

GitHub a confirmé qu'un dispositif d'un employé engagé par une extension malveillante de Visual Studio Code a permis l'exfiltration de centaines ou de milliers de dépôts internes; la figure qui circule - autour 3 800 dépôts internes- coïncide "directionnellement" avec l'évaluation interne que l'entreprise a faite jusqu'à présent. GitHub dit qu'il a retiré la version empoisonnée de l'extension du marché, isolé le paramètre touché et initié la réponse aux incidents, et à l'heure actuelle n'a trouvé aucune preuve que les données des clients en dehors de ces dépôts internes ont été compromises ( Déclaration de GitHub).

Parallèlement, un acteur qui s'identifie comme TeamPCP a publié des échantillons présumés du butin et a essayé de négocier la vente de données dans les forums criminels, une tactique que nous avons déjà vue avec des attaques sur la chaîne d'approvisionnement logiciel. Cet épisode montre à nouveau deux réalités simultanées: les outils de développement sont désormais un vecteur d'attaque à impact élevé et les attaquants continuent d'exploiter la confiance que les équipes mettent dans des extensions et des suppléments tiers.

VS Les extensions de code sont très utiles pour les développeurs mais aussi dangereux s'ils sont threaded: ces dernières années, plusieurs cas de plugins sont apparus avec des millions de téléchargements qui ont volé des identifiants, filtré des fichiers locaux ou des logiciels malveillants déployés comme cryptomineros. Qu'une seule extension malveillante peut ouvrir la voie à l'exfiltration de dépôts internes confirme que la surface d'attaque n'est pas seulement le code lui-même, mais les outils avec lesquels vous travaillez. Pour comprendre le fonctionnement de l'écosystème et les précautions à prendre, Microsoft tient à jour la documentation officielle sur le marketing et les extensions dans le code VS ( Code VS Documentation du marché).

Quelles sont les conséquences pratiques pour les entreprises et les développeurs? À court terme, toute organisation ayant des intégrations ou des dépendances directes des dépôts concernés doit prendre des risques : code propriétaire, scripts de déploiement, jetons intégrés ou documentation interne aurait pu être compromise. Bien que GitHub n'attribue toujours pas publiquement l'intrusion ou ne confirme pas la portée complète, la prudence oblige cet incident à être traité comme un grave déficit de sécurité et de prendre des mesures immédiates.

Recommandations opérationnelles qui devraient déjà être mises en œuvre : vérifier et faire pivoter les justificatifs d'identité et les jetons avec accès aux dépôts internes et aux systèmes connexes; vérifier les registres GitHub et les registres de réseau pour identifier les clones, les accès atypiques ou les transferts de masse; forcer la régénération des clés personnelles et de service en cas de doute; et maintenir les paramètres affectés par les solutions EDR ou l'analyse médico-légale isolés et analysés. GitHub offre des outils et de la documentation pour la gestion des jetons, les dossiers de vérification et la numérisation secrète qui devraient être intégrés à ces processus ( gestion des jetons en GitHub).

À moyen et à long terme, les organisations devraient accroître le contrôle sur l'environnement de développement : mettre en oeuvre des politiques d'installation d'extension (autorisation / déni de liste) ou interdire les installations locales dans les machines qui ont accès à des dépôts critiques; déplacer les environnements de développement vers des conteneurs ou des comptoirs isolés; appliquer le principe du privilège mineur dans les jetons et les permis de dépôt; automatiser le balayage des secrets dans les commits et les artefacts. En outre, il est essentiel d'intégrer l'IDE et la télémétrie en fin de ligne à des systèmes de détection interne pour détecter des comportements étranges d'extensions et de processus.

Pour les développeurs individuels, la recommandation pratique est extrêmement prudente : n'installez que des extensions d'éditeurs bien entretenues par des auteurs vérifiés, examinez le code source de l'extension si possible, vérifiez les autorisations que vous demandez et préférez les utilisations dans des environnements isolés lorsque vous travaillez avec des dépôts sensibles. La communauté et les fournisseurs doivent exiger une plus grande sécurité sur le marché: des signatures d'extension, une validation automatisée plus stricte et la transparence sur les unités et la télémétrie des plugins.

Cet incident rappelle que la sécurité des logiciels modernes inclut la sécurité des outils qui les produisent. Les entreprises, les fournisseurs de plateformes et les développeurs ont des rôles différents mais complémentaires : les plateformes doivent resserrer l'examen et la distribution des extensions, et les organisations doivent supposer que le travail du développeur est un atout essentiel qui nécessite des contrôles aussi rigoureux que ceux appliqués aux infrastructures de production. Pour ceux qui veulent approfondir la façon d'atténuer les risques dans la chaîne d'approvisionnement des logiciels, il est approprié de lire des ressources spécialisées et des guides communautaires sur le durcissement de la chaîne d'approvisionnement (p. ex. projets publics et recommandations dans le PAOAO et documents sur la sécurité des fournisseurs). OWASP - Attaques de la chaîne d'approvisionnement.