Nous avons piraté GitHub pendant un mois : voici ce que nous avons trouvé

Après une longue pause, nous revenons avec un nouveau write-up. Bien que nous ne participions pas habituellement aux programmes de bug bounty en raison d’autres engagements, nous avons relevé le défi de pirater GitHub pendant un mois et nous sommes ravis de partager nos résultats. Tout a commencé lorsque Shivam Singh (Mr. Rajput Hacker) m’a contacté en novembre et m’a encouragé à essayer le bug bounty. Nous avons décidé de nous concentrer sur npmjs.com, une filiale de GitHub. Même si GitHub est une grande entreprise et que le programme de bug bounty était public sur HackerOne, nous avons estimé que cela valait la peine d’essayer.

Se concentrer sur la logique métier

Mr. Rajput Hacker et moi avons décidé de nous concentrer uniquement sur les failles de logique métier de l’application. Avant de commencer nos recherches, nous avons veillé à comprendre l’application dans son intégralité. Cela impliquait un usage minimal de Burp Suite et une attention portée à la compréhension des fonctionnalités et des processus fondamentaux de l’application. Notre objectif était de repérer toute faiblesse dans la logique métier susceptible d’être exploitée. En limitant notre panoplie d’outils et en nous concentrant sur la compréhension de l’application, nous cherchions à mettre au jour des vulnérabilités uniques ou passées inaperçues. Comme npmjs.com était une application relativement modeste, notre compréhension et nos notes nous ont pris moins de deux heures.

Vulnérabilités découvertes

N°	Titre du rapport H1	Cible	Date de signalement (JJ/MM/AA)	Gravité	Récompense
1	Revendiquer le nom d’utilisateur d’un compte supprimé avant 90 jours peut entraîner plusieurs problèmes	https://github.com/	11/12/22	Informatif	NA
2	Les sessions du compte restent actives et liées à l’ancien nom d’utilisateur après un changement de nom d’utilisateur	https://education.github.com/	11/12/22	Faible	$2000
3	Tromper les membres d’une organisation victime via une vulnérabilité de confusion de noms dans la fonctionnalité d’invitation de membres de l’organisation	https://npmjs.com/	07/12/22	Moyenne	Doublon
4	La victime peut revendiquer le nom d’utilisateur d’un compte supprimé – conduit à une prise de contrôle du compte en contrôlant la session du compte supprimé	https://npmjs.com/	02/12/22	Moyenne	$4000
5	Supprimer le compte de n’importe qui sur NPMJS en exploitant une mauvaise configuration du système de support	https://npmjs/com/	11/12/22	Faible	Doublon ($200)
6	Contournement de la vérification de connexion sur NPMJS.com	https://npmjs.com/	16/11/22	Moyenne	$4000
	Récompense totale				$10000

Vulnérabilités signalées au GitHub Security Program

Bien que nous ayons mentionné qu’au total  9 vulnérabilités ont été signalées, nous en abordons aujourd’hui 3 ici, indiquées ci-dessous :

1. Contournement de la vérification de connexion sur npmjs.com
2. Pre-Account Takeover sur npmjs.com
3. Problème de contrôle d’accès sur education.github.com

Contournement de la vérification de connexion sur NPMJS

Description  –

En parcourant la partie authentification de npmjs.com et des fonctionnalités courantes telles que la mise à jour de l’adresse e-mail et du profil, nous avons remarqué un comportement étrange de l’application qui a attiré notre attention : le format du lien de vérification d’e-mail, du lien de réinitialisation du mot de passe & du lien envoyé pour mettre à jour l’adresse e-mail . 

Le lien avait pour toutes les fonctionnalités le format https://npmjs.com/verify/{some_random_token_here} – qu’il s’agisse de la réinitialisation du mot de passe, du lien de vérification d’e-mail ou de tout autre lien du site . Nous avons ensuite observé que, à chaque connexion, l’application envoie un code de vérification à l’adresse e-mail enregistrée, code qu’il faut saisir dans le cadre de la vérification de connexion (une sorte de code 2FA/MFA par e-mail) pour se connecter au compte avec succès .  Nous avons alors tenté de contourner cette fonctionnalité et y sommes parvenus – ayant parcouru l’application en profondeur au cours des 2 dernières heures, nous connaissions chaque fonctionnalité, avons pu établir les liens et trouver le contournement ; lisez les étapes de reproduction ci-dessous pour voir comment nous avons procédé .

