GitHub est une forge pour héberger des projets utilisant le système de contrôle de version
Récemment Les chercheurs d’Aqua Security ont révélé des informations sur une analyse qu’ils ont menée concernant avec l’applicabilité de l’attaque RepoJacking aux référentiels GitHub.
L’essence du problème c’est que après avoir supprimé ou renommé des projets sur GitHub, le Les référentiels tiers peuvent contenir des liens aux noms qui n’existent plus, par exemple, dans la documentation, les scripts et les instructions d’installation README.
Les chercheurs mentionnent que un attaquant peut enregistrer un nom d’utilisateur sur GitHub dupliquer un nom d’un utilisateur préexistant, en plaçant des logiciels malveillants dans un référentiel csur le nom en double et attendez que quelqu’un le télécharge en utilisant des manuels non corrigés ou un ancien code qui télécharge les dépendances à partir d’anciens liens.
Contrairement aux études précédentes, notre recherche met l’accent sur les implications de sécurité et la gravité de cette base de données si elle est exploitée par des attaquants. Beaucoup d’entre eux peuvent y trouver de nombreuses cibles de haute qualité susceptibles de RepoJacking. Dans ce blog, nous nous penchons sur les scénarios d’exploitation de cette attaque et fournissons des illustrations de chaque scénario à l’aide d’exemples concrets.
Par exemple, Le contrôle de la bibliothèque PHP phpass a été obtenu de la même manière l’année dernière. GitHub dispose d’une protection contre le réenregistrement de projets distants, mais il était possible de la contourner en créant un référentiel avec le même nom dans un compte arbitraire, puis en renommant ce compte en celui cible. Si vous souhaitez enregistrer un référentiel d’utilisateurs/représentants dans lequel le compte d’utilisateur a été supprimé, GitHub vous permettra de recréer l’utilisateur “user”, mais cela ne vous permettra pas de créer le référentiel “représentatif”. Vous pouvez contourner cette limitation en créant le référentiel « représentatif » dans le compte d’un autre utilisateur (par exemple, « utilisateur1 »), puis en modifiant le nom de cet utilisateur en « utilisateur ».
GitHub tente maintenant de résister à de telles manipulations, mais selon Aqua Security, toutes les solutions ne sont pas bloquées et la protection ne s’applique qu’aux projets les plus populaires.s, qui comptait plus de 100 clones avant le changement de nom.
En même temps, La protection n’intercepte pas les projets qui sont devenus populaires après les avoir renommés. Il ne prend pas non plus en compte le fait qu’un projet populaire peut utiliser comme dépendance un référentiel moins populaire qui a été précédemment renommé et n’est pas protégé (peut être attaqué par substitution de dépendance). Après le changement de nom, GitHub redirige automatiquement les anciens liens vers le nouveau référentiel, mais cette redirection ne dure que jusqu’à ce que l’utilisateur portant le même nom s’enregistre, de sorte que le code oublie souvent de corriger les liens vers le nouveau nom.
Les attaquants n’ont pas besoin de faire tout ce travail acharné. Ils ne sont pas liés à une organisation spécifique. Ils peuvent scanner Internet et trouver la victime de leur choix et s’ils estiment qu’il y a un profit derrière l’attaque, ils continueront jusqu’à ce qu’ils maximisent leur profit. Des sites Web comme le projet GHTorrent fournissent des données étonnantes et inestimables.
Le projet GHTorrent enregistre tout événement public (commit, PR, etc.) qui se produit sur Github et l’enregistre dans une base de données. N’importe qui peut télécharger un vidage de base de données à partir d’une période de temps spécifique. En utilisant cet ensemble de données, les acteurs malveillants peuvent découvrir les noms historiques de diverses organisations et étendre leur surface d’attaque potentielle.
L’Etude de Aqua Security a examiné un échantillon de 1,25 million de référentiels, ce qui correspond à environ 0,4 % du nombre total de dépôts sur GitHub. La liste a été dérivée de l’analyse du changelog pour un mois aléatoire (juin 2019). La susceptibilité à l’attaque RepoJacking a été trouvée dans 36983 référentiels (2,95%).
Les chercheurs ont également mené une attaque expérimentale qui a montré l’efficacité de la méthode. Dans plusieurs référentiels modifiés, la collecte d’informations sur les adresses IP qui ont téléchargé les artefacts placés dans le référentiel a été organisée. En conséquence, des téléchargements de données falsifiées ont été enregistrés sur les réseaux de plusieurs grandes entreprises.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.
