Des chercheurs en IA de Microsoft ont partagé accidentellement 38 To de données sensibles

[Raccoon]

Par le partage d’un lien vers un seul dossier sur leur dépôt GitHub, des chercheurs de Microsoft ont laissé la possibilité à n’importe qui de fouiller dans les 38 To de fichiers que contenait leur compte Azure.

Selon TechCrunch, des chercheurs de Microsoft ont accidentellement partagé des dizaines de téraoctets de données sensibles, dont des clés privées et des mots de passes sur leur dépôt GitHub.

La startup Wiz, qui travaille sur la sécurité des données dans le cloud, a découvert cette publication accidentelle et l’a partagée avec le média américain.

38 To venant de backup de deux ordinateurs de salariés

TechCrunch explique que le dépôt qui servait au partage de code pour la reconnaissance d’images contenait aussi un lien vers un dossier de stockage Azure permettant de télécharger les modèles d’IA. Wiz s’est rendu compte que le réglage de permissions permettait d’accéder aussi à toutes les données stockées par ce compte Azure.

Celui-ci contenait 38 téraoctets de données sensibles dont les backups personnels de deux ordinateurs de salariés de Microsoft. À l’intérieur, notamment, des mots de passe d’accès à des services Microsoft, des clés privées et plus de 30 000 messages échangés par des centaines d’employés de l’entreprise de Redmond via Teams. Selon le média, ces données étaient accessibles depuis 2020.

Un jeton de signature d’accès partagé en cause

Le réglage de permissions permettait aussi de modifier et supprimer n’importe quelle donnée stockée sur ce compte Azure.

Wiz explique que les chercheurs de Microsoft ont partagé non seulement l’url des données, mais qu’ils y ont aussi inclus le jeton (token) de la signature d’accès partagé (en anglais, Shared Access Signature, SAS). Ces tokens utilisés par Azure permettent de partager les droits sur les données du compte.

Wiz a informé Microsoft le 22 juin et l’entreprise a révoqué le jeton le 24 juin et terminé son enquête sur les potentielles conséquences dans son organisation le 16 août.

Aucune donnée de clients exposée

Microsoft a publié un billet de blog expliquant qu’ « aucune donnée de client n’a été exposée et aucun autre service interne n’a été mis en danger à cause de ce problème ». En conséquence, les clients n’ont besoin de réaliser aucune action.

L’éditeur de la solution de stockage dans le cloud Azure explique que, «  comme les autres secrets, les jetons SAS doivent être créés et gérés correctement », rejetant la faute sur les utilisateurs de son service, en l’occurrence, ici, ses propres salariés. Microsoft ajoute quand même qu’ « en outre, nous apportons des améliorations constantes pour renforcer la fonction de jeton SAS et continuons d’évaluer le service afin de renforcer notre dispositif de sécurité par défaut », sans aller plus loin dans le détail de ces améliorations permettant d’éviter ce genre de partages maladroits.

L’entreprise explique, par contre, avoir étendu le service d’analyse d’informations secrètes (comme les clés chiffrées et les disques durs virtuels) de GitHub, qu’elle a pour rappel racheté en 2018, pour détecter le partage de jeton SAS.

Bonnes pratiques mises en avant par Azure

Dans son billet, Microsoft cite les « bonnes pratiques » recommandées par Azure lors de l’utilisation d’URL SAS :

• Appliquer le principe du moindre privilège : limiter les URL SAS au plus petit ensemble de ressources requises par les clients (par exemple, un seul blob), et limiter les autorisations à celles requises par l’application (par exemple, lecture seule, écriture seule).
• Utiliser des SAS à courte durée de vie : toujours utiliser un délai d’expiration à court terme lors de la création d’un SAS, et demander aux clients de demander de nouvelles URL de SAS si nécessaire. Azure recommande un délai d’une heure ou moins pour toutes les URL SAS.
• Manipuler les jetons SAS avec précaution : les URL SAS donnent accès aux données et doivent être traitées comme un secret d’application. N’exposer les URL SAS qu’aux clients qui ont besoin d’accéder à un compte de stockage.
• Prévoir un plan de révocation : associer les jetons SAS à une politique d’accès stocké pour une révocation fine d’un SAS au sein d’un conteneur. Être prêt à supprimer la politique d’accès stocké ou à effectuer une rotation des clés de compte de stockage en cas de fuite d’un SAS ou d’une clé partagée.
• Surveiller et auditer votre application : suivre la façon dont les demandes d’accès au compte de stockage sont autorisées en activant Azure Monitor et Azure Storage Logs. Utiliser une politique d’expiration des SAS pour détecter les clients qui utilisent des URL SAS de longue durée.

Source : nextinpact.com

[Un Ancien Utilisateur]

Régis le stagiaire à encore merdé

[Raccoon]

Lê de Science4All a fait une vidéo sur le sujet