The Microsoft division that deals with research on the subject of artificial intelligence, mistakenly leaked 38 TB of confidential data belonging to the Redmond company online. L’accident it came to light in recent days, after the publication of a detailed technical analysis developed by Wiz researchers. However, Microsoft accidentally exposed the 38 TB of confidential data not exactly from “yesterday” but at least from July 2020.
Microsoft confirmed the problem with an official note specifying that an employee of its AI division accidentally posted, in a repository GitHub to which it was contributing, the URL of an Azure blob container that should have remained private.
L’URL in question contained a token Shared Access Signature (SAS) excessively permissive that offered full access to the contents of an internal Microsoft storage account. Wiz security researchers were able to use this token to access information and examine the data contained in the Azure blob.
The exposed data included backups of workstation profiles of two former employees of Satya Nadella’s company and the private messages exchanged through Teams with colleagues.
What are SAS tokens and why it is good to use them carefully
The highlighted problem highlights how errors can happen to anyone: a lack of attention to the ways in which data is shared can have, in certain cases, dramatic consequences.
I token SAS provide a mechanism to restrict access and allow certain clients to connect to specific resources hosted on Azure Storage. In this case, a Microsoft researcher unintentionally included this SAS token in an Azure blob container URL. There is therefore none vulnerability inherent on the Azure platform and no action is required from Microsoft users.
If anything, the incident highlights the importance of create and manage tokens SAS correctly. Wiz researchers, who made the discovery, note that SAS tokens – if used correctly – offer a secure means of granting access to resources available in a cloud storage account. It is in fact possible to specify the resources with which users can interact and define them permissions relating to these resources, resulting in the expiration of the SAS token.
However, again according to Wiz, SAS tokens are poorly monitored and are complex to monitor. For this reason they can represent a security risk and their use should be as limited as possible. In fact, Microsoft currently provides no centralized method for managing SAS tokens within the Azure portal.
Additionally, SAS tokens can be configured with a duration indefinite: this means that they may not have any expiry.
Microsoft recommendations for using SAS tokens on Azure Storage
When you decide to use some URL SAS, Microsoft recommends paying maximum attention to a series of crucial aspects. Suggestions which, evidently, were not carefully applied by the former employee of the Redmond company:
- Apply the principle of least privilege: Limit SAS URLs to the smallest set of resources that clients should be able to access (for example, a single blob). Limit the permissions to those strictly necessary for the application (for example, read only or write only).
- Use Short-term SAS: Always set a short-term deadline when creating a SAS token and have clients request new SAS URLs when needed. Azure Storage recommends one hour or less for all SAS URLs.
- Handle carefully SAS tokens: SAS URLs grant access to data and should be treated like any other “secret” that should be carefully guarded. SAS tokens should only be exposed to clients that need access to a storage account.
- Having a revocation plan: Associate SAS tokens with a Stored Access Policy for revocation. If necessary, you must be able to remove the Stored Access Policy and rotate the storage account keys.
- Monitor the application: It is advisable to keep track of the management of authorization requests by enabling Azure Monitor e Azure Storage Logs.
Opening image credit: iStock.com/da-kuk
