Incidents associés
Loading...
- L'équipe de recherche en IA de Microsoft, en publiant un ensemble de données de formation open source sur GitHub, a accidentellement exposé 38 téraoctets de données privées supplémentaires, y compris une sauvegarde sur disque des postes de travail de deux employés. * La sauvegarde comprend des secrets, des clés privées, des mots de passe et plus de 30 000 messages internes de Microsoft Teams. * Les chercheurs ont partagé leurs fichiers à l'aide d'une fonctionnalité Azure appelée jetons SAS, qui vous permet de partager des données à partir de comptes Azure Storage. * Le niveau d'accès peut être limité à des fichiers spécifiques uniquement ; cependant, dans ce cas, le lien a été configuré pour partager l'intégralité du compte de stockage, y compris 38 To supplémentaires de fichiers privés. * Ce cas est un exemple des nouveaux risques auxquels les organisations sont confrontées lorsqu'elles commencent à exploiter plus largement la puissance de l'IA, alors qu'un plus grand nombre de leurs ingénieurs travaillent désormais avec d'énormes quantités de données de formation. Alors que les data scientists et les ingénieurs s'efforcent de mettre de nouvelles solutions d'IA en production, les quantités massives de données qu'ils traitent nécessitent des contrôles et des protections de sécurité supplémentaires. Dans le cadre des travaux en cours de l'équipe de recherche Wiz sur l'exposition accidentelle de données hébergées dans le cloud, l'équipe a analysé Internet à la recherche de conteneurs de stockage mal configurés. Au cours de ce processus, nous avons trouvé un référentiel GitHub sous l'organisation Microsoft nommé « robust-models-transfer ». Le référentiel appartient à la division de recherche en IA de Microsoft et son objectif est de fournir du code open source et des modèles d'IA pour la reconnaissance d'images. Les lecteurs du référentiel ont été invités à télécharger les modèles à partir d'une URL de stockage Azure : L'URL de stockage exposée, extraite du référentiel GitHub de Microsoft. Cependant, cette URL permettait d'accéder à plus que de simples modèles open source. Il a été configuré pour accorder des autorisations sur l’ensemble du compte de stockage, exposant ainsi par erreur des données privées supplémentaires. Notre analyse montre que ce compte contenait 38 To de données supplémentaires, y compris les sauvegardes des ordinateurs personnels des employés de Microsoft. Les sauvegardes contenaient des données personnelles sensibles, notamment des mots de passe d'accès aux services Microsoft, des clés secrètes et plus de 30 000 messages internes Microsoft Teams provenant de 359 employés de Microsoft. Conteneurs exposés sous le compte de stockage « robustnessws4285631339 » Un petit échantillon de fichiers sensibles trouvés sur les sauvegardes de l'ordinateur Conversation d'équipes rédigée entre deux employés de Microsoft En plus de l'étendue d'accès trop permissive, le jeton a également été mal configuré pour permettre des autorisations de « contrôle total » au lieu de lecture seulement. 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 de par 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. Cependant, il est important de noter que ce compte de stockage n’a pas été directement exposé au public ; en fait, c'était un compte de stockage privé. Les développeurs Microsoft ont utilisé un mécanisme Azure appelé « jetons SAS », qui vous permet de créer un lien partageable donnant accès aux données d'un compte de stockage Azure - alors qu'après inspection, le compte de stockage semble toujours complètement privé. Présentation des jetons SAS ------------------------------- 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 (comme nous l’avons vu dans le jeton de Microsoft ci-dessus), 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. Dans ce blog, nous nous concentrerons sur le type le plus populaire : les jetons de compte SAS, qui ont également été utilisés dans le référentiel de Microsoft. 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, un 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 Microsoft](https://www.microsoft.com/en-us/security/blog/2023/09/07/cloud-storage-security-whats-new-in-the-threat-matrix/# :~:text=Create%20SAS%20Token) 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. Risques de sécurité SAS ----------------------- Les jetons SAS présentent un risque de sécurité, car ils permettent de partager des informations avec des identités externes non identifiées. Le risque peut être examiné sous plusieurs angles : autorisations, hygiène, gestion et surveillance. ### Autorisations Un jeton SAS peut accorder un niveau d'accès très élevé à un compte de stockage, que ce soit via des autorisations excessives (comme lire, lister, écrire ou supprimer), ou via de larges étendues d'accès permettant aux utilisateurs d'accéder au stockage adjacent. conteneurs. ### Les jetons SAS Hygiène ont un problème d'expiration : nos analyses et notre surveillance montrent que les organisations utilisent souvent des jetons avec une durée de vie très longue (parfois infinie), car il n'y a pas de limite supérieure pour l'expiration d'un jeton. C'était le cas du token de Microsoft, valable jusqu'en 2051. ### Gestion et surveillance Les tokens SAS de compte sont extrêmement difficiles à gérer et à révoquer. Il n’existe aucun moyen officiel de suivre ces jetons dans Azure, ni de surveiller leur émission, ce qui rend difficile de savoir combien de jetons ont été émis et sont activement utilisés. La raison pour laquelle même l’émission ne peut pas être suivie est que les jetons SAS sont créés côté client. Il ne s’agit donc pas d’une activité suivie par Azure et le jeton généré n’est pas un objet Azure. Pour cette raison, même ce qui semble être un compte de stockage privé peut potentiellement être largement exposé. Quant à la révocation, il n'existe aucun moyen de révoquer un seul compte SAS ; la seule solution consiste à révoquer l'intégralité de la clé de compte, ce qui invalide également tous les autres jetons émis avec la même clé. La surveillance de l'utilisation des jetons SAS constitue un autre défi, car elle nécessite d'activer la journalisation sur chaque compte de stockage séparément. Cela peut également être coûteux, car le prix dépend du volume de demandes de chaque compte de stockage. Recommandations de sécurité SAS --------------------------------- La sécurité SAS peut être considérablement améliorée grâce aux recommandations suivantes . ### Gestion En raison du manque de sécurité et de gouvernance des jetons Account SAS, ils doivent être considérés comme aussi sensibles que la clé du compte elle-même. Par conséquent, il est fortement recommandé d’éviter d’utiliser le compte SAS pour le partage externe. Les erreurs de création de jetons peuvent facilement passer inaperçues et exposer des données sensibles. Pour le partage externe, envisagez d'utiliser un Service SAS avec une Politique d'accès stockée. Cette fonctionnalité connecte le jeton SAS à une stratégie côté serveur, offrant la possibilité de gérer les stratégies et de les révoquer de manière centralisée. Si vous devez partager du contenu de manière limitée dans le temps, envisagez d'utiliser une Délégation d'utilisateur SAS , puisque leur délai d'expiration est plafonné à 7 jours. Cette fonctionnalité connecte le jeton SAS à la gestion des identités d'Azure Active Directory, offrant ainsi un contrôle et une visibilité sur l'identité du créateur du jeton et de ses utilisateurs. De plus, nous vous recommandons de créer des comptes de stockage dédiés pour le partage externe, afin de garantir que l'impact potentiel d'un jeton trop privilégié est limité aux données externes uniquement. Pour éviter complètement les jetons SAS, les organisations devront désactiver l'accès SAS pour chacun de leurs comptes de stockage. séparément. Nous vous recommandons d'utiliser un CSPM pour suivre et appliquer cela en tant que politique. Une autre solution pour désactiver la création de jetons SAS consiste à bloquer l'accès à la « liste des clés de compte de stockage » opération dans Azure (puisque de nouveaux jetons SAS ne peuvent pas être créés sans la clé), puis rotation des clés de compte actuelles, pour invalider les jetons SAS préexistants. Cette approche permettrait toujours la création d’une SAS de délégation d’utilisateur, car elle s’appuie sur la clé de l’utilisateur au lieu de la clé du compte. ### Surveillance Pour suivre l'utilisation active des jetons SAS, vous devez activer les journaux Storage Analytics pour chacun de vos comptes de stockage. Les journaux résultants contiendront des détails sur l'accès au jeton SAS, y compris la clé de signature et les autorisations attribuées. Cependant, il convient de noter que seuls les jetons activement utilisés apparaîtront dans les journaux et que l'activation de la journalisation entraîne des frais supplémentaires, ce qui peut être coûteux pour les comptes ayant une activité importante. Azure Metrics peut être utilisé pour surveiller l'utilisation des jetons SAS dans les comptes de stockage. Par défaut, Azure enregistre et regroupe les événements du compte de stockage jusqu'à 93 jours. Grâce à Azure Metrics, les utilisateurs peuvent rechercher des demandes authentifiées par SAS, mettant en évidence les comptes de stockage avec l'utilisation de jetons SAS. ### Analyse secrète De plus, nous vous recommandons d'utiliser des outils d'analyse secrète pour détecter les jetons SAS divulgués ou surprivilégiés dans les artefacts et les actifs exposés publiquement, tels que les applications mobiles, les sites Web et les référentiels GitHub, comme on peut le voir dans le cas Microsoft. Pour plus d'informations sur l'analyse des secrets du cloud, veuillez consulter notre récente conférence de la conférence fwd:cloudsec 2023, "Scanning Internet for external cloud expositions". ### Pour les clients Wiz Les clients Wiz peuvent tirer parti des capacités d'analyse secrète de Wiz pour identifier les jetons SAS dans les actifs internes et externes et explorer leurs autorisations. De plus, les clients peuvent utiliser le Wiz CSPM pour suivre les comptes de stockage avec la prise en charge SAS. * Détecter les jetons SAS : utilisez cette [requête](https://app.wiz.io/graph#~(query~(type~(~'SECRET_DATA)~select~true~where~(presignedURL_type~( EQUALS~(~'PresignedURLTypeAzureSASToken)))~relations~(~(type~(~(type~'PERMITS))~facultatif~true~with~(type~(~'STORAGE_ACCOUNT)~select~true))~(type ~(~(type~'INSTANCE_OF~reverse~true))~avec~(type~(~'SECRET_INSTANCE)~select~true~relations~(~(type~(~(type~'CONTAINS~reverse~true)) ~avec~(type~(~'CLOUD_RESOURCE)~select~true)))))))~view~'table~columns~(~(~'0~49)~(~'1~17)~(~ '2~17)~(~'3~17)))) pour faire apparaître tous les jetons SAS dans tous vos environnements cloud surveillés. * Détecter les jetons SAS à privilèges élevés : utilisez le contrôle suivant pour détecter jetons SAS hautement privilégiés situés sur des charges de travail exposées publiquement. * Règle CSPM pour bloquer les jetons SAS : utilisez la [règle de configuration cloud](https://app.wiz.io/graph#~(query~(type~(~'STORAGE_ACCOUNT)~select~true~ relations~(~(type~(~(type~'ALERTED_ON~reverse~true))~avec~(type~(~'CONFIGURATION_FINDING)~select~true~where~(configurationRuleShortName~(EQUALS~(~'StorageAccount-026 )))))~(type~(~(type~'CONTAINS~reverse~true))~facultatif~true~with~(type~(~'SUBSCRIPTION)~select~true)))))) pour suivre le stockage comptes permettant l'utilisation du jeton SAS. Risques de sécurité dans le pipeline de l'IA ---------------------------------------------------- Alors que les entreprises adoptent Dans l’IA de manière plus générale, il est important que les équipes de sécurité comprennent les risques de sécurité inhérents à chaque étape du processus de développement de l’IA. L'incident détaillé dans ce blog est un exemple de deux de ces risques. Le premier est le partage excessif des données. Les chercheurs collectent et partagent d’énormes quantités de données externes et internes pour construire les informations de formation requises pour leurs modèles d’IA. Cela pose des risques de sécurité inhérents liés au partage de données à grande échelle. Il est crucial que les équipes de sécurité définissent des directives claires pour le partage externe des ensembles de données d’IA. Comme nous l’avons vu dans ce cas, séparer l’ensemble des données publiques de l’IA sur un compte de stockage dédié aurait pu limiter l’exposition. Le deuxième est le risque d’attaques de la chaîne d’approvisionnement. En raison d'autorisations inappropriées, le jeton public a accordé un accès en écriture au compte de stockage contenant les modèles IA. Comme indiqué ci-dessus, l’injection de code malveillant dans les fichiers de modèles aurait pu conduire à une attaque de la chaîne d’approvisionnement contre d’autres chercheurs qui utilisent les modèles du référentiel. Les équipes de sécurité doivent examiner et nettoyer les modèles d’IA provenant de sources externes, car ils peuvent être utilisés comme vecteur d’exécution de code à distance. À retenir --------------- La simple étape de partage d'un ensemble de données d'IA a conduit à une fuite de données majeure, contenant plus de 38 To de données privées. La cause première était l’utilisation de jetons Account SAS comme mécanisme de partage. En raison d'un manque de surveillance et de gouvernance, les jetons SAS présentent un risque de sécurité et leur utilisation doit être aussi limitée que possible. Ces jetons sont très difficiles à suivre, car Microsoft ne propose pas de moyen centralisé pour les gérer au sein du portail Azure. De plus, ces jetons peuvent être configurés pour durer indéfiniment, sans limite supérieure quant à leur durée d’expiration. Par conséquent, l’utilisation de jetons Account SAS pour le partage externe n’est pas sûre et doit être évitée. Dans une perspective plus large, des incidents similaires peuvent être évités en accordant aux équipes de sécurité plus de visibilité sur les processus des équipes de recherche et développement en IA. Alors que nous constatons une adoption plus large des modèles d'IA au sein des entreprises, il est important de sensibiliser aux risques de sécurité pertinents à chaque étape du processus de développement de l'IA et de s'assurer que l'équipe de sécurité travaille en étroite collaboration avec les équipes de science des données et de recherche pour garantir que les garde-fous appropriés sont définis. . Le compte rendu de Microsoft sur ce problème est disponible sur le [blog MSRC](https://msrc.microsoft.com/blog/2023/09/microsoft-mitigated-exposure-of-internal-information-in-a-storage-account- en raison d'un jeton SAS trop permissif/). Chronologie ------------- * Juil. 20 2020 – Jeton SAS en premier engagé vers GitHub ; expiration fixée au 5 octobre 2021 * Oct. 6 octobre 2021 – Expiration du jeton SAS mise à jour jusqu'au 6 octobre 2051 * ** juin. 22 janvier 2023** – Wiz Research découvre et signale un problème au MSRC * ** juin. 24 juillet 2023** – Jeton SAS invalidé par Microsoft * Juillet. 7 novembre 2023 – Jeton SAS remplacé sur GitHub * Août 7 : 16 septembre 2023 – Microsoft termine son enquête interne sur l'impact potentiel * Sep. 18, 2023 – Divulgation publique **Restez en contact ! ** ------------------- Salut! Nous sommes Hillai Ben-Sasson (@hillai](https://twitter.com/hillai)), Shir Tamari (@@shirtamari), Nir Ohfeld (@@nirohfeld ), Sagi Tzadik (@sagitz_) et Ronen Shustin ([@ronenshh](https://twitter. com/ronenshh)) de l’équipe de recherche Wiz. Nous sommes un groupe de hackers chevronnés avec un seul objectif : faire du cloud un endroit plus sûr pour tous. Nous nous concentrons principalement sur la recherche de nouveaux vecteurs d’attaque dans le cloud et sur les problèmes d’isolation chez les fournisseurs de cloud. Nous serions ravis d'avoir de vos nouvelles ! N'hésitez pas à nous contacter sur Twitter ou par e-mail : research@wiz.io.