A member of Microsoft’s AI research division has accidentally leaked 38 terabytes of data via a misconfigured storage bucket.
Researchers from the Cloud security company Wiz.io found the Microsoft employee had shared a URL for the Azure storage bucket in a public GitHub repository whose “purpose is to provide open-source code and AI models for image recognition”.
However, the bucket “was configured to grant permissions on the entire storage account”, not just the open-source models, thereby exposing 38TB of additional data by mistake, including employees’ personal computer backups and over 30,000 Teams messages from 359 Microsoft employees.
No customer data was involved.
The error was caused by the use of an over-permissive SAS or Shared Access Signature token for the storage account. SAS tokens work by allowing you to create shareable links that grant access to Azure Storage data. The access level is determined by the user, with permissions ranging from read-only to full control, and “the scope can either be a single file, a container, or an entire storage account”.
While this provides a useful range of access options, it can mean that if the token is misconfigured, full permissions on an account can be mistakenly granted – as happened in this incident.
Microsoft recommendations
Microsoft explains that “There was no security issue or vulnerability within Azure Storage or the SAS token feature”. However, it was “making ongoing improvements to further harden the SAS token feature and continue to evaluate the service to bolster [its] secure-by-default posture”.
If your organization uses SAS tokens to share URLs, it’s important to take precautions. Azure Storage recommends:
- Applying the principle of least privilege, limiting permissions to those needed by the application and limiting the scope to the smallest set of resources required;
- Using short-lived SAS URLs that have a short expiration time, ideally of one hour or less;
- Handling SAS tokens carefully, and sharing them only with those who need access to the storage account;
- Having a revocation plan so you can withdraw access to the container, either by using a stored access policy or rotating the storage account keys if an SAS token or Shared Key is leaked; and
- Monitoring and auditing your application to track how requests to the storage account are authorized.
Monitoring shared access
These points seem sensible enough precautions. However, Wiz points out that the service lacks suitable monitoring capabilities: when an Account SAS token is generated, the “entire process is done on the client side; it’s not an Azure event, and the resulting token is not an Azure object”.
This means administrators have no way of knowing if the token exists and who has it – so if an attacker manages to issue privileged SAS tokens with a long expiration, they will preserve valid credentials that they can use as a backdoor.
As a recent Microsoft report noted, “The tokens are not monitored by storage accounts, thus they cannot be revoked (except Service SAS) and it’s not easy to determine whether there are valid tokens in the wild until they are used.”
Although in this incident the storage bucket itself was secure, even if the link providing access to it wasn’t, data breaches caused by unsecured or misconfigured storage buckets are relatively commonplace. It’s therefore critical to ensure you store sensitive information and personal data securely, and can maintain its confidentiality, integrity and availability.
