Sur GitHub, il est possible daccder aux donnes de dpts supprims, de forks supprims et mme de dpts privs. Cette vulnrabilit, connue sous le nom de Cross Fork Object Reference (CFOR), est intentionnellement conue par GitHub et reprsente un vecteur dattaque majeur pour les organisations utilisant cette plateforme.
Les chercheurs de Truffle Security ont dcouvert, ou plutt redcouvert, que les donnes des dpts GitHub supprims (publics ou privs) et des copies supprimes (forks) des dpts ne sont pas ncessairement supprimes.
Joe Leon, un chercheur en scurit de l’organisation, a dclar dans un avis publi mercredi que la possibilit d’accder aux donnes supprimes d’un dpt – telles que les cls d’API – reprsente un risque pour la scurit. Il a propos un nouveau terme pour dcrire cette vulnrabilit prsume : Cross Fork Object Reference (CFOR).
Leon explique : Une vulnrabilit CFOR se produit lorsqu’une fork du rfrentiel peut accder des donnes sensibles d’un autre fork (y compris des donnes de fork prives et supprimes). Comme dans le cas d’une rfrence directe un objet (Insecure Direct Object Reference), dans le cas d’une vulnrabilit CFOR, les utilisateurs fournissent des hachages de livraisons pour accder directement des donnes de livraisons qui, autrement, ne leur seraient pas visibles .
Accs aux donnes de forks supprims
Imaginons que vous ayez fork un dpt public, y ayez ajout du code, puis supprim votre fork. Logiquement, ce code ne devrait plus tre accessible. Pourtant, il lest, et ce de manire permanente.
Dans la vido ci-dessous, vous verrez Truffle Security forker un dpt, y livrer des donnes, supprimer le fork, puis accder aux donnes supprimes via le dpt d’origine.
Vous pourriez penser que vous tes protg en ayant besoin de connatre le hash du commit. Ce n’est pas le cas. Le hash peut tre dcouvert. Nous y reviendrons plus tard.
quelle frquence peut-on trouver des donnes provenant de forks supprimes ?
Assez souvent. Truffle Security indique avoir tudi quelques (littralement 3) dpts publics couramment forks d’une grande entreprise d’IA et avoir facilement trouv 40 cls d’API valides provenant de forks supprims. Le schma de l’utilisateur semble tre le suivant :
- Forcer le dpt.
- Coder en dur une cl API dans un fichier d’exemple.
- <Faire le travail>
- Supprimer le fork.
Mais le pire, c’est que cela fonctionne aussi en sens inverse :
Accs des donnes repo supprimes
Considrons le scnario suivant :
- Vous avez un dpt public sur GitHub.
- Un utilisateur fork votre repo.
- Vous livrez des donnes aprs qu’il l’ait fork (et il ne synchronise jamais son fork avec vos mises jour).
- Vous supprimez l’ensemble du repo.
Le code que vous avez livr aprs qu’ils aient fork votre repo est-il toujours accessible ?
Oui.
GitHub stocke les dpts et les forks dans un rseau de dpts, le dpt original en amont jouant le rle de nud racine. Lorsqu’un dpt public en amont ayant fait l’objet d’un fork est supprim , GitHub rattribue le rle de nud racine l’un des forks en aval. Cependant, tous les commits du dpt en amont existent toujours et sont accessibles via n’importe quel fork.
Dans la vido ci-dessous, Truffle Security a cr un repo, l’a fork et a montr ensuite comment les donnes qui ne sont pas synchronises avec le fork peuvent encore tre accdes par le fork aprs la suppression du repo original.
Il ne s’agit pas d’un scnario bizarre. Il s’est droul la semaine dernire :
J’ai soumis une vulnrabilit P1 une grande entreprise technologique qui a accidentellement livr une cl prive pour le compte GitHub d’un employ qui avait un accs important l’ensemble de leur organisation GitHub. Ils ont immdiatement supprim le dpt, mais comme il avait t fork, je pouvais toujours accder au commit contenant les donnes sensibles via un fork, bien que le fork n’ait jamais t synchronis avec le dpt original « en amont » .
L’implication ici est que tout code engag dans un dpt public peut tre accessible pour toujours tant qu’il existe au moins un fork de ce dpt.
Et ce n’est pas tout.
Accs aux donnes de repo prives
Considrez ce flux de travail commun pour l’open-sourcing d’un nouvel outil sur GitHub :
- Vous crez un repo priv qui sera ventuellement rendu public.
- Vous crez une version interne prive de ce dpt (via un fork) et vous livrez du code supplmentaire pour les fonctionnalits que vous n’allez pas rendre publiques.
- Vous rendez public votre dpt en amont et gardez votre fork priv.
Vos fonctionnalits prives et le code correspondant (de l’tape 2) sont-ils visibles par le public ?
Oui. Tout code modifi entre le moment o vous avez cr une version interne de votre outil et le moment o vous avez ouvert l’outil la concurrence est accessible sur le dpt public.
Les modifications apportes votre fork priv aprs que vous ayez rendu public le dpt amont ne sont pas visibles. En effet, la modification de la visibilit d’un dpt priv en amont entrane la cration de deux rseaux de dpts – un pour la version prive et un pour la version publique.
Dans la vido ci-dessous, Truffle Security montre comment les organisations mettent de nouveaux outils en open source tout en conservant des forks internes prives, puis comment quelqu’un peut accder aux donnes de validation de la version interne prive par le biais de la version publique.
Malheureusement, ce flux de travail est l’une des approches les plus courantes que les utilisateurs et les organisations adoptent pour dvelopper des logiciels libres. Par consquent, il est possible que des donnes confidentielles et des secrets soient exposs par inadvertance sur les dpts publics GitHub d’une organisation.
Vous pouvez forker
Il s’agit clairement d’un problme. Mais ce n’est pas un problme au point que GitHub considre CFOR comme une vulnrabilit lgitime. En fait, le gant de l’hbergement de code, proprit de Microsoft, considre qu’il s’agit d’une fonctionnalit et non d’un bogue. Inform de la situation par le biais de son programme de divulgation des vulnrabilits, GitHub a rpondu : Il s’agit d’une dcision de conception intentionnelle et elle fonctionne comme prvu, comme indiqu dans notre [documentation].
Il est vident que cela est connu depuis des annes. Une personne affirme avoir notifi GitHub de la vulnrabilit en 2018 et avoir reu une rponse similaire.
Lors d’un entretien, Dylan Ayrey, cofondateur et PDG de Truffle Security, a expliqu que le problme se rsumait ce que l’on appelle un dangling commit.
Un dangling commit est une primitive git, explique Ayrey. Ce n’est pas une primitive GitHub. Un dangling commit peut donc exister sur n’importe quelle plateforme git – Bitbucket, GitLab, GitHub, etc. Un dangling commit, c’est en fait, dans un dpt de code donn, un arbre qui reprsente l’historique du projet, c’est–dire toutes les anciennes versions du code qui sont relies entre elles .
Un commit git capture un instantan de l’tat d’un dpt un moment prcis, y compris les modifications apportes au code et aux donnes. Chaque commit est identifi de manire unique par un hachage cryptographique. Si la suppression d’une branche, par exemple, supprime la rfrence une chane de livraisons particulire, les livraisons elles-mmes ne sont pas supprimes de la base de donnes d’objets du rfrentiel.
Ces « dangling commits » sont comme une partie fondamentale documente de git lui-mme , a dclar Ayrey, qui a expliqu que la faon dont les plateformes git traitent les dangling commits est une dcision de la plateforme plutt qu’une spcification de git.
Bitbucket, GitLab et GitHub, a dclar Ayrey, ont ces commits mme lorsque la connexion l’arbre du code est rompue. Si vous avez l’identifiant pour y accder directement, vous pouvez toujours tlcharger les donnes associes.
Un problme largement connu
Selon Ayrey, ce problme est largement connu. Mais il existe un autre problme, li aux forks (dpts copis), qui est plus spcifique GitHub. Les forks, a-t-il expliqu, ne font pas partie des spcifications de Git, de sorte que chaque plateforme a sa propre implmentation. Ayrey a dclar que pour GitHub, les commits en suspens peuvent tre tlchargs via un fork si vous avez le hash d’identification, ou une partie de celui-ci.
Si vous avez l’identifiant, vous pouvez les tlcharger partir du dpt dans lequel ils ont t pousss l’origine , a-t-il expliqu. Il s’avre que vous pouvez galement les tlcharger partir de n’importe quel fork de ce dpt. Et cela fonctionne dans les deux sens. Ainsi, depuis le parent, vous pouvez tlcharger ce commit dangling depuis le fork et depuis le fork, vous pouvez tlcharger ce commit dangling depuis le parent .
Ce que nous avons dcouvert, c’est que mme si vous supprimez le parent, et que le commit a t envoy (push) vers le parent, ce dangling commit non seulement vit toujours, mais vous pouvez le tlcharger travers l’enfant, mme s’il a t envoy vers le parent, qu’il n’a jamais t tir (pull) dans l’enfant, et que le parent a t supprim, vous pouvez maintenant accder ce dangling commit.
De plus, explique Ayrey, vous n’avez mme pas besoin du hachage complet de l’identifiant pour accder au commit. Si vous connaissez les quatre premiers caractres de l’identifiant, GitHub compltera presque automatiquement le reste de l’identifiant pour vous , a-t-il dclar, notant qu’avec seulement soixante-cinq mille combinaisons possibles pour ces caractres, il s’agit d’un nombre suffisamment restreint pour tester toutes les possibilits.
Quels risques cela reprsente ?
Interrog sur les risques que cela prsente, Ayrey a indiqu qu’il existe des archives d’vnements GitHub qui enregistrent toutes les actions publiques de GitHub. De mme que les archives de tweets de la Sunlight Foundation peuvent tre utilises pour tudier les dclarations publiques sur les mdias sociaux, les archives d’vnements de GitHub peuvent tre utilises pour des enqutes judiciaires sur les activits des entreprises technologiques.
Si [les entreprises technologiques] suppriment du code, si elles s’efforcent de supprimer quelque chose, cela ne veut pas toujours dire quelque chose , a-t-il expliqu. Mais souvent, cela signifie quelque chose. Cela peut signifier qu’une cl ou un mot de passe [a t expos]. Cela peut signifier qu’ils ont accidentellement mis en ligne un ensemble de donnes d’apprentissage automatique. Nous avons dj vu cela. Ou cela peut signifier – et c’est rare – [que] l’attaquant a en fait backdooris son projet et qu’il en tait un peu gn… alors il a simplement supprim la porte drobe.
la question de savoir comment GitHub devrait ragir, Ayrey a rpondu : Si une plateforme cre une vulnrabilit, la documente et explique qu’il s’agit de quelque chose dont vous devriez tre conscient et qui constitue un risque connu, est-ce que cela en fait moins une vulnrabilit ?
Sources : Truffle Security, GitHub (1, 2)
Et vous ?
Quelle est votre opinion sur la conception de GitHub concernant laccs aux donnes de dpts supprims et privs ? Certains considrent cela comme une fonctionnalit utile, tandis que dautres le voient comme un risque potentiel pour la scurit des donnes.
Comment grez-vous la scurit de vos dpts GitHub ? Partagez vos meilleures pratiques pour protger vos informations sensibles et vos secrets dentreprise.
Pensez-vous que GitHub devrait modifier cette conception pour renforcer la scurit ? Si oui, quelles amliorations suggrez-vous ?
Avez-vous dj rencontr des problmes lis cette vulnrabilit dans vos projets ? Partagez vos expriences et comment vous les avez rsolus.