Comment les jetons OAuth volés ont aidé à violer des dizaines d’organisations

GitHub

GitHub a partagé une chronologie de la faille de sécurité de ce mois-ci lorsqu’un acteur de la menace a eu accès et a volé des référentiels privés appartenant à des dizaines d’organisations.

L’attaquant a utilisé des jetons d’application OAuth volés délivrés à Heroku et Travis-CI pour violer les comptes clients GitHub.com avec des intégrations d’applications Heroku ou Travis CI OAuth autorisées.

Le responsable de la sécurité de GitHub, Mike Hanley, a déclaré que la société n’avait pas encore trouvé de preuve que ses systèmes avaient été piratés depuis la découverte de l’incident le 12 avril 2022.

GitHub travaille toujours à alerter tous les utilisateurs et organisations concernés, la société étant en train d’envoyer les notifications finales aux utilisateurs GitHub.com concernés à partir d’aujourd’hui.

Une analyse du comportement de l’attaquant, alors qu’il avait accès à des comptes Github compromis, montre que les activités suivantes ont été menées sur GitHub.com en utilisant les jetons d’application OAuth volés :

  1. L’attaquant s’est authentifié auprès de l’API GitHub à l’aide des jetons OAuth volés délivrés à Heroku et Travis CI.
  2. Pour la plupart des personnes qui avaient les applications Heroku ou Travis CI OAuth autorisées dans leurs comptes GitHub, l’attaquant a répertorié toutes les organisations de l’utilisateur.
  3. L’attaquant a ensuite choisi de manière sélective des cibles en fonction des organisations répertoriées.
  4. L’attaquant a répertorié les référentiels privés pour les comptes d’utilisateurs d’intérêt.
  5. L’attaquant a ensuite procédé au clonage de certains de ces référentiels privés.

« Ce modèle de comportement suggère que l’attaquant répertoriait uniquement les organisations afin d’identifier les comptes à cibler de manière sélective pour répertorier et télécharger des référentiels privés », GitHub mentionné.

« GitHub pense que ces attaques étaient très ciblées sur la base des informations disponibles et de notre analyse du comportement de l’attaquant à l’aide des jetons OAuth compromis délivrés à Travis CI et Heroku. »

Trouver des preuves d’activités malveillantes

GitHub a révélé la faille dans la soirée du 15 avril, trois jours après avoir découvert l’attaque, lorsque l’acteur malveillant a accédé à l’infrastructure de production npm de GitHub.

Au cours de la phase initiale de l’attaque, l’auteur de la menace a utilisé une clé d’API AWS compromise acquise après avoir téléchargé plusieurs référentiels npm privés à l’aide de jetons d’utilisateur OAuth volés.

Tandis que GitHub, Travis CIet Héroku ont révoqué tous les jetons OAuth pour bloquer tout accès ultérieur après la découverte de l’attaque, il est conseillé aux organisations concernées de continuer à surveiller leur journaux d’audit et journaux de sécurité des comptes d’utilisateurs pour toute activité potentiellement malveillante liée à cet incident.

GitHub a partagé les conseils suivants avec les clients potentiellement concernés pour les aider à rechercher dans les journaux des preuves d’exfiltration de données ou d’activité malveillante :

  • Passez en revue tous vos référentiels privés pour les secrets ou les informations d’identification qui y sont stockés. Plusieurs outils peuvent vous aider dans cette tâche, tels que Analyse secrète GitHub et truffier.
  • Passez en revue les applications OAuth que vous avez autorisées pour votre compte personnel ou qui sont autorisés à accéder à votre organisme et supprimer tout ce qui n’est plus nécessaire.
  • Suivez GitHub des lignes directrices pour renforcer la posture de sécurité de votre organisation GitHub.
  • La revue l’activité de votre compte, les jetons d’accès personnels, les applications OAuth et les clés SSH pour toute activité ou modification pouvant provenir de l’attaquant.
  • Les questions supplémentaires doivent être adressées à Prise en charge de GitHub.

Vous pouvez trouver plus d’informations sur la façon dont GitHub a répondu pour protéger ses clients et ce que les organisations doivent savoir dans l’alerte de sécurité initiale.