Crédits : Unsplash 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
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (18)
#1
#1.1
Dans les faits, tu peux y stocker ce que tu veux en tgz.
#1.2
#1.3
#1.4
cat mon_film.mkv | base64
#2
#2.1
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...
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.
#2.2
Need le tag details !
Edit : pour la gloire
Edit 2 : lisez l'histo du commentaire
Edit : 5 : ah ben je le vois pas dedans :/
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
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
Edit 5 : tiens, on peut pas voir son propre historique d'édition ?
#2.3
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...
#3
On a aucun moyen en tant que owner de repo d'avoir la liste de ce qui est upload ?
#4
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.
#4.1
https://www.404media.co/ai-is-poisoning-reddit-to-promote-products-and-game-google-with-parasite-seo/
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/
#5
#6
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) !
#7
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...
#7.1
- 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.
#7.2
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.
#8
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 ?