Crédits : Unsplash

Sur GitHub et GitLab, des commentaires détournés pour stocker des malwares

Ayez confianssssssssssssssse 🐍

18

Crédits : Unsplash

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Depuis au moins plusieurs semaines, des acteurs malveillants se servent des commentaires de GitHub pour distribuer des malwares. Un détournement des commentaires que l’on retrouve également dans GitLab depuis peu. À moins de fermer complètement les commentaires sur un dépôt, il ne semble pas y avoir de solution simple au problème.

Le moins que l’on puisse dire est que les pirates ne manquent jamais d’astuce pour conduire les internautes à effectuer des actions malveillantes. On a pu encore le voir récemment avec la vague de phishing ayant visé les clients de LastPass, à l’aide d’informations volées dans de précédentes fuites, dont celle de LastPass probablement.

L’ingéniosité ne passe pas toujours par l’ingénierie sociale. BleepingComputer s’est ainsi penché sur un drôle de phénomène : des acteurs malveillants se servent des commentaires de GitHub pour distribuer des malwares. Comment ? En détournant une fonction existante, permettant de téléverser des fichiers. Les pirates peuvent presque leur donner une allure respectable, à même de leurrer une partie des utilisateurs.

Des liens à l’apparence respectable

Sur GitHub, il est possible de joindre un fichier à un commentaire. Une fonction pratique, permettant de montrer rapidement un exemple d’une situation, une capture d’écran d’un problème, etc. Selon le type de fichier, la destination n’est pas la même. Ainsi, les images et vidéos vont dans le dossier /assets/. Les autres vont dans /files/.

Point crucial, toutes ces données sont stockées dans un dossier du dépôt, mais n’en font pas partie à proprement parler. Il s’agit d’un stockage annexe, afin que les fichiers ne soient pas mélangés avec ceux du projet.

Cependant, l’apparence du lien peut suggérer qu’il s’agit d’un fichier hébergé par le dépôt, comme le montre la capture ci-dessous, publiée par BleepingComputer :

Elle illustre parfaitement le problème : si l’on ne sait pas comment fonctionne le téléversement des fichiers dans les commentaires, il est aisé de se faire avoir. L’adresse est tout ce qu’il y a de plus officielle et contient le nom du dépôt sur lequel est laissé le commentaire. Si l’on ne connait pas ce fonctionnement, seule la méfiance ou l’utilisation d’une solution antivirale (ou au moins un passage par VirusTotal) peut sauver la machine d’une infection.

Ces liens sont générés automatiquement par GitHub. Ils restent valides même en cas de suppression ou si le commentaire n’est finalement pas publié. Le fichier téléversé pendant la préparation du commentaire reste stocké dans son dossier.

Un problème découvert en février

Ce détournement des commentaires était en fait connu depuis au moins février. Il a fait l’objet de publications, notamment sur X. On trouve par exemple une vidéo explicative de Sergei Frankoff (herrcore), qui montre le déroulé de l’opération et le danger lié. Datée du 27 mars, elle évoque un problème durant « depuis des semaines ».

Le problème a pris une toute autre ampleur à la publication d’un article de McAfee au sujet d’un nouveau malware. Apparemment lié à Redline, un célèbre malware voleur lui aussi, il en reprend l’infrastructure de contrôle. Cependant, il ne dérobe pas d’informations et présente des spécificités, dont l’utilisation de bytecode écrit en Lua pour échapper à la détection et en lui permettant de s’injecter dans des processus légitimes.

Le malware est distribué sous la forme d’un fichier Zip contenant un fichier d’installation MSI. Ce dernier décompresse alors trois fichiers : compiler.exe, lua51.dll et un fichier readme.txt contenant le bytecode Lua. Les personnes intéressées croient télécharger un moteur de triche pour les jeux vidéo. À l’ouverture, l’application affiche même un message encourageant les utilisateurs à partager le programme à leurs amis pour recevoir une copie complète gratuite.

L’archive se présentait avec des noms tels que Cheat.Lab.2.7.2.zip ou Cheater.Pro.1.6.0.zip. Or, les liens de téléchargement renvoyaient systématiquement vers une adresse du type « https://github[.]com/microsoft/vcpkg/files ». vcpkg ? Il s’agit d’un gestionnaire de bibliothèques C et C++ publié par Microsoft, open source et dont le code réside dans un dépôt GitHub.

