Les données privées et le contenu supprimé sont accessibles en permanence, officiel GitHub : conçu intentionnellement

Récemment, une nouvelle a choqué la communauté open source : le contenu supprimé sur GitHub et les données dans des référentiels privés sont accessibles en permanence, et cela a été intentionnellement conçu par le responsable.

La société de logiciels de sécurité open source Truffle Security a détaillé le problème dans un article de blog.

Truffle Security introduit un nouveau terme : CFOR (Cross Fork Object Reference) : lorsqu'un fork de référentiel a accès à des données sensibles dans un autre fork (y compris les données de forks privés et supprimés). Une vulnérabilité CFOR existe.

Semblable aux références d'objet directes non sécurisées, dans CFOR, les utilisateurs peuvent accéder directement aux données de validation en fournissant la valeur de hachage de validation, sinon les données sont invisibles.

Ce qui suit est le contenu original du blog Truffle Security.

Accéder aux données d'un référentiel fork supprimé

Imaginez le workflow suivant :

• Fork un référentiel public sur GitHub

• Commettez le code dans votre référentiel fork ; .

Donc, le code que vous avez soumis au fork devrait être inaccessible, n'est-ce pas, car vous avez supprimé le référentiel du fork. Cependant, il est accessible en permanence et échappe à votre contrôle.

Comme le montre la vidéo ci-dessous, forkez un référentiel, soumettez-y des données, puis supprimez le référentiel fork, puis les données soumises « supprimées » sont accessibles via le référentiel d'origine.

Cette situation est courante. Truffle Security a enquêté sur 3 référentiels publics fréquemment fork d'une grande entreprise d'IA et a facilement trouvé 40 clés API valides à partir des référentiels fork supprimés.

Accès aux données d'un référentiel supprimé

Considérez le workflow suivant :

Vous disposez d'un référentiel public sur GitHub ;

• L'utilisateur forke votre référentiel ; données après qu'ils fork, et ils ne synchronisent jamais leur référentiel forké avec vos mises à jour ;

• Vous supprimez l'intégralité du référentiel.

• Ensuite, le code que vous avez soumis est toujours accessible une fois que l'utilisateur a fork votre référentiel.
  GitHub stocke les référentiels et les référentiels forkés dans un réseau de référentiels, le référentiel "en amont" d'origine agissant comme nœud racine. Lorsqu'un référentiel forké public « en amont » est « supprimé », GitHub réattribue le rôle root à l'un des référentiels forkés en aval. Cependant, tous les commits du référentiel « en amont » existent toujours et sont accessibles via n'importe quel référentiel forké.

Cette situation n'est pas unique, quelque chose comme ceci s'est produit la semaine dernière :

Truffle Security a soumis une vulnérabilité P1 à une grande entreprise technologique, montrant qu'elle a accidentellement soumis un employé à GitHub La clé d'un compte avec accès critique à l’ensemble de l’organisation GitHub. L'entreprise a immédiatement supprimé le référentiel, mais comme celui-ci avait été dupliqué, les commits contenant des données sensibles étaient toujours accessibles via le référentiel forké, même si le référentiel forké n'a jamais été synchronisé avec le référentiel « en amont » d'origine. Autrement dit, tout code validé dans un référentiel public est accessible en permanence tant que le référentiel possède au moins un référentiel fork.

Accéder aux données du référentiel privé

Considérez le flux de travail suivant :

Vous créez un référentiel privé qui sera éventuellement rendu public

Créez une version privée de ce référentiel (via fork) et validez du code supplémentaire ; pour les fonctionnalités qui ne sont pas destinées à être publiques ;

• Vous rendez votre référentiel "en amont" public et gardez votre référentiel fork privé.

Ensuite, les fonctionnalités privées et le code associé sont disponibles pour un visionnage public. Tout code validé entre le fork interne du référentiel dans lequel vous avez créé l'outil et l'open source de l'outil sera accessible via le référentiel public.

Après avoir rendu public votre référentiel "en amont", les validations effectuées dans votre référentiel fork privé ne seront pas visibles. En effet, la modification de la visibilité d'un référentiel privé « en amont » entraîne la création de deux réseaux de référentiels : un pour la version privée et un pour la version publique.



Malheureusement, ce flux de travail est l'une des méthodes les plus couramment utilisées par les utilisateurs et les institutions lors du développement de logiciels open source. En conséquence, des données confidentielles peuvent être exposées par inadvertance sur les référentiels publics GitHub.

Comment accéder aux données ?

Les opérations destructives dans le réseau de référentiels GitHub (comme les 3 scénarios ci-dessus) suppriment les références pour valider les données de l'interface utilisateur GitHub standard et des opérations git normales. Cependant, les données existent toujours et sont accessibles (hachage de validation). C’est le lien entre les vulnérabilités CFOR et IDOR.



Les hachages de validation peuvent être forcés brutalement via l'interface utilisateur de GitHub, d'autant plus que le protocole git permet l'utilisation de valeurs SHA-1 courtes lors du référencement de validations. Une valeur SHA-1 courte est le nombre minimum de caractères requis pour éviter une collision avec un autre hachage de validation, avec un minimum absolu de 4. L'espace clé pour toutes les valeurs SHA-1 à 4 caractères est 65536 (16^4). Le forçage brutal de toutes les valeurs possibles peut être obtenu relativement facilement.





Fait intéressant, GitHub expose un point de terminaison d'API d'événements publics. Vous pouvez également interroger les hachages de validation dans une archive d'événements gérée par un tiers et conserver tous les événements GitHub des dix dernières années en dehors de GitHub, même après la suppression du référentiel.

Dispositions GitHub

Truffle Security a soumis ses conclusions aux responsables de GitHub via le programme VDP de GitHub. GitHub a répondu : « Ceci est prévu par la conception » et la documentation jointe.







Documentation : https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks -quand-un-dépôt-est-supprimé-ou-change-de-visibilité

Truffle Security félicite GitHub pour sa transparence sur son architecture, mais Truffle Security estime que : les utilisateurs ordinaires considèrent la séparation des référentiels privés et publics comme une frontière de sécurité, et Les utilisateurs publics sont considérés comme incapables d'accéder aux données des référentiels privés. Malheureusement, comme mentionné ci-dessus, ce n’est pas toujours le cas.

Truffle Security a conclu que tant qu'un référentiel fork existe, toutes les validations sur ce réseau de référentiels (c'est-à-dire les validations sur le référentiel "en amont" ou le référentiel fork "en aval") persisteront pour toujours.

Truffle Security souligne également que le seul moyen de réparer en toute sécurité les clés compromises sur les référentiels publics GitHub est la rotation des clés.

L'architecture du référentiel de GitHub souffre de ces défauts de conception. Malheureusement, la grande majorité des utilisateurs de GitHub ne comprendront jamais comment fonctionne réellement la mise en réseau des référentiels et compromettront ainsi la sécurité.

^{Lien original : https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github}

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!