GitHub a confirmé mardi que des attaquants avaient obtenu un accès non autorisé à ses dépôts internes après avoir compromis un appareil d'employé via une extension Visual Studio Code empoisonnée. La plateforme détenue par Microsoft a détecté et contenu la compromission, supprimé l'extension malveillante, isolé le point d'accès affecté et lancé immédiatement une réponse à l'incident.
La société a déclaré que son évaluation actuelle indique que la violation n'a impliqué que l'exfiltration de dépôts internes à GitHub. Les dépôts clients, les organisations entreprises et les données utilisateur stockées en dehors des systèmes internes de GitHub ne seraient pas concernées.
L'ampleur de la violation
GitHub a confirmé que les affirmations de l'attaquant concernant environ 3 800 dépôts internes sont cohérentes avec son propre examen. Le groupe de menaces TeamPCP a revendiqué la responsabilité de la violation et tenterait de vendre l'ensemble de données volées sur des forums de cybercriminalité souterrains pour plus de 50 000 $, selon les rapports. Le groupe affirme que les données incluent le code source propriétaire de la plateforme et des fichiers internes de l'organisation provenant d'environ 4 000 dépôts privés.
GitHub a déclaré qu'il avait rapidement procédé à la rotation des identifiants critiques après avoir détecté la violation, en priorisant d'abord les secrets à impact le plus élevé. L'entreprise continue d'analyser les journaux, de valider la rotation des secrets et de surveiller toute activité ultérieure.
Pourquoi l'accès au dépôt interne est sérieux
L'entreprise a déclaré qu'elle n'a aucune preuve d'impact sur les informations clients stockées en dehors des dépôts internes. Des chercheurs en sécurité ont souligné que le libellé précis est important. L'absence de preuve d'impact ne constitue pas une confirmation que les données clients sont sécurisées. Cela signifie que l'enquête est en cours et que l'étendue complète de l'impact n'a pas encore été déterminée.
Les dépôts internes contiennent généralement des configurations d'infrastructure, des scripts de déploiement, de la documentation API interne, des identifiants de staging, des indicateurs de fonctionnalités, des points d'observation de surveillance et des services non documentés. L'accès au code source interne fournit effectivement un plan de l'architecture complète d'un système, même sans accès direct aux données clients.
Les professionnels de la sécurité ont également souligné l'importance de la mention explicite par GitHub de la surveillance des activités ultérieures. Les attaques modernes rares fois s'arrêtent à l'accès initial. La progression standard passe de la prise de pied initiale à la reconnaissance, à l'élévation de privilèges, à la persistance, puis à une deuxième vague d'activités ciblées après que les défenseurs pensent que la menace a été contenue.
Ce que GitHub fait
GitHub a indiqué que les secrets critiques ont été renouvelés le même jour où la violation a été détectée, les identifiants les plus sensibles étant traités en premier. L'entreprise continue de surveiller l'infrastructure à la recherche d'activités secondaires et publiera un rapport d'incident plus complet une fois l'enquête terminée. Les clients seront notifiés via les canaux de réponse aux incidents établis si un impact sur leurs données est découvert.
Les développeurs utilisant GitHub ont été invités à vérifier et à renouveler toutes les clés API stockées dans les dépôts, à titre préventif, même si les dépôts clients ne sont pas censés avoir été directement affectés.