Peu de solutions pour l’instant

C’est sur ce dépôt que les fichiers étaient hébergés, grâce au fonctionnement vu précédemment. Microsoft a fini par les supprimer, mais avec plusieurs semaines de délai. BleepingComputer, interloqué par le délai, s’est aperçu de la différence dans le stockage des fichiers : le malware n’appartenait pas au dépôt, mais à un stockage parallèle et rattaché. Il ne s’agissait donc pas de Microsoft distribuant des logiciels malveillants.

C’est l’un des problèmes soulignés par nos confrères : l’espace étant attenant et non intégré au dépôt, les personnes gérant ce dernier ne peuvent pas agir directement sur les fichiers téléversés dans les commentaires.

Pour l’instant, la seule solution est de fermer les commentaires, mais elle engendre deux problèmes. D’abord, cette fermeture ne peut être que temporaire, car GitHub permet de ne fermer les commentaires que pendant un maximum de six mois. Ensuite – et surtout – parce que les commentaires font pleinement partie de la vie d’un projet et permettent de collecter de nombreux retours et propositions.

BleepingComputer dit avoir trouvé un autre compte utilisé de cette manière, httprouter. Cependant, dans leurs discussions avec Sergei Frankoff, nos confrères ont appris l’existence d’une campagne similaire, avec un malware déguisé en Aimmy, une application de triche (aide à la visée). On y retrouvait le même logiciel malveillant en Lua, appelé SmartLoader.

Il y a deux jours, les fichiers associés n’étaient toujours pas supprimés.

Le même problème chez GitLab

La situation est à peu de choses près la même chez GitLab. La seule petite différence est que tous les fichiers sont stockés dans un dossier /uploads/, au sein d’un lien laissant penser qu’ils sont stockés dans le dépôt même. Et donc qu’il s’agit de fichiers tout à fait officiels, contrôlés par les autres membres du projet.

Pour l’instant, ni GitHub ni GitLab n’ont répondu aux sollicitations de BleepingComputer. Le sujet est cependant sérieux, car le système des commentaires, pensé comme outil de productivité, peut être détourné pour donner une légitimité apparente à des liens malveillants. La situation est d’autant plus problématique qu’il n’existe a priori pas de moyens simples de corriger le tir. Un changement dans la structure des liens rendrait ainsi tous ceux publiés inopérants et risquerait de couper l’accès à des millions de liens parfaitement légitimes.

Les risques sont importants. Nos confrères citent plusieurs exemples parlants. Un acteur malveillant pourrait ainsi se servir du dépôt de NVIDIA pour signaler une nouvelle version d’un pilote permettant de résoudre des problèmes dans des jeux. Sur le dépôt de Chromium, il pourrait mettre en avant une version de test du navigateur présentant des nouveautés attendues, des hausses de performances, etc.

L’information circulant depuis quelques jours, on peut tabler sur une baisse de la dangerosité. Mais cela vaut surtout pour les personnes arpentant les dépôts concernés. Pour les utilisateurs lambdas, il restera simple de présenter un lien vers GitHub ou GitLab comme officiel. Au moins jusqu’à ce qu’une solution officielle soit apportée.

Commentaires (18)


Ça veut dire qu'on peut héberger des films de vacances sur github ? :fumer:
A moins que ça n'ait changé depuis, il n'y a pas de limite de taille pour les assets d'une release sur GitHub. La seule limite est en nombre (1024 je crois de mémoire). Leur volume n'a pas de quota non plus, comme les repositories en eux-même.

Dans les faits, tu peux y stocker ce que tu veux en tgz.

SebGF

A moins que ça n'ait changé depuis, il n'y a pas de limite de taille pour les assets d'une release sur GitHub. La seule limite est en nombre (1024 je crois de mémoire). Leur volume n'a pas de quota non plus, comme les repositories en eux-même.

Dans les faits, tu peux y stocker ce que tu veux en tgz.
Je parlais par cette technique utilisant les commentaires.

fred42

Je parlais par cette technique utilisant les commentaires.
J'en doutais pas, c'était pour apporter une précision concernant d'autre possibilités :)

