Small mistakes with a disastrous consequence: security misconfigurations are low hanging fruit for the dark side.

Despite efforts to create robust systems, hidden weaknesses within those may still exist and make them vulnerable causing severe cyber security threats. This issue became evident in December 2019, when the content of 250 million Microsoft user files became accessible online as a result of misconfigured security settings.

Security misconfiguration – the low hanging fruit on both sides

Researchers detected the data breach on December 29, a day after BinaryEdge’s search engine indexed some Microsoft customer details, leaking user data online to the public. Bob Diachenko’s team at Comparitech discovered that five Elasticsearch servers contained the same catalogue of 250 million user files, accessible without any authentication or authorization. After receiving the notification, Microsoft swiftly responded by correcting the system breach and securing the exposed information by fixing the security misconfiguration.

Before Comparitech’s alert and before adequately securing its files, Microsoft exposed the records in question for about 48 hours. After receiving the warning, they corrected the configuration settings on December 31, restricting further unauthorized access to the database. According to Microsoft cyber security team, the root cause of the problem was an internal database with misconfigured security that they used for support case analytics. This database disclosed the records to their own commercial cloud services.

Diachenko praised the professionalism of Microsoft’s cyber security team incident response unit for their “responsiveness and having a quick turnaround on this despite New Year’s Eve”. As a result, they closed (back) the public access to this data in less than 24 hours.

Personally Identifiable Information (or not)

The data, which covered a fourteen-year period from 2005 to 2019, included clients’ online chat records with Microsoft’s customer support team. According to Microsoft cyber security team, sensitive customer data was deleted from the customer service records before transferring them to its serves, however, some personally identifiable information (PII) like email and IP addresses were still easily detectable, among other items such as:

• Customer email addresses
• IP addresses
• Locations
• Descriptions of CSS claims and cases
• Microsoft support agent emails
• Case numbers, resolutions, and remarks
• Internal notes marked as “confidential”

Later, Microsoft established that most of the leaked records actually did not contain individual customer information, in compliance with the company’s standard procedures. Which is good.

However, whilst they indeed removed most personal information from the documents in time, some data was left unaffected, as it did not meet particular conditions used when cleaning up. Typically, the clean-up did not remove any information presented in an unconventional layout, such as an email address separated with spaces instead of written in a standard format (for example, “XYZ @contoso.com” instead of “XYZ@contoso.com”). A typical issue with blacklists…

From conjuncture of vulnerabilities to incidents

For real-life incidents we typically need the co-existence of several weakness – just as it happened in this case: a mistake in the clean-up, plus a security misconfiguration of the access control.

Not surprisingly, Security Misconfiguration has been on the OWASP Top Ten for long, and it’s the A6 element of the 2017 list. Issues arise frequently as cyber security professionals create firewall controls which inspect and oversee a great number of access requests, from various users and from different locations. According to Microsoft in connection with this specific breach, “Misconfigurations are unfortunately a common error across the industry. We have solutions to help prevent this kind of mistake, but unfortunately, they were not enabled for this database. As we’ve learned, it is good to periodically review your own configurations and ensure you are taking advantage of all protections available.”

By looking at this incident from the Sensitive Data Exposure (A3) perspective, the original intent of cleaning up the database from PII was correct. However, Microsoft have overseen some important details. A weakness slipped through, which may have gone undetected for good, if the data would not leak out due to misconfigured security.

Finally, such stories always trigger the same question in companies and professionals: “Are we ready to prevent similar cyber security incidents to occur in our own systems?”. We have to accept that mistakes are unavoidable. Thus, we should ensure cyber resilience on a higher level as well, establishing processes for continuous reviews of all features, checking if all security controls perform as expected.

Not trivial, but certainly viable.

We cover misconfiguration issues as part of the OWASP Top 10 in all of training courses, such as Web application security, with some other courses offering more specific best practices on avoiding misconfiguration problems in various commonly used components such as Flask, Tomcat, ASP.NET Core, and IIS. Of course misconfiguration can happen on the cloud level as well; if, for instance, you are working with Azure, Cloud application security in C# for Azure contains the typical mistakes to avoid and best practices to follow to make sure you don’t run into the same problems Microsoft did!