Plus de 100 000 dépôts infectés découverts sur GitHub

Plus de 100 000 dépôts infectés découverts sur GitHub

• Une équipe de recherche en sécurité et de data science a détecté la réapparition à grande échelle d’une campagne malveillante de confusion de dépôts, lancée au milieu de l’année dernière.
• Cette attaque affecte plus de 100 000 dépôts GitHub (et probablement des millions, selon les estimations) lorsque des développeurs utilisent des dépôts qui ressemblent à des dépôts connus et fiables, mais qui contiennent en réalité du code malveillant.

Comment se produit une attaque par confusion de dépôts ?

• Les attaques par confusion de dépôts sont similaires aux attaques par confusion de dépendances : des acteurs malveillants amènent la cible à télécharger une version malveillante à la place de la vraie version.
• Alors que les attaques par confusion de dépendances exploitent le fonctionnement des gestionnaires de paquets, les attaques par confusion de dépôts reposent sur le fait que des personnes sélectionnent par erreur la version malveillante à la place de la vraie, parfois avec des techniques d’ingénierie sociale.

Ce qui se passe lorsqu’un dépôt malveillant est utilisé

• Lorsque des développeurs utilisent sans méfiance un dépôt malveillant, une charge utile cachée lève 7 niveaux d’obfuscation, puis récupère du code Python malveillant et ensuite des exécutables binaires.
• Le code malveillant collecte les identifiants de connexion de diverses applications, les mots de passe et cookies de navigateur, ainsi que d’autres données sensibles, puis les envoie au serveur C&C des attaquants et exécute d’autres activités malveillantes.

Impact de l’automatisation sur GitHub

• La plupart des dépôts forkés sont rapidement supprimés par GitHub, mais la détection automatisée en manque beaucoup, et les dépôts mis en ligne manuellement survivent.
• Comme l’ensemble de la chaîne d’attaque est en grande partie automatisé à grande échelle, le 1 % qui survit représente encore des milliers de dépôts malveillants.

Quand la campagne a commencé

• Mai 2023 : selon un premier signalement de Phylum, plusieurs paquets malveillants contenant la partie initiale de la charge utile actuelle ont été publiés sur PyPI.
• Juillet - août 2023 : après la suppression des paquets malveillants par PyPI et une attention accrue de la communauté sécurité, plusieurs dépôts malveillants ont été publiés sur GitHub, livrant directement la charge utile au lieu de récupérer les paquets PyPI.
• Novembre 2023 - aujourd’hui : plus de 100 000 dépôts contenant des charges utiles malveillantes similaires ont été détectés, et leur nombre continue d’augmenter.

Transition du malware des gestionnaires de paquets vers la gestion de code source (SCM)

• Au vu des nombreux incidents observés sur les gestionnaires de paquets et les plateformes de SCM, le passage de cette campagne des paquets malveillants sur PyPI aux dépôts malveillants sur GitHub semble refléter une tendance générale.

Comment se protéger contre la confusion de dépôts

• GitHub a été alerté et la plupart des dépôts malveillants ont été supprimés, mais la campagne se poursuit et les attaques visant à injecter du code malveillant dans la supply chain deviennent de plus en plus fréquentes.
• Apiiro a mis en place un système de détection de malware qui surveille les codebases connectées.
• Pour détecter les attaques, il utilise diverses techniques avancées, dont l’analyse de code basée sur les LLM, la décomposition du code en graphe de flux d’exécution complet, un moteur heuristique sophistiqué, ainsi que le décodage dynamique, le déchiffrement et la désobfuscation.

L’avis de GN⁺