fred42

Je parlais par cette technique utilisant les commentaires.
Au pire:
cat mon_film.mkv | base64

:D
Quand est-ce qu'on pourra stocker des fichiers dans les commentaires de Next ?
En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les textes, images et vidéos (légitimes, et ultra courants dans les discussions) des autres binaires.
D'après l'article, hein.

Edit : ils pourraient aussi afficher un avertissement rappelant que le fichier prêt à télécharger ne provient pas de l'auteur du dépôt git. Bref...
Modifié le 23/04/2024 à 19h06

Historique des modifications :

Posté le 23/04/2024 à 18h57


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.

Posté le 23/04/2024 à 18h58


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.

Posté le 23/04/2024 à 18h59


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort.

Posté le 23/04/2024 à 19h00


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée.

Posté le 23/04/2024 à 19h02


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les images et vidéos (ultra courants dans les discussions) des autres binaires.

Posté le 23/04/2024 à 19h02


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les images et vidéos (légitimes, et ultra courants dans les discussions) des autres binaires.

Posté le 23/04/2024 à 19h03


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les textes, images et vidéos (légitimes, et ultra courants dans les discussions) des autres binaires.

Posté le 23/04/2024 à 19h04


En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les textes, images et vidéos (légitimes, et ultra courants dans les discussions) des autres binaires.
D'après l'article, hein.

Éloquent-Perroquet-performant

En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les textes, images et vidéos (légitimes, et ultra courants dans les discussions) des autres binaires.
D'après l'article, hein.

Edit : ils pourraient aussi afficher un avertissement rappelant que le fichier prêt à télécharger ne provient pas de l'auteur du dépôt git. Bref...
J'ai voulu mettre le suprised-pikachu pour la déconne, mais avec 860 lignes en base 64 je pense que ça aurait quelque peu froissé du monde.

Need le tag details !

Edit : pour la gloire

Edit 2 : lisez l'histo du commentaire :D

Edit : 5 : ah ben je le vois pas dedans :/
Modifié le 23/04/2024 à 20h15

Historique des modifications :

Posté le 23/04/2024 à 20h12


J'ai voulu mettre le suprised-pikachu pour la déconne, mais avec 860 lignes en base 64 je pense que ça aurait quelque peu froissé du monde.

Need le tag details !

Posté le 23/04/2024 à 20h13


J'ai voulu mettre le suprised-pikachu pour la déconne, mais avec 860 lignes en base 64 je pense que ça aurait quelque peu froissé du monde.

Need le tag details !

Edit : pour la gloire

Edit 2 : lisez l'histo du commentaire :D

Posté le 23/04/2024 à 20h14


J'ai voulu mettre le suprised-pikachu pour la déconne, mais avec 860 lignes en base 64 je pense que ça aurait quelque peu froissé du monde.

Need le tag details !

Edit : pour la gloire

Edit 2 : lisez l'histo du commentaire :D

Edit 5 : tiens, on peut pas voir son propre historique d'édition ?

Éloquent-Perroquet-performant

En base64 par exemple :-p On peut les stocker partout en fait. En texte, sous forme d'image sur les sites d'hébergement d'images, sous forme audio... A moins de limiter le nombre de messages/médias envoyés (et même là y'a des parades), c'est extrêmement difficile à contrer.
Mais bon, il n'y aura pas le soucis d'url, qui est le cœur du problème évoqué dans l'article.
Github et Gitlab peuvent facilement corriger ça pour les nouveaux commentaires. Pour l'existant, c'est un compromis à choisir entre sécurité et confort. Je suis triste de voir que la sécurité ne soit toujours pas privilégiée, d'autant qu'ils pourraient traiter différemment les textes, images et vidéos (légitimes, et ultra courants dans les discussions) des autres binaires.
D'après l'article, hein.

Edit : ils pourraient aussi afficher un avertissement rappelant que le fichier prêt à télécharger ne provient pas de l'auteur du dépôt git. Bref...
"Edit : ils pourraient aussi afficher un avertissement rappelant que le fichier prêt à télécharger ne provient pas de l'auteur du dépôt git"

Le problème n'est pas vraiment là. Pour différentes raisons, les serveurs github ne sont pas considérés comme particulièrement dangereux.

