Lapsus$ fait une nouvelle victime : analyse de la fuite Microsoft
Lapsus$ a poursuivi son rythme soutenu d'intrusions en divulguant maintenant le code source interne de 250 projets Microsoft.
Lapsus$ a poursuivi son rythme soutenu d'intrusions en divulguant maintenant le code source interne de 250 projets Microsoft, ce qui, selon le groupe, représente 90% du code source de Bing et 45% du code source de Bing Maps et Cortana. Ces fuites interviennent après celles, du code source de Samsung et de Nvidia, et après celles de Vodafone, Okta, Ubisoft et Mercado Libre.
Bien que Lapsus$ cible également les comptes administrateurs, nous savons qu'il se concentre sur le code source privé des entreprises. Ce code source est non seulement précieux pour découvrir les vulnérabilités des applications, mais aussi parce qu'il contient souvent des informations sensibles comme des secrets.
Comment Lapsus accède-t-il au code source interne ?
Bien que l'on ne sache pas exactement comment Lapsus$ a obtenu l'accès initial à Microsoft, ce dernier a déclaré sur son blog qu'il avait remarqué que plusieurs techniques étaient utilisées :
- Déploiement du voleur de mots de passe malveillant Redline pour obtenir des mots de passe et des jetons de session.
- Achat d'informations d'identification et de jetons de session sur des forums criminels clandestins.
- Paiement d’employés des organisations ciblées (ou les fournisseurs/partenaires commerciaux) pour accéder aux informations d'identification et à l'approbation MFA.
- Recherche de secrets exposés dans des dépôts de code publics.
Microsoft a également déclaré que le groupe (qu'il appelle Dev-0537) a utilisé des comptes personnels d'employés susceptibles d'avoir divulgué des informations d'identification de l'entreprise, par exemple sur les dépôts publics Github personnels des employés.
"Dans certains cas, DEV-0537 a d'abord ciblé et compromis les comptes personnels ou privés (non liés au travail) d'un individu, lui donnant accès pour ensuite rechercher des informations d'identification supplémentaires qui pourraient être utilisées pour accéder aux systèmes de l'entreprise."
Cela nous permet de mieux comprendre comment Lapsus$ accède aux organisations et il est clair qu'il y a une relation avec les secrets, qu'ils soient divulgués publiquement, achetés à un acteur qui ne devrait pas y avoir accès ou volés à l'aide d'outils malveillants.
Alors que Microsoft a affirmé que les dommages causés par l'attaque étaient très limités, déclarant:
"Aucun code ou donnée client n'a été impliqué dans les activités observées. Notre enquête a révélé qu'un seul compte avait été compromis, accordant un accès limité."
Ils ont également déclaré que le fait que leur code source reste secret n'est pas fondamental dans leur approche de la sécurité.
"Microsoft ne s'appuie pas sur le secret du code comme mesure de sécurité et la visualisation du code source ne conduit pas à une élévation du risque."
Analyse du code source de Microsoft par GitGuardian
Après avoir examiné le code divulgué, GitGuardian a constaté que le code source de Microsoft montre une attention particulière portée sur la sécurité, pourtant il y avait encore beaucoup d'informations sensibles trouvées en son sein.
Suite à la fuite du code source de Samsung, GitGuardian a fourni une analyse sur le nombre de secrets (clés d'api, certificats de sécurité, credentials.....) qui étaient présents dans les dépôts. Nous avons également effectué la même analyse sur le code source de Microsoft.
Au total, nous avons trouvé 376 secrets dans les projets Microsoft ayant fait l'objet d'une fuite.
Bien que la quantité de secrets découvert soit encore élevée, elle représente environ la moitié de ce que l'on pourrait s'attendre à trouver dans une organisation comparable. Cela montre que Microsoft a mis en place des mesures pour s'assurer que les informations sensibles ne se trouvent pas dans le code source, mais cela montre aussi que même dans les entreprises les plus soucieuses de la sécurité, les fuites de secrets restent un problème important.
GitGuardian a pour politique de ne jamais valider si les clés d'une brèche publique sont actuellement actives afin de ne pas perturber les experts de la victime qui tentent de confirmer si les clés ont été utilisées. Nous ne pouvons donc pas confirmer quelles clés sont actuellement actives, ou étaient actives au moment de la violation.
Types de secrets trouvés
La plupart des clés que nous avons examinées présentaient les caractéristiques que nous nous attendons à voir avec des secrets utilisés dans une application et nous pensons donc que beaucoup d'entre elles permettent d'accéder aux systèmes et à l'infrastructure internes de Microsoft. On ne sait pas à quel point ces systèmes sont critiques et si d'autres politiques de sécurité de Microsoft pourrait limiter l'accès, mais ce sont certainement des actifs précieux pour Lapsus$.
Clés AWS
5 clés AWS IAM ont été découvertes dans le code source, ci-dessous un exemple de clé découverte dans un projet de transfert de données tiers.
Clé d'abonnement Azure
Une clé d'abonnement Azure a été découverte dans un fichier python. Il y a plusieurs API différentes qui sont fournies par Azure, par exemple la recherche Bing, la traduction, la reconnaissance vocale, etc. Ces API peuvent avoir différents niveaux de criticité, mais même les clés non critiques peuvent être utilisées pour bloquer des services et utiliser des ressources importantes.
Clé RSA
3 clés RSA ont été trouvées, ceci est un exemple de clé trouvée dans un fichier .pem sensible. Ces fichiers peuvent être utilisés pour décrypter des données ou pour simuler l'authenticité de données.
Paires d'identifiants
Nous avons également trouvé de nombreuses paires nom d'utilisateur-mot de passe, comme cet exemple trouvé dans un fichier de configuration d'application. Ces informations d'identification peuvent être utilisées dans une variété de services tels que l'accès aux bases de données.
Pourquoi les fichiers sensibles existent-ils dans le code source ?
Les dépôts centraux de code source sont accessibles à un très grand nombre de développeurs au sein d'organisations de la taille de Microsoft. Mais si l'on tient compte de ce nombre important de développeurs et du fait que les systèmes de contrôle de version tels que git n’oublient rien, des erreurs se produisent fréquemment lorsque des informations sensibles sont transmises, alors qu'il s'agit d'une mauvaise pratique universellement reconnue.
Le rapport de GitGuardian sur le State of Secrets Sprawl a mis en évidence le défi que représente pour les équipes de sécurité des applications la gestion des fuites ou de la prolifération des secrets dans les dépôts de code.
En moyenne, en 2021, une entreprise type comptant 400 développeurs et 4 ingénieurs AppSec découvrirait 1 050 secrets uniques divulgués lors de l'analyse de ses dépôts et commits. Chaque secret étant détecté à 13 endroits différents en moyenne, la quantité de travail nécessaire pour y remédier dépasse de loin les capacités des équipes AppSec actuelles (1 ingénieur AppSec pour 100 développeurs)*.
Bien que le code source de Microsoft contienne beaucoup moins de secrets que pour des organisations comparables, cela montre que même l'entreprise qui porte le plus d’attention à sa la sécurité et disposant d'importantes ressources a quand même des informations sensibles dans son code source.