Un compte de stockage Azure déréglé met en péril la propriété intellectuelle des développeurs de logiciels.

Un certain mystère entoure la provenance d’une cache de données de code source confidentiel récemment découverte et laissée sur un compte de stockage Azure. exposé et accessible dans un système mal configuré Microsoft Azure Compte de stockage en nuage Blob.

Les données semblent provenir d’une série de lancers effectués auprès de Microsoft Dynamics par diverses entreprises, et beaucoup d’entre eux comprennent le code source de produits qui ont été publiés par la suite. L’ensemble complet de données contient 63 Go de données réparties dans près de 4 000 fichiers distincts. Outre le code propriétaire, il comprend des présentations commerciales, des descriptions de produits et des mots de passe codés en dur.

Il a été trouvé par vpnMentor dirigée par Noam Rotem en janvier 2021, mais après de multiples tentatives de divulgation responsable, l’équipe n’a pu que faire l’hypothèse très provisoire que l’exposition provient de l’intérieur même de Microsoft.

“Chacune de ces entreprises – y compris certaines entreprises bien connues – a été exposée, avec des données internes très sensibles sur leurs opérations et leurs lignes de produits accessibles au public”, a déclaré Rotem. dans un blogue de divulgation publié aujourd’hui.

“Après une première enquête, nous avons identifié deux propriétaires potentiels, en commençant par la société de conseil canadienne. Adoxio. Comme KPMG est maintenant propriétaire d’Adoxio, nous avons contacté KPMG pour l’informer de la violation. KPMG a répondu, confirmant qu’il ne possédait pas les données, et a suggéré qu’elles appartenaient à Microsoft.

“Nous avons également soupçonné Microsoft d’être responsable. Nous avons donc contacté l’entreprise à plusieurs reprises pour nous assurer que les fichiers étaient sécurisés et pour confirmer que les données leur appartenaient. Bien que nous n’ayons reçu que des réponses automatisées de la part de l’entreprise, le compte Azure Blob a été sécurisé dans l’intervalle.”

Rotem ajoute : “Plus de deux mois après avoir initialement découvert la vulnérabilité, nous avons finalement reçu une réponse de Microsoft. Cependant, l’entreprise semble avoir confondu la divulgation de la violation de données avec la divulgation d’une faille dans son logiciel. Dans sa réponse, Microsoft n’a pas reconnu la violation de données et n’a pas revendiqué sa responsabilité. Par conséquent, nous n’avons aucun moyen de vérifier si le fichier appartient à Microsoft.”

Bien qu’elle soit désormais sécurisée, l’exposition des données est importante car si un acteur malveillant obtenait le code source, il lui serait beaucoup plus facile de trouver des vulnérabilités dans un produit ou une base de données et de les manipuler pour accéder à des données plus sensibles détenues par les utilisateurs ciblés – en contournant les protocoles normaux de sécurité des données.

Ils pourraient ensuite exfiltrer d’autres données, voire prendre le contrôle à distance des systèmes exécutant le code, ce qui leur permettrait d’établir une persistance au sein de leur réseau cible et de mener d’autres attaques, notamment des rançongiciels.

Les données du code source peuvent également être transmises à des concurrents, ce qui expose les entreprises qui les ont initialement développées à un risque d’espionnage industriel.

Rotem a déclaré que le propriétaire du compte Azure Blob aurait facilement pu éviter l’incident en sécurisant ses serveurs, en mettant en place des règles d’accès et en ne laissant pas les systèmes qui ne nécessitent pas d’authentification ouverts à Internet. Comme pour d’autres produits de stockage en nuage, tels que AWS S3, les blobs Azure ne sont pas accessibles au public par défaut, et Microsoft fournit des recommandations détaillées et des instructions sur la manière de le faire.