Des chercheurs en intelligence artificielle de Microsoft ont exposé accidentellement des téraoctets de données sensibles, notamment des clés privées et des mots de passe, en publiant un seau de stockage de données d’entraînement open source sur GitHub. L’exposition a eu lieu en raison d’une URL mal configurée qui accordait des permissions sur l’ensemble du compte de stockage, au lieu de se limiter à la lecture seule. Microsoft a déclaré qu'aucune donnée client n'était affectée par l'exposition au stockage Azure et « qu'aucun autre service interne n'était mis en danger en raison de ce problème », qui a été atténué.Le fournisseur de sécurité cloud Wiz a découvert 38 To de données privées Microsoft qui ont été accidentellement exposées par des chercheurs en IA employés par la grande enseigne de la technologie. Les recherches de Wiz ont été publiées lundi dans un article de blog dans le cadre d'une divulgation coordonnée avec Microsoft.
Comprendre le mécanisme
Dans Azure, un jeton SAS (Shared Access Signature) est une URL signée qui accorde l’accès aux données Azure Storage. Le niveau d'accès peut être personnalisé par l'utilisateur ; les autorisations vont de la lecture seule au contrôle total, tandis que la portée peut être soit un seul fichier, un conteneur ou un compte de stockage complet. Le délai d'expiration est également entièrement personnalisable, permettant à l'utilisateur de créer des jetons d'accès n'expirant jamais. Cette granularité offre une grande agilité aux utilisateurs, mais elle crée également le risque d'accorder trop d'accès ; dans le cas le plus permissif, le jeton peut accorder des autorisations de contrôle total, sur l’ensemble du compte, pour toujours – fournissant essentiellement le même niveau d’accès que la clé de compte elle-même.
Il existe 3 types de jetons SAS : Compte SAS, Service SAS et Délégation d'utilisateur SAS. Pour le cas des chercheurs de Microsoft, c'est le type le plus populaire qui a été utilisé : les jetons de compte SAS.
Générer un Compte SAS est un processus simple. Comme le montre l'écran ci-dessous, l'utilisateur configure la portée, les autorisations et la date d'expiration du jeton, et génère le jeton. En arrière-plan, le navigateur télécharge la clé de compte depuis Azure et signe le jeton généré avec la clé. L’ensemble de ce processus est effectué côté client ; ce n'est pas un événement Azure et le jeton résultant n'est pas un objet Azure.
Création d'un jeton SAS à privilèges élevés et sans expiration
Pour cette raison, lorsqu'un utilisateur crée un jeton hautement permissif sans expiration, l'administrateur n'a aucun moyen de savoir que ce jeton existe et où il circule. La révocation d'un jeton n'est pas non plus une tâche facile : cela nécessite de faire pivoter la clé de compte qui a signé le jeton, ce qui rend également inefficaces tous les autres jetons signés par la même clé. Ces pièges uniques font de ce service une cible facile pour les attaquants à la recherche de données exposées.
Outre le risque d’exposition accidentelle, les pièges du service en font un outil efficace pour les attaquants cherchant à maintenir la persistance sur des comptes de stockage compromis. Un récent rapport de Microsoft indique que les attaquants profitent du manque de capacités de surveillance du service pour émettre des jetons SAS privilégiés comme porte dérobée. Étant donné que l’émission du jeton n’est documentée nulle part, il n’existe aucun moyen de savoir s’il a été émis et d’agir en conséquence.
Un jeton SAS trop permissif
Selon les chercheurs en sécurité de Wiz, Hillai Ben-Sasson et Ronny Greenberg, auteurs de l'étude, l'équipe de recherche en IA de Microsoft a inclus un jeton d’accès partagé (SAS) trop permissif dans l’URL, ce qui a accidentellement exposé 38 To de données privées.
Les données exposées comprenaient les sauvegardes personnelles de deux employés de Microsoft, qui contenaient des mots de passe pour les services Microsoft, des clés secrètes et plus de 30 000 messages internes de Microsoft Teams provenant de 359 employés de Microsoft. Les données exposées depuis 2020 étaient également mal configurées pour permettre un contrôle total plutôt qu’un accès en lecture seule, ce qui signifiait que toute personne sachant où chercher pouvait potentiellement supprimer, remplacer et injecter du contenu malveillant dans ces données.
En plus de la portée d'accès trop permissive, le jeton a également été mal configuré pour permettre des autorisations de « contrôle total » au lieu d'autorisations en lecture seule. Cela signifie que non seulement un attaquant pourrait voir tous les fichiers du compte de stockage, mais il pourrait également supprimer et écraser les fichiers existants.
Ceci est particulièrement intéressant compte tenu de l’objectif initial du référentiel : fournir des modèles d’IA à utiliser dans le code de formation. Le référentiel demande aux utilisateurs de télécharger un fichier de données de modèle à partir du lien SAS et de l'insérer dans un script. Le format du fichier est ckpt, un format produit par la bibliothèque TensorFlow. Il est formaté à l’aide du formateur pickle de Python, qui est sujet à l’exécution de code arbitraire dès sa conception. Cela signifie qu’un attaquant aurait pu injecter du code malveillant dans tous les modèles d’IA de ce compte de stockage, et que tous les utilisateurs qui font confiance au référentiel GitHub de Microsoft en auraient été infectés.
Ceci est particulièrement intéressant compte tenu de l’objectif initial du référentiel : fournir des modèles d’IA à utiliser dans le code de formation. Le référentiel demande aux utilisateurs de télécharger un fichier de données de modèle à partir du lien SAS et de l'insérer dans un script. Le format du fichier est ckpt, un format produit par la bibliothèque TensorFlow. Il est formaté à l’aide du formateur pickle de Python, qui est sujet à l’exécution de code arbitraire dès sa conception. Cela signifie qu’un attaquant aurait pu injecter du code malveillant dans tous les modèles d’IA de ce compte de stockage, et que tous les utilisateurs qui font confiance au référentiel GitHub de Microsoft en auraient été infectés.
La réaction de Microsoft
Wiz a déclaré avoir partagé ses conclusions avec Microsoft le 22 juin 2023, et Microsoft a révoqué le jeton SAS deux jours plus tard, le 24 juin. Microsoft a déclaré avoir terminé son enquête sur l’impact organisationnel potentiel le 16 août. Le 7 juillet, le jeton SAS a été remplacé sur GitHub. Dans un billet de blog, le centre de réponse aux incidents de sécurité de Microsoft a déclaré que « aucune donnée client n’a été exposée et qu’aucun autre service interne n’a été mis en danger à cause de ce problème ».
Microsoft a déclaré qu’à la suite des recherches de Wiz, il a étendu le service d’analyse des secrets de GitHub, qui surveille tous les changements publics du code source ouvert pour détecter l’exposition en texte clair des informations d’identification et d’autres secrets, pour inclure tout jeton SAS qui pourrait avoir des expirations ou des privilèges trop permissifs.
Source : Wiz
Et vous ?
Quelles sont les conséquences potentielles de l’exposition accidentelle de données sensibles par les chercheurs en IA de Microsoft ? Comment Microsoft peut-il renforcer la sécurité de ses données d’entraînement open source et éviter que ce genre d’incident ne se reproduise à l’avenir ? Quelle est votre opinion sur le service d’analyse des secrets de GitHub, qui surveille les changements publics du code source ouvert pour détecter l’exposition en texte clair des informations d’identification et d’autres secrets ? Pensez-vous que les chercheurs en IA devraient être plus prudents lorsqu’ils partagent leurs données d’entraînement open source avec la communauté scientifique ?