Summary
As part of a recent Coordinated Vulnerability Disclosure (CVD) report from Wiz.io, Microsoft investigated and remediated an incident involving a Microsoft employee who shared a URL for a blob store in a public GitHub repository while contributing to open-source AI learning models. This URL included an overly-permissive Shared Access Signature (SAS) token for an internal storage account. Security researchers at Wiz were then able to use this token to access information in the storage account. Data exposed in this storage account included backups of two former employees’ workstation profiles and internal Microsoft Teams messages of these two employees with their colleagues. No customer data was exposed, and no other internal services were put at risk because of this issue. No customer action is required in response to this issue. We are sharing the learnings and best practices below to inform our customers and help them avoid similar incidents in the future.
SAS tokens provide a mechanism to restrict access and allow certain clients to connect to specified Azure Storage resources. In this case, a researcher at Microsoft inadvertently included this SAS token in a blob store URL while contributing to open-source AI learning models and provided the URL in a public GitHub repository. There was no security issue or vulnerability within Azure Storage or the SAS token feature. Like other secrets, SAS tokens should be created and managed properly. Additionally, we are making ongoing improvements to further harden the SAS token feature and continue to evaluate the service to bolster our secure-by-default posture.
After identifying the exposure, Wiz reported the issue to the Microsoft Security Response Center (MSRC) on June 22nd, 2023. Once notified, MSRC worked with the relevant research and engineering teams to revoke the SAS token and prevent all external access to the storage account, mitigating the issue on June 24th, 2023. Additional investigation then took place to understand any potential impact to our customers and/or business continuity. Our investigation concluded that there was no risk to customers as a result of this exposure.
Improving detections for future cases
GitHub’s secret scanning service monitors all public open-source code changes for plaintext exposure of credentials and other secrets. This service runs a SAS detection, provided by Microsoft, that flags Azure Storage SAS URLs pointing to sensitive content, such as VHDs and private cryptographic keys. Microsoft has expanded this detection to include any SAS token that may have overly-permissive expirations or privileges.
Microsoft additionally performs complete historical rescans of all public repositories in Microsoft-owned or affiliated organizations and accounts. This system detected the specific SAS URL identified by Wiz in the ‘robust-models-transfer’ repo, but the finding was incorrectly marked as a false positive. The root cause issue for this has been fixed and the system is now confirmed to be detecting and properly reporting on all over-provisioned SAS tokens.
Understanding SAS tokens, best practices, and preventing abuse
Shared Access Signatures (SAS) provides a secure mechanism to delegate access to data within a storage account. Unlike Shared Key, which has full access to an entire storage account, SAS provides granular control for how clients can access your data. When used correctly, SAS can improve both the security and performance of storage applications.
For example, a SAS token can be used to restrict:
- What resources a client can access (specific container, directory, blob, or blob version)
- What operations a client can perform (read, write, list, delete)
- What network a client can access from (HTTPS, IP address)
- How long a client has access (start time, end time)
Like any key-based authentication mechanism, a SAS can be revoked at any time by rotating the parent key. In addition, SAS supports fine-grained revocation at the container level, without having to rotate storage account keys.
Just like any secret, SAS tokens need to be created and handled appropriately.
Azure Storage recommends the following Best Practices when working with SAS URLs:
- Apply the Principle of Least Privilege: Scope SAS URLs to the smallest set of resources required by clients (e.g. a single blob), and limit permissions to only those needed by the application (e.g. read-only, write-only).
- Use Short-Lived SAS: Always use a near-term expiration time when creating a SAS, and have clients request new SAS URLs when needed. Azure Storage recommends 1 hour or less for all SAS URLs.
- Handle SAS Tokens Carefully: SAS URLs grant access to your data and should be treated as an application secret. Only expose SAS URLs to clients who need access to a storage account.
- Have a Revocation Plan: Associate SAS tokens with a Stored Access Policy for fine-grained revocation of a SAS within a Container. Be ready to remove the Stored Access Policy or Rotate Storage Account Keys if a SAS or Shared Key is leaked.
- Monitor and Audit Your Application: Track how requests to your storage account are authorized by enabling Azure Monitor and Azure Storage Logs. Use a SAS Expiration Policy to detect clients using long-lived SAS URLs.
Azure Storage is committed to helping customers safeguard their data assets and will continue to make ongoing improvements to encode these best practices in the default settings for storage accounts.
For more information, please see our best practices for using SAS tokens and security recommendations for blob storage.
Conclusion
To reiterate, the information that was exposed consisted of information unique to two former Microsoft employees and these former employees’ workstations. No customer data was exposed, and no other Microsoft services were put at risk because of this issue. Customers do not need to take any additional action to remain secure.
Like any secret, SAS tokens need to be created and handled appropriately. As always, we highly encourage customers to follow our best practices when using SAS tokens to minimize the risk of unintended access or abuse. Microsoft is also making ongoing improvements to our detections and scanning toolset to proactively identify such cases of over-provisioned SAS URLs and bolster our secure-by-default posture.
We appreciate the opportunity to investigate the findings reported by Wiz.io. We encourage all researchers to work with vendors under Coordinated Vulnerability Disclosure (CVD) and abide by the rules of engagement for penetration testing to avoid impacting customer data while conducting security research. Researchers who report security issues to the Microsoft Security Response Center are also eligible to participate in Microsoft’s Bug Bounty Program.
Microsoft follows CVD, which systematically and responsibly manages the discovery, reporting, and remediation of security vulnerabilities. CVD allows us to collaborate with researchers and the wider security community in a way that prioritizes user security and system integrity. By following a coordinated approach, we can work with researchers to ensure that potential vulnerabilities are addressed before they’re made public, reducing the risk of exploitation.