• Cet article fournit aux développeurs des informations importantes sur les menaces de sécurité à connaître lorsqu’ils utilisent des dépôts GitHub.
• En comprenant comment les malwares s’infiltrent dans la supply chain logicielle, les développeurs et les professionnels de la sécurité peuvent mettre en place des mécanismes de défense plus robustes.
• Ces attaques soulignent non seulement la capacité des développeurs à choisir des dépôts fiables, mais aussi la dépendance à la justesse des configurations CI/CD et à la sécurité du code tiers.
• D’un point de vue critique, elles montrent que les systèmes automatisés de plateformes comme GitHub et l’existence de dépôts à grande échelle peuvent être une arme à double tranchant.
• Parmi les outils de sécurité proposant des fonctions similaires, on peut citer SonarQube, Snyk et WhiteSource, qui peuvent aider à détecter les vulnérabilités du code et à renforcer la sécurité.
• Avant d’adopter cette technologie, il faut prendre en compte la compatibilité avec les politiques de sécurité de l’organisation, le coût de mise en œuvre et les compétences techniques des membres de l’équipe.
• Les avantages attendus sont un renforcement de la sécurité et une réduction des risques, mais les inconvénients potentiels incluent la courbe d’apprentissage d’un nouveau système et la complexité de sa gestion.

[GN⁺]

Avis Hacker News

• Il faut être prudent lorsqu’on récupère du code depuis des dépôts publics, et il est important de vérifier l’arbre des dépendances. Cela soulève la question de l’impact que les malwares présents dans les dépôts publics peuvent avoir sur les outils automatisés comme les grands modèles de langage (Large Language Models, LLMs). Par exemple, des outils comme GitHub Copilot pourraient inclure par erreur du malware dans leurs réponses à des questions de programmation.
• Il est souligné que GitHub est en train d’échouer de la même manière qu’Usenet a échoué. N’importe qui peut créer un dépôt sur GitHub, et il n’existe aucun moyen de distinguer les dépôts officiels de ceux des spammeurs. Quand Amazon a voulu devenir « le magasin qui vend tout », il s’est retrouvé confronté au fait que la plupart des produits étaient des déchets. GitHub doit définir son identité : est-ce « le dépôt pour tout le monde », ou bien « peut-on faire confiance à ce code » ?
• Il est déploré que les problèmes de supply chain soient graves. Même si cela ne cible pas les releases npm, socket.dev est utilisé pour surveiller les projets. Le projet BrowserBox utilise environ 800 dépendances, dont 19 dépendances de premier niveau. Il est envisagé de faire un snapshot de toutes les dépendances dans l’espace de noms npm @browserbox afin de suivre les vulnérabilités et d’appliquer des correctifs.
• Il est souligné que les développeurs devraient séparer au moins trois environnements : travail, loisirs et usage personnel. Même pour des dépôts et des propriétaires de confiance, il est judicieux d’exécuter le code dans une machine virtuelle sandboxée.
• Si l’on développe un SDK dans une petite équipe et qu’il reçoit beaucoup de téléchargements hebdomadaires, on est en train d’évaluer des solutions basées sur snyk, aikido.dev, renovate, etc. Il n’est pas clair que ces outils aideront réellement à résoudre le problème, et gérer un grand nombre de faux positifs, comme cela a été le cas avec snyk, est difficile.
• Quelqu’un se demande si la méthode d’installation par script shell utilisant curl et sudo va bientôt disparaître. Cette méthode est étroitement liée au logiciel infecté mentionné dans l’article.
• Sur npm, l’option --ignore-scripts peut être utilisée pour empêcher l’exécution de malware.
• Il est mentionné qu’il y a eu, il y a moins d’un an, des dépôts contenant des chevaux de Troie.
• Il est critiqué que les publications récentes sur les problèmes de sécurité débouchent sur des publicités demandant de financer des startups LLM. Ces startups ne peuvent résoudre qu’une partie des failles de sécurité, et signer avec un grand nombre de startups peut entraîner des problèmes de coût et d’intégration.
• En raison des rapports de sécurité continus, la sécurité de l’environnement de développement est progressivement renforcée. Sont notamment testés : les conteneurs de développement VSCode, GitHub Codespaces, la lecture des recommandations OWASP, ainsi que la revue des packages npm/Python avec socket.dev.