On a donc ici un stockage gratuit, disponible et peu filtrés pour des charges de travail pour les virus. Ce n'est pas qu'une news "développeur", mais virus en général - sauf que pour empêcher ce vecteur de propagation des charges de travail, il va falloir filtrer github, et là les dev vont soulever un sourcil et froncer l'autre...
Merci pour l'article. Je serai attentif à l'avenir sur les issues de mon repo. Par contre, le fait que même sans poster le commentaire on récupère un lien valide c'est chaud 😐

On a aucun moyen en tant que owner de repo d'avoir la liste de ce qui est upload ?
Le plus vicieux: des commentaires vaguement pertinents donc laissés en place (probablement générés par des LLMs ou des humains sous payés).

Et quelques mois plus tard, le commentaire est édité pour rajouter du spam, ce qui est très difficile à repérer avec les outils actuels.
Modifié le 23/04/2024 à 20h48

Historique des modifications :

Posté le 23/04/2024 à 20h47


Des exemples d'outils "modernes" pour flooder le Web de merde:

https://www.404media.co/ai-is-poisoning-reddit-to-promote-products-and-game-google-with-parasite-seo/

Ah bah voilà un hebergeur sympa qui offre un stockage gratuit et illimité !! y'a plus qu'a chiffrer en amont + un 'ptit rclone ça roule :)
(erreur : à supprimer, SVP)
Modifié le 24/04/2024 à 10h23

Historique des modifications :

Posté le 24/04/2024 à 10h22


Alors que l'héliosphère a été quittée en 2012 (environ 18 milliards de km du Soleil), Voyager 1 reste sous l'influence gravitationnelle du Soleil, et ne franchira le nuage de Oort qu'en 25 000 (à environ 1,3 années-lumière du Soleil) !

Je ne vois vraiment pas en quoi il serait compliqué de changer le chemin des fichiers pour avoir "/comments/files/" dedans, par exemple.
Il "suffit" de vérifier que les fichiers qui utilisent l'ancien chemin ont été uploadés avant la mise en place du nouveau chemin et on est bons...
On pourrait aussi se baser sur le referrer :
- si pas renseigné => téléchargement autorisé
- si renseigné et github => téléchargement autorisé
- si renseigné et pas github => téléchargement bloqué

Comme ce n'est pas un espace de stockage, il n'y a quasiment aucune raison valable d'avoir un accès direct au lien de téléchargement en dehors de github (ou gitlab)

On pourrait aussi limiter le téléchargement d'une pièce jointe au fait d'être logué sur la plateforme. Potentiellement, cela pourrait s'appliquer en fonction du type de fichier. Un fichier texte ne présente que très peu de risque comparé à un fichier .exe par exemple.

fdorin

On pourrait aussi se baser sur le referrer :
- si pas renseigné => téléchargement autorisé
- si renseigné et github => téléchargement autorisé
- si renseigné et pas github => téléchargement bloqué

Comme ce n'est pas un espace de stockage, il n'y a quasiment aucune raison valable d'avoir un accès direct au lien de téléchargement en dehors de github (ou gitlab)

On pourrait aussi limiter le téléchargement d'une pièce jointe au fait d'être logué sur la plateforme. Potentiellement, cela pourrait s'appliquer en fonction du type de fichier. Un fichier texte ne présente que très peu de risque comparé à un fichier .exe par exemple.
L'un n'empêche pas l'autre, en effet.
C'est pour ça que je m'étonne qu'il soit dit ici que le problème est complexe à résoudre : nous avons proposé des solutions à priori viables très rapidement, donc j'imagine que Github et Gitlab sont en mesure de faire au moins aussi bien et rapidement de surcroît.
La situation est d’autant plus problématique qu’il n’existe a priori pas de moyens simples de corriger le tir. Un changement dans la structure des liens rendrait ainsi tous ceux publiés inopérants et risquerait de couper l’accès à des millions de liens parfaitement légitimes.


C'est franchement trés simple : les nouveaux upload arrivent dans github.com/dangerous_external_upload/, avec le lien qui va avec dans le commentaire, et les anciens pré-existant conservent leur url actuelle.
Prb résolu, en quoi... 2h de dev ?
Fermer