GitHub : des faux dépôts pour un faux malware ?
Si la campagne malveillante d’ampleur révélée par un développeur sur Twitter n’en était pas vraiment une, l’événement souligne les risques qui pèsent sur l’écosystème open source et la nécessité d’une plus grande transparence de la part des acteurs impliqués.
Dans un tweet publié le trois août 2022, Stephen Lacy, développeur, partage ses recherches. Il semblerait alors que le jeune développeur ait mis le doigt sur une « campagne maliciel d’ampleur » impactant, selon son premier message, quelque 35 000 dépôts de code sur GitHub. Il pense alors qu’une grande quantité de projets, dont ceux consacrés à Python, Kubernetes, Docker ou Golang ont été clonés. Puis, ils ont été infectés avec un malware apparemment conçu pour exfiltrer les variables env, dont les authentifiants des propriétaires : clés de sécurité, accès à AWS, clés API, etc.
Dans son préparatif, l’attaquant supposé semble avoir forké les dépôts GitHub, les a renommés en abusant du typosquatting, puis a modifié le dernier commit original en date en y ajoutant le code malicieux, après avoir usurpé l’identité de son véritable auteur.
Puis, il devait s’agir pour l’attaquant d’effectuer une merge resquest (une demande de fusion) de ce commit avec le projet original.
En principe, « La charge utile malveillante envoie des variables d’environnement sensibles à l’infrastructure de l’attaquant, puis attend qu’une commande de l’attaquant soit exécutée sur la machine », résume Jossef Harush Kadouri, responsable de l’ingénierie chez CheckMarx, dans un billet de blog.
Le tout devait être vers un serveur désigné par une adresse URL se terminant par myjino [.] ru.
I am uncovering what seems to be a massive widespread malware attack on @github.
— Stephen Lacy (@stephenlacy) August 3, 2022
- Currently over 35k repositories are infected
- So far found in projects including: crypto, golang, python, js, bash, docker, k8s
- It is added to npm scripts, docker images and install docs pic.twitter.com/rq3CBDw3r9
Il s’avère que l’URL en question est le dénominatif commun de ces projets clonés. Après avoir prévenu GitHub de cette campagne, Stephen Lacy précise que ce ne sont pas 35 000 dépôts qui sont potentiellement infectés, mais plutôt 35 000 fichiers contenant l’URL supposément malicieuse. Qui plus est, environ 13 000 URL sont présentes dans un seul dépôt dénommé « redhat-operator-ecosystem ».
Ces faux projets semblent avoir été créés dans la vingtaine de jours précédant la découverte de Stephen Lacy.
Des confrères de Bleeping Computer notent que si la majorité des dépôts clonés ont été altérés ces trois dernières semaines, certains d’entre eux l’étaient déjà depuis 2015.
Richard Hartmann, directeur de la communauté chez Grafana Labs, signale très rapidement que ce sont les dépôts clonés qui sont affectés et que Stephen Lacy devrait supprimer son premier tweet pour éviter la propagation d’informations erronées. Aussi, le vecteur d’attaque paraissait à ses yeux grossier et trop aléatoire pour que cette campagne soit réellement dangereuse. Il faut la plupart du temps valider manuellement un merge request.
Une réponse rapide, mais laconique
Quelques heures après le premier message de Stephen Lacy, Github s’est contenté d’un message laconique.
« Aucun dépôt n’a été compromis », indique l’équipe de sécurité de GitHub sur Twitter. « Le code malveillant a été posté dans les dépôts clonés, pas dans les dépôts eux-mêmes. Les clones ont été mis en quarantaine et il n’y a pas eu de compromission évidente des comptes GitHub ou des comptes des mainteneurs ».
Contacté par LeMagIT, le service presse de GitHub l’a renvoyé vers ce message sans offrir davantage de précisions quant à la chronologie de l’événement.
GitHub is investigating the Tweet published Wed, Aug. 3, 2022:
— GitHub Security (@GitHubSecurity) August 3, 2022
* No repositories were compromised
* Malicious code was posted to cloned repositories, not the repositories themselves
* The clones were quarantined and there was no evident compromise of GitHub or maintainer accounts
Les usagers de GitHub et les chercheurs en cybersécurité constatent, avant même cette annonce, les actions de la filiale de Microsoft. Le nombre de recherches positives à l’URL malicieuse a chuté à vue d’œil.
« GitHub semble avoir nettoyé la plupart, sinon la totalité [des dépôts clonés infectés], assez rapidement. Excellente réponse de leur part ! », s’exclame Stephen Lacy.
Pour certains, dont Florian Roth, responsable de la recherche chez Nextron Systems, GitHub a « effacé la scène du crime », avant que lui, son équipe et d’autres chercheurs puissent explorer en détail la nature de cette campagne.
La faute à un chasseur de primes ?
Hi Stephen,
— pl0x_plox_chiken_p0x (@Pl0xP) August 3, 2022
I'm sorry to rain on your parade, but what you've uncovered in GH is a bb effort.
I've discovered a problematic behavior in GH and was exploiting it for bounty (affected companies were contacted responsibly).
This is why I only exfiltrated the env variables.
Dans un même temps, un certain @Pl0xP répondait à Stephen Lacy sur Twitter :
« Bonjour Stephen, je suis désolé de gâcher votre quart d’heure de gloire, mais ce que vous avez découvert dans GH est un effort de Bug Bounty. J’ai découvert un comportement problématique dans GitHub et je l’exploitais pour [obtenir] une prime (les entreprises concernées ont été contactées de manière responsable). C’est pourquoi je n’ai exfiltré que les variables env ».
Cette affaire serait alors un « drama » ayant généré plus de peur que de mal et serait potentiellement due à une tentative maladroite de Bounty Hunting. « Cela reste à prouver », rétorque Jossef Harush Kadouri.
« Le code a exfiltré des variables d’environnement sensibles. Dans le cadre d’un POC [démonstrateur, NDLR], envoyer le nom de votre ordinateur est plus que suffisant », note-t-il. Aussi, le serveur malicieux a « tout de même envoyé des commandes à exécuter sur la machine de la victime ». Enfin, le compte Twitter @Pl0xP a fraîchement été créé, souligne-t-il.
« Je peux confirmer que je possède le serveur si vous le souhaitez », ajoute de son côté l’individu derrière le compte @PloxP.
Difficile d’en savoir davantage si GitHub ne rédige pas lui-même un postmortem au sujet de cet événement.
La réaction immédiate de l’entreprise semble toutefois proportionnée. Il s’agissait d’écarter la menace le plus rapidement possible, de vérifier les possibles compromissions et d’éviter d’éventuelles remontrances. Il faut dire que la filiale de Microsoft cherche depuis quelque temps à renforcer la sécurité de sa plateforme et des paquets NPM, régulièrement mis à mal, comme l’explique Kaspersky qui a trouvé récemment quatre paquets NPM infectés par un malware.
De manière générale, la sécurité de la chaîne logistique logicielle est de plus en plus à risque. GitHub multiplie les initiatives et les projets pour tenter d’y remédier, mais l’entreprise apparaît plus encline à passer par son programme de Bounty Hunting plutôt que de s’en remettre à une communauté élargie. Et pourtant, c’est bien parce que des individus alertes tels Stephen Lacy signalent ce type de comportements inhabituels, que le monde open source s’en porte mieux.