Abus de l’infrastructure Go

Problème

• La nuit dernière, en explorant le contenu de la base de données de sommes de contrôle de Go, un résultat intéressant est apparu.
• Après avoir exécuté la commande sqlite> select path, count(path) from modules group by path order by count(path) desc; :
  • github.com/homebrew/homebrew-core|39438
  • github.com/Homebrew/homebrew-core|30896
  • github.com/concourse/concourse|25372
  • github.com/openshift/release|24065
  • github.com/cilium/cilium|22138
• Homebrew est connu pour utiliser Ruby, ce qui rendait son lien avec Go intrigant.
• Les statistiques de langage de GitHub le confirmaient également.
• Le dépôt a été cloné pour chercher des fichiers liés à Go (go.mod ou fichiers source Go), mais rien n’a été trouvé.

Recherche

• Un nouveau jour a commencé, et la curiosité exigeait une réponse.
• Si le dépôt Git n’a aucun lien avec du code Go, la question était de savoir comment il apparaissait dans la base de données de sommes de contrôle de Go.
• Il a été constaté que proxy.golang.org est le proxy de modules par défaut et que sum.golang.org est la base de données de sommes de contrôle.
• En lisant la documentation de Go, il est apparu que si une version de module n’est pas encore enregistrée dans le journal, la base de données de sommes de contrôle tente de récupérer le module depuis le serveur d’origine.
• Pour vérifier si un nouveau dépôt de module Go est ajouté à la base de données de sommes de contrôle et au proxy, l’endpoint lookup a été appelé.
• Après avoir créé un nouveau module Go et l’avoir téléversé sur un compte GitHub, la commande lookup a été essayée sous deux formes, mais les deux ont renvoyé une erreur.
• Une pseudo-version correcte a ensuite été générée, puis la base de données de sommes de contrôle a de nouveau été interrogée pour vérifier si le module avait été téléchargé.
• Le proxy a été interrogé et le module zip téléchargé, ce qui a permis de démontrer qu’il est possible de stocker des données arbitraires dans l’infrastructure Go.

Possibilités d’abus

• Cela pourrait être utilisé pour contourner les restrictions de téléchargement sur des machines de développeurs et des serveurs CI/CD.
• Un logiciel malveillant pourrait y stocker sa charge utile et la récupérer depuis le proxy au moment voulu.
• Une attaque par déni de service (DoS) contre proxy.golang.org pourrait être possible.
• Un système de commande et contrôle (C2) pourrait être mis en œuvre facilement.

Conclusion

• Cela a permis de comprendre le fonctionnement du processus de la base de données de sommes de contrôle.
• Pour l’instant, il ne s’agit pas d’un problème grave dans l’infrastructure Go, mais le potentiel d’abus existe.
• D’autres questions subsistent sur la raison de la présence de projets non-Go dans la base de données.
• Cette recherche a apporté de nombreuses idées, et il est prévu d’explorer davantage.

Avis de GN⁺

1. Vulnérabilité de sécurité : cet article souligne une faiblesse de sécurité dans la base de données de sommes de contrôle de Go, qui peut stocker des données arbitraires. Cela pourrait offrir une voie de distribution facilitée pour du code malveillant.
2. Nécessité d’améliorations : il est nécessaire d’améliorer le contrôle d’accès à la base de données de sommes de contrôle et aux serveurs proxy afin de renforcer la sécurité et l’intégrité de l’infrastructure Go.
3. Intégration avec d’autres langages : il faut clarifier pourquoi des projets non-Go sont inclus dans la base de données de sommes de contrôle de Go et mettre en place des procédures de validation supplémentaires pour l’empêcher.
4. Formation des développeurs : il est nécessaire de former les développeurs afin qu’ils prennent conscience de ces failles de sécurité et comprennent les meilleures pratiques pour les éviter.
5. Solutions alternatives : il serait utile de comparer avec les bases de données de sommes de contrôle et les serveurs proxy d’autres langages offrant des fonctionnalités similaires, afin d’en tirer des pistes d’amélioration pour l’infrastructure de Go.

[GN⁺]

Avis Hacker News

Résumé des commentaires de Hacker News

• Possibilités d’abus des services en ligne

  • Tous les services en ligne peuvent au final être détournés à des fins de commande et contrôle, de violation du droit d’auteur ou d’hébergement de CSAM. Twitter, Telegram, l’infrastructure de clés PGP, etc. ont déjà connu ce type de cas.

• Le problème de l’hébergement de fichiers chez Google

  • Google traite souvent des problèmes d’hébergement de fichiers malveillants, donc il est possible que l’équipe Go ait collaboré avec GCP et Drive. Cela ne diffère pas énormément d’autres endpoints déjà autorisés par Google.

• Comparaison avec GitHub

  • Certains estiment qu’il n’y a pas de grande différence avec le fait de téléverser des fichiers sur GitHub. GitHub aussi permet de stocker des données arbitraires dès lors qu’on a un compte.

• Les projets non Python sur PyPI

  • PyPI héberge aussi des projets non Python, et il faut une fonction permettant de distribuer des wheels (binaires compilés) lorsque les utilisateurs ne peuvent pas compiler le code d’une bibliothèque. Cela peut aussi concerner du code écrit en C et en Golang.

• Le proxy Golang et le journal des checksums

  • Quelqu’un dit avoir déjà essayé l’idée d’enregistrer de manière transparente les checksums d’URL arbitraires à l’aide du proxy Golang et de sumdb.

• Exploration de domaine

  • En explorant un domaine précis, la plupart des contenus attendus s’y trouvaient.

• Problème connu

  • Un lien vers un problème connu de Golang est partagé.

• Le système de modules de CUE

  • Le système de modules de CUE est en cours de lancement ; son MVS de Go est apprécié, mais il est construit sur une infrastructure OCI. Les personnes intéressées par les systèmes de gestion des dépendances peuvent consulter les liens associés.

• Le problème du cache Web

  • Le W3C a rendu tout le Web théoriquement cacheable, mais on peut se demander pourquoi les caches proxy à usage général sont presque inexistants. Est-ce parce que les éditeurs envoient inutilement des réponses avec un Cache-Control: max-age trop court ou Vary: Cookie, ou parce que trop de FAI paient des coûts de transit ?

• Le problème du cache proxy

  • Mettre en cache des dépôts non Go via un proxy peut être du gaspillage, mais faire en sorte qu’il mette en cache des dépôts Go permet aussi de stocker des données arbitraires. Cela ne semble pas être un gros problème.