Une vulnérabilité GitHub permet la fuite de rapports de sécurité sensibles

Une vulnérabilité récemment découverte sur GitHub pourrait exposer les rapports de sécurité, donnant aux attaquants la possibilité d’exploiter les failles du code avant que les utilisateurs n’aient le temps d’appliquer les correctifs.

Justin Cappos, professeur au département d’informatique et d’ingénierie de l’université de New York, a découvert la vulnérabilité en appliquant un correctif dans le référentiel d’un autre compte. Il explique avoir remarqué que ses rapports de sécurité avaient été divulgués au propriétaire du compte… Justin Cappos a découvert la vulnérabilité le 13 mars et l’a signalée à GitHub le 20 mars par l’intermédiaire de son programme de primes aux bugs avec HackerOne, mais aucune CVE n’a depuis été attribuée.

Justin Cappos nous a déclaré que le vecteur d’attaque implique des dépôts .github qui contiennent des fichiers security.md dans lesquels les utilisateurs stockent des instructions sur la manière de signaler une vulnérabilité découverte dans leurs dépôts. Les fichiers security.md sont donc censés être publics. La vulnérabilité est déclenchée lorsqu’un utilisateur tente de mettre en œuvre un correctif pour un problème qu’il a découvert dans un autre dépôt.

L’accès au fichier Security.md pourrait exposer les faiblesses de sécurité dans le dépôt .github d’un autre utilisateur, précise Justin Cappos, mais les acteurs de la menace doivent cependant toujours exploiter les problèmes ensuite pour lancer des attaques. Le risque est donc réel en seconde intention.

« Ce qui se passe, c’est que le fichier security.md donne un lien vers l’endroit où les vulnérabilités sont signalées, de sorte que les vulnérabilités signalées pour mon logiciel seraient transmises à l’attaquant », a-t-il déclaré. « Une personne compétente pourrait ainsi se rendre compte que tous ceux qui utilisent mon logiciel de signalement courent le risque d’informer plus de monde à cause d’un bug. Lorsqu’ils me font part d’un problème, cette information est transmise au pirate. Ce dernier peut alors compromettre tous mes utilisateurs s’il sait rapidement exploiter le problème signalé ».

Dans les faits, lorsque les utilisateurs de GitHub découvrent une erreur, il leur est demandé de forker le dépôt qui contient le problème et ce dépôt est alors étiqueté .github. Ensuite, ils envoient une demande d’extraction au nouveau dépôt .github pour informer l’utilisateur de la correction. Si le dépôt .github forké contient des fichiers security.md, tous les projets de l’utilisateur qui n’ont pas de dépôt .github verront leurs rapports de vulnérabilité de sécurité envoyés au notificateur.

La vulnérabilité peut être déclenchée, que les utilisateurs fusionnent la demande d’extraction ou non, avertit Justin Cappos. Il a exhorté GitHub à rendre l’attaque plus difficile à lancer.

« Quand on fork le .github de quelqu’un d’autre, tout ce qu’il a dit de faire pour les rapports de sécurité finit par s’appliquer automatiquement à tous vos dépôts. Il n’y a pas d’avertissement à ce sujet. Il n’y a pas de notification », alerte Justin Cappos. « En gros, vous, en tant qu’utilisateur qui essayez juste de faire une bonne chose, comme corriger une coquille ou un bogue, vous vous retrouvez tout d’un coup à transmettre tous vos rapports de sécurité à un tiers, y compris s’il est mal intentionné. »

Justin Cappos soulève de nombreux points sensibles liés à cette vulnérabilité. Les fichiers security.md des dépôts .github peuvent contenir un ensemble d’informations sensibles. Lorsqu’un utilisateur prend en charge le dépôt d’un autre utilisateur pour y apporter des modifications, le fichier security.md est appliqué à tous les dépôts .github de ce dernier. Par la suite, un utilisateur de GitHub ne peut pas modifier le fichier après le fork ; le fork contient tout le contenu des fichiers à ce moment-là.

