La société Truffle Security a publié des scénarios d'attaques sur plusieurs techniques standard de travail avec les dépôts sur GitHub, permettant d'extraire des données de dépôts distants qui ont des forks publics ou qui ont été créés en tant que forks.
La possibilité d'accéder aux commits par hash dans tous les forks associés d'un dépôt est due au fait que GitHub, dans un souci d'optimisation et d'élimination des doublons, stocke ensemble tous les objets du dépôt principal et des forks, ne séparant logiquement que l'appartenance des commits. Ce stockage permet de visualiser dans le dépôt principal n'importe quel commit d'un fork en indiquant explicitement son hash dans l'URL. Par exemple, un utilisateur peut créer un fork du dépôt "/torvalds/linux" et y ajouter n'importe quel code, après quoi ce code sera accessible via un lien hash direct dans le dépôt "/torvalds/linux". En cas de suppression du dépôt, si au moins un fork public existe, les données du dépôt supprimé restent accessibles par le hash du commit.
Trois scénarios représentant une menace pour la sécurité sont proposés :
- Le premier scénario concerne les situations où les développeurs créent des forks de dépôts publics, y ajoutent des modifications, expérimentent, puis les suppriment. En plus de la fuite de code qui n'est pas destiné à être publié, le risque provient de la situation où, dans le cadre des expériences, des clés d'accès API fonctionnelles sont ajoutées au code des fichiers d'exemples. Dans ce cas, un attaquant peut accéder à la modification par le hash du commit, après la suppression du fork via le dépôt principal. Par exemple, de cette manière, les chercheurs ont pu identifier 30 clés d'accès API fonctionnelles en étudiant trois dépôts liés à l'apprentissage automatique avec un grand nombre de forks.
- Le deuxième scénario porte sur la possibilité d'accéder aux données après la suppression d'un dépôt principal, si des forks ont été créés pour ce dépôt. Par exemple, il est mentionné qu'un dépôt public d'une entreprise a accidentellement exposé les clés privées d'un de ses employés, permettant d'accéder à tous les dépôts de cette entreprise sur GitHub. L'entreprise a supprimé le dépôt par lequel la fuite a eu lieu, mais les clés restent accessibles via des requêtes utilisant le hash des commits dans les dépôts forkés.
- Le troisième scénario est lié au modèle de développement de projets, où une version de base est développée dans un dépôt public et une version propriétaire étendue dans un dépôt privé. Si une entreprise a initialement développé un projet dans un dépôt privé, puis après l'ouverture du code, l'a transféré vers un dépôt public tout en continuant de développer une version interne ou étendue dans un fork privé, il est possible d'accéder aux modifications ajoutées au fork privé par le biais des hashes de commits via le dépôt public. Cependant, l'accès n'est possible qu'aux modifications ajoutées au fork privé avant le passage du dépôt principal au statut public (les dépôts privés et publics sont séparés, mais lorsque deux dépôts étaient privés, les commits étaient stockés ensemble, donc ils ont été conservés dans le dépôt après sa transition vers le statut public).
Le truc permettant d'accéder aux commits dans les forks d'un dépôt via un lien vers le dépôt principal est connu depuis de nombreuses années et est périodiquement utilisé pour diverses blagues et pour induire en erreur les développeurs (par exemple, des farceurs créent périodiquement l'apparence d'un backdoor dans le dépôt du noyau Linux sur GitHub de cette manière). En réponse à de telles blagues, GitHub a ajouté un avertissement indiquant que le commit demandé n'appartient pas aux branches du dépôt actuel et pourrait appartenir à un fork. Cependant, la possibilité d'accéder aux commits par le hash dans n'importe quel dépôt lié est considérée comme inoffensive, car pour accéder aux données dans des forks privés et distants, il faut connaître le hash du commit.
Il est irréel de trouver un hachage de commit basé sur l'algorithme SHA-1 qui inclut 32 caractères, mais il s'avère que ce n'est pas nécessaire. GitHub prend en charge une forme abrégée de référence aux commits, permettant d'adresser les modifications par les premiers caractères du hachage, à condition qu'il n'y ait pas de chevauchements avec d'autres commits. Le nombre minimum de caractères pour une adresse de hachage abrégée est de 4, ce qui correspond à 65 000 combinaisons possibles (16^4). Toutefois, il se peut que cette recherche ne soit pas nécessaire, car l'API de GitHub permet de connecter des gestionnaires pour intercepter les événements, qui sont utilisés par des projets tiers maintenant un archivage avec un journal complet de toutes les opérations, dans lequel l'information sur les hachages de commits persiste même après la suppression des dépôts.
Source : opennet.ru
