Microsoft Data-Exposure Incident Highlights Risk of Cloud Storage Misconfiguration

Cloud storage misconfigurations of the sort that Microsoft disclosed late yesterday continue to be a major contributor to data breaches.

Microsoft Security Response Center said in a post that information shared by prospective clients with the company in recent years potentially may have been compromised via a misconfigured cloud storage endpoint.

SOCRadar, the threat intelligence firm that reported the issue to Microsoft, described discovering the data in an Azure Blob storage bucket that was publicly accessible over the Internet. The data was associated with more than 65,000 companies in 11 countries and included statement-of-work documents, invoices, product orders, project details, signed customer documents, product price lists, personally identifiable information (PII), and potentially intellectual property as well.

Microsoft blamed the issue on an unintentional misconfiguration on an endpoint containing the data, and said SOCRadar “greatly exaggerated the scope of this issue,” with some duplicate data that exaggerated the numbers.

Ongoing Problem

Storage-bucket misconfigurations by other organizations have resulted in numerous data breaches in recent years. A Trend Micro study last year found storage-related configuration errors to be among the most common cloud security issues that lead to data breaches. The analysis showed, for example, that administrators frequently misconfigure a setting in Amazon’s AWS cloud service that allows organizations to block public access to data in their S3 storage buckets. But even with readily available and detailed documentation, administrators often fall short and leave Amazon S3 buckets open and publicly accessible.

The security vendor found the same problem prevalent in Microsoft Azure storage environments as well. The Azure storage account service that contains Azure Storage objects such as blobs, file shares and tables, had a misconfiguration rate of 60.75%, Trend Micro found.

Unsurprisingly, data exposures resulting from misconfigured cloud storage buckets remain commonplace. Many of the publicly known instances have involved data in insecure or poorly configured AWS S3 storage buckets. One recent example is Skyhigh Security’s discovery of some 3TB worth of airport data — more than 1.5 million files — stored in a publicly accessible S3 bucket. The compromised data included PII and sensitive employee and company data associated with at least four airports in Peru and Colombia.

According to third-party risk management vendor UpGuard, there have been thousands of S3-related breaches tied to misconfigured S3 settings in recent years. Incidents involving Azure Blob misconfigurations — though fewer in number — have resulted in major compromises as well. Research that CyberArk conducted last year uncovered millions of files stored online in Azure Blob storage without any access restrictions at all, meaning anyone looking for the data could access it. Many of the files that CyberArk found include personal identifiable information, payment card information, financial information, and other sensitive data.

So Much Data

Meantime, the circumstances surrounding Microsoft’s newly disclosed Azure Blob misconfiguration are not clear, says Claude Mandy, chief evangelist for data security at Symmetry Systems. “A more technical post-incident analysis would be beneficial for the entire industry to take proactive steps to avoid similar issues,” he says.

The information released thus far on the Microsoft incident suggests that either the Azure storage container or the blobs containing the data was configured to allow anonymous public read access to the data — a setting that is not allowed by default. “This configuration drift is unfortunately common. For example, it may result from users with excessive privileges attempting to share specific data with external parties without having the expertise to configure external access securely,” Mandy says.

In addition, it appears that the specific blob storage may have also been used to backup data from other blob storages, resulting in further unattended sharing of data, he adds.

The incident underscores the challenges organizations face from the sheer scale of data being generated and collected these days, and the way it is shared and managed. “This can include simple changes such as people joining and leaving organizations, or the need to use or share data with different parties,” Mandy says. “The impact of the continual change at the most granular data object level can result in unattended and significant consequences but is challenging to manually monitor at scale.”

Andrew Hay, chief operating officer at Lares Consulting, believes the recent incident was likely the result of an oversight by a developer or administrator. “Like AWS S3, users must go out of their way to allow public access to the Azure Storage Blob,” Hay says. “Public read-access to blob data is an optional setting that can be enabled on a container.”

While public read-access can be convenient for sharing data it also entails security risks, he says. Azure allows administrators to disallow public access to data in a storage account, he notes. Any subsequent request for access to blob data then would need to be authorized and anonymous requests would fail, Hay explains.

Microsoft had not responded to a request for additional comment as of this posting.