Autre problème : la faille peut affecter des référentiels extrêmement sécurisés d’une manière inattendue pour les utilisateurs. Justin Cappos souligne cependant que les attaques n’affecteraient que les utilisateurs légitimes cherchant à corriger les erreurs commises dans le code ou les projets partagés sur GitHub.

Justin Cappos explique qu’il n’a vu aucune preuve que de telles attaques se sont produites jusqu’à présent. Mais il a analysé les dépôts GitHub et a découvert que des milliers d’utilisateurs avaient accidentellement divulgué leurs fichiers security.md. Il note que les informations de sécurité de certains projets populaires ont été modifiées sans savoir si ces modifications sont intentionnelles, accidentelles ou malveillantes. Il ajoute que la plupart des dépôts concernés ne sont pas considérés comme critiques.

Selon Justin Cappos, la faille est facile à exploiter, mais le ciblage présente des difficultés. Les acteurs de la menace pourraient cependant attirer les utilisateurs en incluant intentionnellement des erreurs dans leur code, mais il n’y a aucune garantie qu’ils répondront.

Au cours du processus de divulgation de la vulnérabilité avec HackerOne le 20 mars, Justin Cappos s’est vu confirmer qu’ils avaient de la documentation sur le problème. GitHub prend la faille au sérieux, mais en même temps ne semble pas certaine qu’il s’agit d’une véritable vulnérabilité nécessitant un correctif.

« Je suis un peu d’accord avec l’évaluation de GitHub qui estime que ce n’est pas extrêmement grave. Bien que leur outil de suivi des problèmes l’ait classé comme critique (la catégorie la plus élevée) – principalement parce que vous avez accès à des informations très sensibles et que cela a un impact sur un large éventail de dépôts –, le fait que quelqu’un doive être un bon samaritain en premier lieu et forker votre dépôt pour envoyer une demande d’extraction rend l’attaque plus difficile à cibler sur une partie spécifique », admet Justin Cappos. « Cependant, pour un attaquant qui souhaite simplement compromettre des projets en général, il s’agit d’une préoccupation sérieuse ».

À ce jour, aucune CVE ni correctif n’a été attribué à cette vulnérabilité et Justin Cappos invite les utilisateurs à se protéger en créant un dépôt .github vide.

« Si vous avez créé votre propre dépôt .github, cela ne vous affectera pas, car vous ne pourrez pas écraser le vôtre lorsque vous forkez celui de quelqu’un d’autre. Mais si vous n’en avez pas créé, ce qui n’est pas le cas de la plupart des utilisateurs parce qu’ils ne sont pas très populaires, alors vous êtes vulnérable », explique-t-il.

Contacté par la rédaction de TechTarget (maison mère du MagIT), GitHub s’engage à enquêter sur les problèmes de sécurité signalés et explique « nous avons pris connaissance de ce rapport soumis dans le cadre du programme GitHub bug bounty et l’avons validé comme présentant un faible risque de sécurité et une faible probabilité d’exploitation. Nous continuons à investir dans l’amélioration de la sécurité de GitHub et de nos produits et nous étudions les possibilités de rendre ce comportement plus clair lors de l’édition des fichiers de politique de sécurité. »

Reste que les récentes attaques contre les utilisateurs de GitHub ont mis en évidence la popularité de la plateforme de développement pour les acteurs de la menace, ainsi que les risques pour la chaîne d’approvisionnement en logiciels libres. Au début du mois, Checkmarx a découvert que des attaquants manipulaient les actions GitHub et la fonction d’observation des étoiles pour inciter les développeurs à télécharger un code malveillant. Checkmarx a révélé une autre campagne d’attaque en mars où les attaquants ont empoisonné plusieurs dépôts de code GitHub populaires, y compris Top.gg, qui est utilisé pour la recherche et la découverte sur la plateforme Discord.