Le fait que GitHub ait eu besoin de plusieurs tentatives pour résoudre les attaques RepoJacking n’inspire pas vraiment confiance. Un risque résiduel demeure.
Les chercheurs en sécurité de Checkmarx ont découvert une vulnérabilité dans GitHub qui permettait aux attaquants de prendre le contrôle de référentiels tiers et ainsi d’injecter du code malveillant dans les projets d’autres utilisateurs. Les chercheurs avertissent que cela pourrait potentiellement permettre à des milliers de progiciels d’être détournés pour fournir du code malveillant à des millions d’utilisateurs. Après que les chercheurs en sécurité ont signalé la vulnérabilité, la plate-forme de gestion du code source de Microsoft a fermé la vulnérabilité. Mais la solution semble plus compliquée. Un certain danger demeure.
RepoJacking cible des comptes GitHub renommés
À la base, l’attaque est basée sur le fait que les URL de tous les référentiels sont liées au nom d’utilisateur du créateur. Après avoir renommé le compte utilisateur, GitHub met enfin en place une redirection automatique des URL liées à l’ancien nom vers la variante avec le nouveau nom de compte. Cette mesure garantit que les projets logiciels qui reposent sur le référentiel continuent de pointer vers une URL correcte. Parce que de nombreux développeurs qui utilisent le projet du compte renommé ne remarqueront même pas le changement de nom.
Avec la technique d’attaque appelée RepoJacking, les pirates détournent le trafic de données des référentiels affectés et le redirigent vers leur propre projet. Pour ce faire, ils enregistrent simplement un nouveau compte GitHub avec l’ancien nom de l’utilisateur qui a renommé leur compte. Parce que celui-ci est ensuite à nouveau libéré pour l’enregistrement. Par conséquent, la redirection par défaut est désactivée et tout le trafic existant accède au nouveau référentiel de l’attaquant.
La solution semble compliquée
Pour éviter cela, GitHub a introduit une nouvelle barrière de sécurité. Tout dépôt qui compte plus de 100 clones au moment où son compte propriétaire est renommé est donc considéré comme « à la retraite“. Par conséquent, aucun autre utilisateur sous le nom de compte précédent ne peut utiliser le nom du référentiel pour son propre projet. Toute tentative de le faire est acquittée par la plate-forme avec un message d’erreur correspondant.
Mais les chercheurs en sécurité de Checkmarx ont trouvé plus d’un moyen de contourner les protections mises en place par GitHub. La société a comblé les lacunes encore et encore après que les chercheurs les eurent signalées. Mais cela montre à quel point la solution choisie par GitHub est sujette aux erreurs.
De plus, les chercheurs préviennent que les actions GitHub pourraient également être affectées par de tels problèmes, puisque ces « peut également être consommé en spécifiant un espace de noms GitHub.« Une attaque contre une action GitHub populaire pourrait donc »conduire à des attaques à grande échelle de la chaîne d’approvisionnement avec un impact significatif.«
« Comme mentionné, cette vulnérabilité a maintenant été corrigée et ne peut plus être exploitée, mais cela ne signifie pas qu’un autre moyen de contourner la même protection n’a pas été trouvé. »
Chercheur en sécurité Checkmarx
Les utilisateurs ne savent souvent pas si leurs projets sont à risque
Ainsi, les comptes GitHub renommés restent une cible attrayante pour les pirates pour intervenir dans la chaîne d’approvisionnement de nombreux progiciels et causer des dommages importants. Les chercheurs préviennent que le «La protection fournie est activée sur la base de métriques internes et ne donne aux utilisateurs aucune indication quant à savoir si un espace de noms particulier est protégé par celui-ci ou non.«
Par conséquent, de nombreux utilisateurs ne savent même pas si leurs propres référentiels et packages sont menacés. Pour identifier les progiciels concernés, les chercheurs ont fourni un outil open source. Cela suggère également une manière plus sûre d’utiliser les projets potentiellement vulnérables.
