An overly permissive file-sharing link allowed public access to a massive 38TB storage bucket containing private Microsoft data, leaving a variety of development secrets — including passwords, Teams messages, and files from two employees’ workstations — accessible to attackers.
Cloud data-security firm Wiz issued an advisory on the incident, which it said originated in the use of a Microsoft Azure feature known as a Shared Access Signature (SAS) token, which allows users with a link to access an otherwise private data repository. The specific at-risk repository belonged to Microsoft’s AI research division, which — in its public GitHub repository — directed users to download open source images and code from the Azure Storage bucket via the SAS link.
However, the link was misconfigured and allowed access to the entire private storage instance, making the sensitive files and data public.
The incident underscores the potential for security missteps when using SAS links, says Ami Luttwak, chief technology officer and co-founder of cloud data-security firm Wiz.
“The AI researcher just wanted to share a database, which is fine, but how do I know if my users — who they want to share something with — mistakenly share our entire storage account,” he says. “They even gave write permission, not just read permissions, so it could have even led to remote execution.”
Over the past five years, the storage services offered by major cloud providers have become a significant target of both researchers and attackers. In 2020, a half-million documents related to a financial app were exposed due to a misconfigured Amazon Web Services S3 bucket. In 2017, two AWS S3 buckets exposed sensitive data on thousands of US veterans and millions of subscribers to Time-Warner cable. Microsoft Azure has not been immune: A security firm discovered last year that data on prospective clients may have been compromised due to a misconfigured cloud storage endpoint.
In the latest incident, Microsoft confirmed the details of the Wiz advisory, noting that the company contacted Microsoft through the coordinated vulnerability disclosure process.
“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,” the Microsoft Security Response Center (MSRC) stated in an advisory. “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.”
Shared Access in Secret
The SAS feature of Azure allows users to grant specific access to specific files and resources in their storage account. The user has fine-grained control over the resources that may be accessed, the permissions the link allows, and how long the SAS token is valid. There are three different types of Shared Access Signatures, including user delegation, service, and account SAS tokens.
However, employees who allow access to resources are not easily monitored, Wiz’s Luttwak says.
“There is no way in Azure to monitor which permissions have been granted because Azure does not know about all of the tokens that were created,” he says. “That means the security teams actually have no way to monitor or do any governance over these tokens. And that’s scary.”
Wiz is not the only company to warn of the dangers of the Azure share-by-link mechanism. Security assessments have often found insecure Azure Storage Accounts, even if a particular client did not have a problem securing their Amazon S3 storage buckets, Tom Ellson, head of offensive security for Jumpsec Labs, stated in an advisory published last year.
“Azure Storage Accounts are the Microsoft equivalent of Amazon S3 buckets, and are susceptible to many of the same challenges,” he stated. “Namely, that — as with other cloud services — they are often deployed by teams without the security know-how to configure them effectively, and that default deployments will often lack the necessary level of controls for their environment unless they are explicitly enabled by the IT team.”
Just Say No?
There are so many pitfalls in setting up SAS tokens that Wiz’s Luttwak recommends against ever using the mechanism to share files from a private cloud storage account. Instead, companies should have a public account from which resources are shared, he says.
“This mechanism is so risky that our recommendation is, first of all, never to share public data, within your storage account — create a completely separate storage account only for public sharing,” Luttwak says. “That will greatly reduce the risk of misconfiguration. You want to share public data, create a public data externally storage account and use only that.”
For those companies that continue to want to share specific files from private storage using SAS URLs, Microsoft has added the capability as part of GitHub’s monitoring of the exposure of credentials and secrets. The company has rescanned all repositories, the company stated in its advisory.
Microsoft recommends that Azure users limit themselves to short-lived SAS tokens, apply the principle of least privilege, and have a revocation plan.
“Like any secret, SAS tokens need to be created and handled appropriately,” Microsoft stated in the advisory. “As always, we highly encourage customers to follow our best practices when using SAS tokens to minimize the risk of unintended access or abuse.”
Source: www.darkreading.com