Je viens de reconstruire l’un de mes forums Discourse et lorsque je le charge dans le navigateur, le message suivant s’affiche dans une fenêtre contextuelle :
Vous avez été piraté par un plugin ! par w3shi(Hackerone)-S.Lakshmi Vignesh(RCE-POC)
Sainte… Que se passe-t-il ? L’un des plugins que j’utilise a été compromis ?
Oui, il est dans la liste. Et le seul de discoursehosting.
Je me souviens qu’il doit être actif pour permettre aux anciens utilisateurs de se connecter, n’est-ce pas ?
Mais la question est maintenant de savoir si l’installation a été compromise ou si elle affiche simplement ce message. Le site est actuellement hors service par mesure de sécurité.
Avec ce plugin, voici la liste de ce que j’utilise :
Traduction par Google Translate du post du forum français :
\u003e Un pseudo-chercheur en sécurité a récupéré un ancien dépôt Git d’un plugin utilisé par le forum et l’a détourné pour simplement afficher ce message.
\u003e
\u003e Le dépôt en question (GitHub - discoursehosting/discourse-migratepassword: A touch of security) a été inspecté et aucun code malveillant n’est présent (c’est simplement une preuve de concept).
\u003e
\u003e Ce dépôt avait en fait changé d’URL (il est maintenant disponible sur GitHub - communiteq/discourse-migratepassword: Support migrated password hashes) et l’utilisateur a simplement recréé le dépôt discoursehosting/discourse-migratepassword, qui redirigeait auparavant vers communiteq/discourse-migratepassword, pour y placer du code sans rapport. Nous utilisions l’ancienne URL, c’est pourquoi nous avons été affectés.
Si c’est vrai, d’accord… J’ai changé l’URL du plugin pour communiteq et je suis en train de reconstruire. Mais je dois examiner cela de plus près (comme je ne suis pas programmeur, je ne peux pas être sûr à 100%).
Il s’agit d’une vulnérabilité Github dans une classe d’exploit appelée « Repojacking ».
Nous recommandons à tout le monde de vérifier les URL de leurs plugins Github et de renommer chaque instance de discoursehosting en communiteq.
Contexte :
Nous avons dû renommer notre entreprise de Discoursehosting à Communiteq en 2019.
Si cela se produit, Github redirige automatiquement les URL vers les dépôts Github vers leur nouvel emplacement, jusqu’à ce que quelqu’un crée un dépôt du même nom. À ce moment-là, le nouveau dépôt prendra la préférence.
Github marquait auparavant de tels dépôts comme « retirés » et interdisait la création d’un dépôt du même nom.
Un exploit précédent est décrit ici. Apparemment, cette correction n’est plus efficace.
Nous avons déposé un rapport d’abus auprès de Github et tenterons de faire supprimer ce dépôt par tous les moyens disponibles.
Pour le moment, le plugin compromis affiche seulement un message et laisse un fichier inoffensif dans /tmp.
Donc rien de grave ne s’est produit - pour l’instant. Il est important de changer l’URL de votre plugin avant de reconstruire.
Pour atténuer l’impact potentiel sur les utilisateurs de l’installation standard, nous avons ajouté du code pour détecter github.com/discoursehosting/ et annuler toute reconstruction/mise à niveau.
---
ERREUR : Le fichier de configuration containers/app.yml contient des références à une organisation GitHub compromise : github.com/discoursehosting
Veuillez supprimer toute référence à cette organisation de votre fichier de configuration.
Pour plus d'informations, voir https://meta.discourse.org/t/374703/6
---
Je tiens à m’excuser sincèrement pour la perturbation causée par mes actions concernant le dépôt de plugins. En tentant de mettre en évidence un problème de sécurité, j’ai commis de graves erreurs qui ont enfreint le code de conduite.
À l’avenir, je veillerai à ce que mes actions respectent les pratiques de divulgation responsable et j’apprécie l’opportunité d’en tirer des leçons.
Encore une fois, je suis vraiment désolé pour la perturbation causée.
La chose suivante, pas très responsable, a été de ne pas me contacter ou CDCK en privé lorsque vous avez abandonné le handle, car au cours des trois dernières heures, quelqu’un d’autre aurait pu voir votre publication et l’enregistrer.
Vous devriez essentiellement supposer que rien n’est sûr, ce qui ne fonctionne pas bien non plus.
Il y a quelques jours à peine, on a appris que l’un des développeurs derrière le compte NPM de certains packages ESLint Prettier avait été compromis et avait publié de nouvelles versions compromises de certains packages populaires :
Ces packages ont ensuite été référencés dans d’autres packages, car beaucoup prétendent qu’il faut toujours mettre à jour vers les dernières versions.
Après avoir vu ce fil, j’ai suggéré une fonctionnalité pour introduire la validation de signature des plugins/composants de thème lors de leur mise à jour : Plugin and theme component signing
Cela n’arrêterait pas une clé compromise, mais rendrait au moins une partie de la chaîne d’approvisionnement plus digne de confiance. En fin de compte, il est toujours possible que des bibliothèques tierces compromises soient incluses. Les dépendances supplémentaires ne sont pas vraiment visibles.
Je ne suis pas sûr que cela fonctionne toujours. J’avais un plugin pointant vers l’URL GitHub compromise et le message d’erreur lors de la reconstruction a simplement indiqué qu’il n’avait pas réussi à extraire le dépôt, avec des détails supplémentaires sur une version de gem ou quelque chose de similaire. (Je ne peux pas coller les informations exactes car elles sont trop loin dans mon historique de défilement par rapport à tout le reste pendant les constructions ultérieures.)
Il semble que l’URL/dépôt n’existe plus du tout, ce qui est une bonne chose (du moins jusqu’à ce que quelqu’un d’autre le recrée), mais le message d’erreur aurait fait gagner beaucoup de temps.