Security researchers at Wiz have identified a major leak of internal data at Microsoft. The breach occurred three years ago in 2020 when an employee shared a URL for a blob store in a public GitHub repository while contributing to open source AI learning models. Wiz reported the data leak to the Microsoft Security Response Center (MSRC) in June, and on Monday, MSRC issued an advisory confirming this was an internal data leak involving no customer data. Microsoft attributed the data leak to the use of “an overly permissive Shared Access Signature (SAS) token for an internal storage account.” The SAS token was used by the researchers at Wiz to access information in the storage account. The account contained 38 terabytes of data, including backups of two employee workstation profiles, passwords for Microsoft services, secret keys, and more than 30,000 internal Microsoft Teams messages between the two employees and their colleagues.
SAS tokens can be used to restrict access to and allow clients to connect to specified Azure Storage resources. These tokens facilitate sharing but they are difficult to track as there is no centralized way of managing them in the Azure portal. When these tokens are created, there may be no upper limit on expiry, which makes the tokens difficult to revoke. These tokens should therefore not be used for external sharing.
Microsoft’s data leak was due to a researcher including a SAS token in a blob store URL and that it is making ongoing improvements to further harden the SAS token feature. Microsoft said the secret scanning service at GitHub monitors all public open-source code changes for plaintext exposure of credentials and other secrets and includes Microsoft-provided SAS detection. This feature flags Azure Storage SAS URLs that point to sensitive content such as VHDs and private cryptographic keys. Microsoft has now expanded detection to include SAS tokens with overly permissive expirations or privileges.
When using SAS tokens, it is important to follow security best practices to minimize the risk of unauthorized access and abuse. That means applying the principle of least privilege and only configuring SAS tokens to allow access to the smallest set of required resources, such as a single blob, and limiting permissions to only those needed by the application. When creating an SAS token, it is important to use a short expiration time, such as 1 hour for SAS URLs. SAS tokens must be handled carefully and there should be a plan for revocation. If the key is leaked, be ready to remove the Stored Access Policy or Rotate Storage Account Keys. Microsoft also recommends monitoring and auditing applications by enabling Azure Monitor and Azure Storage Logs and using an SAS Expiration Policy to detect clients using long-lived SAS URLs.