Lors de notre examen du processus d’authentification et des fonctionnalités courantes de npmjs.com, telles que la mise à jour des adresses e-mail et des profils, nous avons découvert un comportement singulier dans le format des liens de vérification d’e-mail, des liens de réinitialisation du mot de passe et des liens envoyés pour mettre à jour les adresses e-mail. Ces liens avaient le format https://npmjs.com/verify/{random_token} et servaient à toutes les fonctionnalités, y compris la réinitialisation du mot de passe, la vérification d’e-mail et d’autres.

Nous avons également remarqué qu’à chaque fois qu’un utilisateur se connectait à l’application, un code de vérification était envoyé à l’adresse e-mail enregistrée. Ce code de vérification était requis pour finaliser le processus de connexion, faisant office d’authentification à deux facteurs. Deuxième chose que nous avons remarquée : lors de la mise à jour d’une adresse e-mail sur npmjs, la modification s’effectuait sans exiger de confirmation par mot de passe. Un e-mail était envoyé à la fois à l’ancienne et à la nouvelle adresse. L’e-mail envoyé à l’ancienne adresse informait le destinataire que, s’il n’était pas à l’origine du changement, il pouvait cliquer sur un lien (https://npmjs.com/verify/{some_random_token_here}) pour annuler la modification et rétablir son ancienne adresse comme adresse actuelle. L’e-mail envoyé à la nouvelle adresse contenait un lien pour vérifier la nouvelle adresse e-mail et la lier au compte qui venait d’être mis à jour.

Nous avons rencontré un problème surprenant en tentant de nous connecter à un compte après avoir mis à jour l’adresse e-mail sur la page de profil. Bien que nous n’ayons confirmé ni cliqué sur aucun lien dans l’ancien ou le nouvel e-mail, le système affichait un message indiquant qu’un code de vérification avait été envoyé à la nouvelle adresse non vérifiée. Cela semblait suggérer que nous ne pourrions pas nous connecter.  Cependant, en y regardant de plus près, nous avons découvert un e-mail envoyé à notre ancienne adresse, nous demandant d’annuler le changement afin d’éviter le verrouillage du compte. En cliquant sur le lien fourni (https://npmjs.com/verify/{random_token}) pour annuler la modification de l’e-mail, nous avons été redirigés vers la page de connexion. À notre grande surprise, lorsque nous avons saisi nos identifiants, le système n’a pas demandé le code de vérification et nous a permis de nous connecter et d’annuler le changement d’e-mail.

Cependant, après un examen plus approfondi, nous avons réussi à contourner cette fonctionnalité. Notre compréhension approfondie de l’application, acquise en passant deux heures à nous familiariser avec ses fonctionnalités, nous a permis de relier différentes fonctions et de trouver le contournement. Les étapes de reproduction du contournement sont indiquées ci-dessous.

Étapes de reproduction –

1. Inscription avec [email protected] (nom d’utilisateur attacker1)
2. Se connecter à attacker1 avec l’identifiant et le mot de passe (car la connexion npmjs ne fonctionne qu’avec le nom d’utilisateur et le mot de passe)
3. Aller dans Account > Update Email > [email protected]
4. Vérifiez la boîte de réception de [email protected], vous y verrez un e-mail de npmjs.com

5.Ouvrir le lien https://www.npmjs.com/verify/{some_random_token_here} Il redirigera vers la connexion > Essayez de vous connecter avec le nom d’utilisateur & le mot de passe de la victime
6.Vous serez redirigé vers la page 404 & connecté au compte sans code de vérification ! (Même si la page affiche un message vous indiquant que vous n’êtes pas connecté au bon utilisateur)

POC –

https://youtube.com/watch?v=ox6np-b3nyI%3Ffeature%3Doembed

Impact –

Un attaquant peut exploiter une vulnérabilité de npmjs pour contourner le processus de vérification de connexion, censé protéger contre les attaques de collecte et de fuite d’identifiants. Cela permet en pratique à l’attaquant d’obtenir un accès non autorisé au compte sans passer par les contrôles de sécurité prévus. Cette vulnérabilité est essentiellement un contournement du processus de vérification de connexion, qui sert de mesure temporaire jusqu’à l’activation de l’authentification à deux facteurs.

Notre conclusion –

En conclusion, même si nous avons pris plaisir à découvrir une vulnérabilité sur GitHub, nous avons été déçus par la récompense reçue. Bien que nous ayons rempli les critères d’une vulnérabilité critique énumérés sur la page de politique Hackerone de GitHub – notamment le contournement du processus de connexion, l’accès à des données utilisateur sensibles et l’accès aux données d’un autre utilisateur -, nous avons été classés en gravité moyenne et n’avons reçu aucune justification claire de la part de GitHub. Malgré notre tentative d’échanger avec l’équipe de GitHub via la médiation H1, nos efforts sont restés vains. Nous estimons que cette situation soulève des questions quant à l’équité du système de récompense de GitHub et au respect de ses propres politiques.

Critères de vulnérabilité critique mentionnés sur la page de politique Hackerone de GitHub

• exécution arbitraire de code/commandes sur un serveur de notre réseau de production
• requêtes SQL arbitraires sur une base de données de production
• contournement du processus de connexion, que ce soit le mot de passe ou la 2FA
• accès à des données utilisateur de production sensibles ou accès à des systèmes internes de production
• accès aux données d’un autre utilisateur dans le service GitHub Actions

CAPTURE D’ÉCRAN DE LA POLITIQUE GITHUB

Demande de retour de la part de l’équipe GitHub :

Si un membre de l’équipe GitHub dispose d’une justification pour le classement de la vulnérabilité, nous apprécierions une réponse sur le rapport ou en nous contactant sur nos comptes H1 @th3pr0xyb0y et @mrrajputhacker2

Pre-Account Takeover sur npmjs.com 

Description  –

Après avoir examiné l’application en profondeur, nous avons décidé de nous concentrer sur la recherche de bugs logiques. Au cours de notre observation, nous avons remarqué que le processus d’authentification n’utilisait qu’un nom d’utilisateur pour se connecter et que l’adresse e-mail pouvait être facilement modifiée sans vérification du mot de passe. Cela nous a amenés à penser que le nom d’utilisateur était un élément critique du backend de npmjs.com.

Nous avons testé la fonctionnalité de suppression de compte et exploré les scénarios suivants :

1. Pouvions-nous encore accéder à la session du compte s’il était connecté depuis un autre navigateur ?
   Nous avons constaté que la suppression du compte depuis un navigateur déconnecte immédiatement l’utilisateur de toutes les autres sessions.
2. Pouvions-nous nous inscrire en utilisant le même nom d’utilisateur qu’un compte récemment supprimé ?
   Nos tests ont montré qu’il n’était pas possible de s’inscrire avec un nom d’utilisateur existant ou précédemment supprimé.
3. Existait-il un moyen de changer le nom d’utilisateur ou de revendiquer un nom d’utilisateur nouveau/supprimé ? Nous avons découvert une option pour revendiquer ou changer un nom d’utilisateur dans l’application – en créant une organisation dans le compte npmjs. Cela nous permettait de choisir un nouveau nom d’utilisateur pour l’organisation ou de convertir notre compte en organisation, changeant ainsi de fait notre nom d’utilisateur. Cependant, même cette option ne permettait pas de passer à un nom d’utilisateur précédemment supprimé.

Malgré des impasses sur les trois scénarios, nous étions déterminés à trouver une solution et sommes parvenus, avec notre ténacité, à contourner le système avec succès. Nous avons documenté les étapes dans notre rapport pour montrer comment nous avons pu créer un pre-account takeover.

Nouvelles observations dans nos recherches –

Nous savions déjà que nous pouvions demander la suppression de notre compte en soumettant un ticket de support. Nous avons donc testé cette méthode et supprimé notre compte. Après avoir reçu l’e-mail de confirmation, nous avons découvert que, même si le compte était supprimé, nous étions toujours connectés avec notre nom d’utilisateur affiché en haut à droite, mais sans pouvoir effectuer la moindre action.

Nous avons essayé de revendiquer à nouveau le nom d’utilisateur supprimé en nous inscrivant dans un autre navigateur, mais ce n’était pas possible. Cependant, comme nous avions trouvé un moyen de changer notre nom d’utilisateur, nous avons tenté de le revendiquer à nouveau dans un autre navigateur. À notre grande surprise, nous avons réussi, et dès que nous avons revendiqué le nom d’utilisateur, la session a été transférée vers notre session précédente où nous ne voyions qu’une page d’erreur 404. Ainsi, nous avons pu prendre le contrôle du compte d’une personne qui tentait de changer son nom d’utilisateur pour un compte supprimé, car nous avions les cookies et la session nous a été transférée.

Si l’explication semble confuse, veuillez vous reporter aux étapes de reproduction et à la preuve de concept pour mieux comprendre cette vulnérabilité.

Étapes de reproduction –

1. Inscrivez-vous en tant qu’attaquant avec un nom d’utilisateur courant (par exemple commonusername123) en utilisant le navigateur Google Chrome.
2. Demandez la suppression du compte au support.
3. Une fois le compte supprimé par le support, actualisez le navigateur sur lequel le compte était connecté. Vous verrez que toutes les pages sauf la page de profil affichent votre nom d’utilisateur (le lien de la page serait https://npmjs.com/~username).
4. Essayez d’accéder à https://www.npmjs.com/settings/commonusername123/profile. Vous verrez une page 404.
5. Inscrivez-vous en tant que victime avec un nom d’utilisateur différent (par exemple victimusername123) en utilisant le navigateur Firefox.
6. Convertissez le compte de la victime en organisation. Le nom d’utilisateur de l’organisation deviendra victimusername123 et vous serez invité à choisir un nouveau nom d’utilisateur. Choisissez commonusername123 comme nouveau nom d’utilisateur pour le compte.
7. Actualisez la page de la session de l’attaquant https://npmjs.com/~username en utilisant le navigateur Google Chrome.
8. Essayez d’accéder à https://www.npmjs.com/settings/commonusername123/profile. Vous verrez désormais l’e-mail de la victime (par exemple [email protected]) et vous aurez accès au compte de la victime et à l’organisation qu’elle a créée.

POC –

https://youtube.com/watch?v=5039T3y8yFw%3Ffeature%3Doembed

Impact –

Un acteur malveillant peut créer plusieurs comptes avec des noms d’utilisateur courants sur npmjs.com, les supprimer en soumettant un ticket de support et conserver les cookies. En conséquence, il a la possibilité de prendre le contrôle d’un compte si quelqu’un d’autre revendique ces noms d’utilisateur.

Notre conclusion – 

En conclusion, même si nous étions enthousiastes à l’idée de mettre au jour une vulnérabilité sur GitHub, nous avons été déçus par la récompense reçue. Il s’agissait d’une prise de contrôle de compte complexe mais réalisable, qui aurait pu toucher une grande organisation. Pour clarifier l’impact, nous disposions encore d’un compte avec des cookies stockés et des sessions actives depuis plus de trois mois, car la session d’un compte supprimé n’expire jamais sur npmjs. Cependant, GitHub a considéré cette vulnérabilité comme “moyenne” et nous a accordé une prime de $4000 seulement.

Problème de contrôle d’accès sur education.github.com

Description  –

Insatisfaits de la réponse de GitHub à nos précédentes vulnérabilités signalées sur npmjs et de la récompense, nous avons décidé de nous concentrer sur d’autres sous-domaines de GitHub. Nous avons découvert que education.github.com utilisait l’authentification unique (SSO) de GitHub pour son processus de connexion. Inspirés par les bugs trouvés sur npmjs, nous avons expérimenté une approche similaire en utilisant des noms d’utilisateur de comptes supprimés.

À notre grande surprise, nous avons constaté que la suppression d’un compte GitHub n’entraînait pas l’expiration de la session sur education.github.com, et chaque page affichait une erreur 404, même en étant toujours connecté. Dans un autre navigateur, nous avons tenté de créer un nouveau compte GitHub avec le même nom d’utilisateur supprimé, mais selon la politique de GitHub, les noms d’utilisateur ne peuvent pas être revendiqués pendant 90 jours après leur suppression .

Cependant, malgré ces impasses, nous avons pu contourner le problème et obtenir le contrôle d’accès . 

Contournement du contrôle d’accès –

Nous avons observé que, même après avoir changé un nom d’utilisateur dans GitHub et actualisé notre session d’education.github.com, le nom d’utilisateur restait le même – il ne changeait pas, bien que nous l’ayons modifié dans notre profil GitHub. Cela se produit parce que le jeton de session est lié au nom d’utilisateur et que le SSO ne l’actualise que lorsque nous nous reconnectons via GitHub. Nous avons donc rapidement revendiqué le compte GitHub supprimé, puis l’ancien nom d’utilisateur qui était encore associé à https://education.github.com  avec ce compte, à l’aide d’un nouveau compte GitHub dans un autre navigateur, et nous nous sommes connectés à https://education.github.com sur un nouveau navigateur.  Nous avons alors observé que les deux comptes avaient le même nom d’utilisateur mais des adresses e-mail différentes et étaient parfaitement fonctionnels ; ainsi, si nous soumettions un formulaire éducatif ou déclenchions des fonctions, cela pouvait causer des dommages à l’intégrité des données des deux côtés. Nous avons donc signalé cela comme un problème, et il a été accepté comme un problème valide .

Nous avons remarqué que, même après avoir changé notre nom d’utilisateur GitHub, la session sur education.github.com restait inchangée. Cela s’expliquait par le fait que le jeton de session était lié au nom d’utilisateur et que le SSO ne l’actualisait qu’à la connexion via GitHub. Pour exploiter cela, nous avons rapidement revendiqué un compte GitHub supprimé, puis l’ancien nom d’utilisateur, qui était encore associé au compte education.github.com. Nous nous sommes ensuite connectés à education.github.com dans un autre navigateur avec un nouveau compte GitHub, et avons constaté que les deux comptes avaient désormais le même nom d’utilisateur mais des adresses e-mail différentes et étaient pleinement fonctionnels.

Cela signifiait que si nous soumettions un formulaire éducatif ou déclenchions des fonctions, cela pouvait entraîner des dommages à l’intégrité des données des deux côtés. Nous avons rapidement signalé cela comme un problème et il a été accepté comme une vulnérabilité valide.

Étapes de reproduction – 

1. Connectez-vous à votre compte GitHub
2. Rendez-vous sur https://education.github.com/schools
3. Changez le nom d’utilisateur de votre compte GitHub
4. Actualisez la page ou rendez-vous à nouveau sur https://education.github.com/schools et vérifiez le nom d’utilisateur depuis l’icône de profil à droite
5. Vous verrez que l’ancien nom d’utilisateur est toujours actif sur education.github.com
6. Comme l’ancien nom d’utilisateur est revendicable, il semble qu’une prise de contrôle de compte sur education.github.com soit possible en le revendiquant.
7. Si vous n’avez pas d’adresse e-mail universitaire, vous ne pouvez pas vérifier si les actions effectuées sur l’ancienne session affecteront un nouveau compte inscrit avec l’ancien nom d’utilisateur.
8. Connectez-vous à education.github.com dans une nouvelle fenêtre Chrome avec un compte nouvellement créé qui a le même nom d’utilisateur que l’ancienne session.
9. Vous verrez que vous avez désormais deux sessions actives avec le même nom d’utilisateur.

Impact –

L’impact de ce problème devrait être évalué par l’équipe GitHub. Il a le potentiel de compromettre des informations sensibles de nouveaux utilisateurs, telles que leur établissement ou leur adresse e-mail et leurs informations personnelles identifiables (PII), s’ils s’inscrivent avec le nom d’utilisateur pour lequel une session active existe. Cela pourrait entraîner une prise de contrôle de compte et la fuite de PII.

Notre conclusion – 

Nous avons été heureux de découvrir cette vulnérabilité sur GitHub, même si elle ressemblait à ce que nous avions trouvé sur npmjs. Cette fois, nous n’avons pas pu évaluer l’impact complet du problème. Néanmoins, nous avons été satisfaits de la récompense accordée.

Avez-vous appris quelque chose grâce à nous ?

Aidez-nous en partageant cet article avec vos amis, votre famille et vos collègues, et en nous suivant sur nos comptes de réseaux sociaux. Vous pouvez également vous abonner à notre liste de diffusion pour davantage de write-ups instructifs sur nos découvertes. Manifestez votre soutien en tweetant à propos de cet article et en le partageant autant que possible avec la communauté.

Découvrez notre nouveau produit, Blind XSS Hunter, conçu pour soutenir la communauté, uniquement sur https://bxsshunter.com.

Préparez-vous à un lancement passionnant de CyberXplore ! Nous avons travaillé d’arrache-pied ces deux dernières années pour perfectionner un produit que nous avons hâte de partager avec vous. Soyez parmi les premiers à en faire l’expérience en restant connectés avec nous ou en nous suivant dans notre aventure. Et pour toutes les dernières nouveautés, n’oubliez pas de vous abonner à notre newsletter ! C’est un lancement à ne pas manquer !