UPDATED October 21: SOCRadar says BlueBleed Microsoft data breach incident exposed “six large cloud buckets that consist of sensitive data belonging to 150,000 companies in 123 countries”. Microsoft disputed that number and said it was due to duplications but declined to give SOCRadar an alternative figure. SOCRadar has pulled down its search tool that allowed customers to see if they were exposed under pressure from Microsoft.
A misconfigured Microsoft endpoint (an Azure storage bucket) exposed 2.4TB of Microsoft customer information, including emails and signed documents, the company has admitted. Strikingly the company’s support staff appear to be telling customers that Microsoft has no GDPR obligations to report it to regulators.
Microsoft declined to comment on that latter claim when contacted by The Stack.
Microsoft has criticised security firm SOCRadar for “exaggerating” the extent of the data leak and for making a search tool that allows organisations to see if their data was exposed. According to the security firm the leak, dubbed “BlueBleed I”, covers data from 65,000 “entities” in 111 countries, from between 2017 and August 2022.
Turkey-based SOCRadar found the open Azure bucket on 24 September, and – after apparently copying the data – reported its findings to Microsoft the same day. Microsoft shut down public access within hours, and notified customers in the subsequent weeks but many say such notifications have been inadequate.
Microsoft data breach BlueBleed: Redmond “disappointed”
Microsoft said in its blog on the leak that its “misconfiguration resulted in the potential for unauthenticated access to some business transaction data corresponding to interactions between Microsoft and prospective customers, such as the planning or potential implementation and provisioning of Microsoft services.”
One German customer affected by the leak posted Microsoft’s communication on Twitter on 5 October.
The letter says a “legacy endpoint was found to be accessible to the Internet which contained business transaction data between your organization, Microsoft or an authorized Microsoft partner”.
“Affected data types that may have been involved included names, email addresses, company name, address, or phone numbers. We are unable to provide the specific affected data from this issue,” the letter continues.
But according to SOCRadar, the exposed data is much more extensive, and includes invoices, purchase orders and signed documents. And while Redmond has declined to provide details of exactly what data was exposed, the security firm has created a dedicated search tool to allow organisations to see if they are affected.
In a blog post on 19 October, Microsoft made its first public announcement about the leak, admitting it was down to a misconfigured endpoint – but also made clear its displeasure at SOCRadar’s actions.
“We take this issue very seriously and are disappointed that SOCRadar exaggerated the numbers involved in this issue even after we highlighted their error,” said the post, claiming much of the data was duplicated.
“More importantly, we are disappointed that SOCRadar has chosen to release publicly a ‘search tool’ that is not in the best interest of ensuring customer privacy or security and potentially exposing them to unnecessary risk. We recommend that any security company that wants to provide a similar tool follow basic measures to enable data protection and privacy,” the blog post continued, detailing steps such as verifying users and minimising data to be disclosed.
When a user searches the BlueBleed breach via SOCRadar, the only information initially disclosed is whether a particular term is or is not included in the data. To get more details, the user must sign up to SOCRadar’s free service – while The Stack has not attempted to sign up, this does appear to include a manual verification step. Microsoft had raised concerns that this search engine potentially exposed customers even more. Whilst SOCRadar insists it only exposes metadata, rather than full documents, it has now pulled it down under apparent pressure from Microsoft.
But whether or not the security firm’s search tool is itself a source of risk, the company’s approach – which includes pushing marketing messages to registered users – led to several users describing SOCRadar as “ambulance-chasers”.
Others, such as security researcher Kevin Beaumont, were more concerned that Microsoft appeared to be focused on SOCRadar’s actions than on how the data leak could affect customers. He also noted the Azure buckets had been listed on the GrayhatWarfare database of open cloud storage instances and potentially accessed by others.
In its blog post Microsoft said all affected customers would be contacted via Microsoft 365 Message Center. But as not all organisations use Message Center, and the communication Microsoft has made through it seems to be less than forthright in describing the extent of the affected data, it is entirely possible that many organisations remain in the dark about their potential exposure. SOCRadar claims this disclosure is the first – and largest – of six publicly-accessible buckets it discovered. Across all six the firm claims data from 150,000 entities was accessible.
Redmond added in its blog on the incident: “The issue was caused by an unintentional misconfiguration on an endpoint that is not in use across the Microsoft ecosystem and was not the result of a security vulnerability. We are working to improve our processes to further prevent this type of misconfiguration and performing additional due diligence to investigate and ensure the security of all Microsoft endpoints.”
Microsoft declined to comment when reached by The Stack on its GDPR obligations.
“An Information Commissioner’s Office (ICO) spokesperson told us: “We do not appear to have received an incident report from Microsoft on this matter. For awareness, not all breaches need to be reported to us. Organisations must however notify the ICO within 72 hours of becoming aware of a personal data breach, unless it does not pose a risk to people’s rights and freedoms.If an organisation decides that a breach doesn’t need to be reported they should keep their own record of it, and be able to explain why it wasn’t reported if necessary.”