GitHub indique avoir informé toutes les organisations soupçonnées d’avoir été volées dans leurs référentiels privés par des attaquants abusant de jetons d’utilisateur OAuth compromis délivrés à Heroku et Travis-CI.
« À partir de 21h30 UTC le 18 avril 2022, nous avons informé les victimes de cette campagne que nous avons identifiées comme ayant téléchargé le contenu du référentiel par une partie non autorisée en abusant de jetons d’utilisateur OAuth tiers maintenus par Heroku et Travis CI. « , a révélé la société dans une mise à jour à la déclaration originale.
Tout comme le directeur de la sécurité de GitHub, Mike Hanley, l’a déclaré précédemment lorsque la violation a été divulguée, la société n’a pas encore trouvé de preuve que l’un de ses systèmes ait été compromis depuis la découverte de l’incident.
« Nous ne pensons pas que l’attaquant ait obtenu ces jetons via une compromission de GitHub ou de ses systèmes, car les jetons en question ne sont pas stockés par GitHub dans leurs formats d’origine utilisables qui pourraient être abusés par un attaquant », a déclaré GitHub.
Tandis que GitHub, Travis CIet Héroku a révoqué tous les jetons OAuth pour bloquer tout accès ultérieur, il est conseillé aux organisations concernées de continuer à surveiller et à revoir leur journaux d’audit et journaux de sécurité des comptes d’utilisateurs pour des activités potentiellement malveillantes.
« Si nous identifions d’autres clients qui ont été touchés, nous les informerons rapidement. Si vous ne recevez pas d’e-mail de notification de notre part, cela signifie que GitHub n’a pas identifié votre compte comme étant affecté par l’incident actuel », a ajouté GitHub lundi.
Aucune donnée client Travis CI exposée
Lundi, l’équipe de Travis CI mentionné qu’il a été informé le vendredi 15 avril dernier, « que certains référentiels de clients privés peuvent avoir été consultés par un individu qui a utilisé une attaque 2FA de type man-in-the-middle, en exploitant un jeton d’intégration tiers ».
Travis CI a ajouté que l’acteur de la menace avait violé un service Heroku et avait eu accès à une clé OAuth d’application privée utilisée pour intégrer l’application Heroku et Travis CI.
Cependant, comme cette clé ne fournissait qu’un accès limité aux données des clients, Travis CI affirme que les dépôts ou les données de ses clients n’ont pas été exposés lors de l’attaque.
« Nous avons enquêté de manière approfondie sur ce problème et n’avons trouvé aucune preuve d’intrusion dans un référentiel client privé (c’est-à-dire le code source) car la clé OAuth volée lors de l’attaque Heroku ne fournit pas ce type d’accès », a déclaré l’équipe Travis CI.
« Sur la base de ce que nous avons découvert, nous ne pensons pas qu’il s’agisse d’un problème ou d’un risque pour nos clients. »
Conseils pour trouver des preuves d’activité malveillante
GitHub a partagé les conseils suivants avec les clients potentiellement concernés pour les aider à rechercher dans leurs journaux des preuves d’exfiltration 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.
GitHub a révélé cet incident vendredi soir, trois jours après avoir découvert l’attaque le 12 avril, lorsque l’attaquant a accédé à l’infrastructure de production npm de GitHub.
L’auteur de la menace a utilisé une clé d’API AWS compromise obtenue après avoir téléchargé plusieurs référentiels npm privés à l’aide de jetons OAuth volés.
L’impact sur l’organisation npm comprend l’accès non autorisé aux référentiels privés GitHub.com et « l’accès potentiel » aux packages npm stockés sur les serveurs AWS S3.
Alors que l’attaquant a volé des données à partir de référentiels privés, GitHub pense qu’aucun des packages n’a été modifié et qu’aucune donnée de compte d’utilisateur ou d’informations d’identification n’a été consultée dans cet incident.
Plus d’informations sur la manière dont GitHub a réagi pour protéger ses clients et ce que les organisations concernées doivent savoir dans l’alerte de sécurité publiée vendredi.