Contextualizing Microsoft’s Source Code Exposure in the SolarWinds Attacks

In the middle of December, IT management software provider SolarWinds revealed in a security advisory that it had fallen victim to a sophisticated supply chain attack. The offensive involved the placement of a backdoor known as SUNBURST into versions 2019.4 HF 5, 2020.2 with no hotfix installed and 2020.2 HF 1 of the company’s Orion Platform software. If executed, SUNBURST allowed an attacker to compromise the server running the Orion build.

The supply chain attack involving SolarWinds affected a variety of organizations and government entities – one of those victims was Microsoft. In a December 31 blog update, the tech giant revealed that its investigation had found no evidence of unauthorized access to its production services or customer data, but that effort did uncover another attack attempt. As explained by Microsoft on its blog:

We detected unusual activity with a small number of internal accounts and upon review, we discovered one account had been used to view source code in a number of source code repositories. The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated.

Sponsorships Available

Sponsorships Available

Sponsorships Available

The Redmond-based company clarified that it has an “inner source approach” that makes source code viewable within Microsoft. This means that the company’s security doesn’t depend on the secrecy of its source code. Even so, such an attempt raises some important questions about the types of risks that Microsoft might still be facing as a result of this exposure.

I sat down with Sam Curry, chief security officer at Cybereason, to explore this further. Presented below is a transcript of our chat.

David Bisson: Could Microsoft suffer reputational damage from this? What are the risks surrounding the security of the tech giant’s trade secrets?

Sam Curry: “Yes” to the first question. It’s already happened. As to your second question, the issue boils down to what source code was affected. Did the exposure affect Microsoft’s quantum computing IP or some vital logic in Azure perhaps? That’s the company’s risk. It’s for Microsoft to worry about, though it has done well to march right through the reputational risk and get into a dialogue with the public.

DB: Interesting. Regardless of what information the digital attack affected, is there the possibility that malicious actors could leverage Microsoft’s source code to launch a 0-day attack?

SC: Possibly. Does Microsoft have an aggressive, leaning-in approach to application security? Does that mean the company is using secure-by-design, code reviews, architecture reviews, source code analysis, object code analysis and solid practices in post-availability turn around on reported bugs and vulnerability? If the answer is yes, great – it means that the code may not have many undiscovered issues that malicious actors could use to craft a 0-day attack. 

The way to check this is to take the area of affected code’s history and check how many vulnerabilities have appeared historically as well as how they are handled, assuming that the company can verify this. Low rates of new vulnerabilities and rapid response are a good sign, whereas the opposite isn’t good. Also, if the affected code is old, it’s more likely to be known and reliable and to have less landmines. 

Once again, however, the history here matters. Let’s also not forget that with some programming languages and applications types, source may be more or less accessible anyway, (I’m looking at you, Javascript.) so which applications and language are affected is also a factor.

From there, the question becomes the following: How big a body of code did the attack affect? What products and services did the attack reach? How long will it be until the code is essentially completely replaced? Is this a large body of code that isn’t likely to change much? Or is it a relatively small one that will iterate rapidly? The latter things look better, but what code was affected is a non-trivial consideration since some code is re-used and leveraged very widely.

DB: Understood. In the absence of a 0-day attack, is there a possibility that malicious actors could use other patterns in the coding and development styles to extrapolate vulnerabilities and weaknesses elsewhere? 

SC: I think what you’re asking is this: If a developer shows a predilection for certain coding weaknesses or structures, could they be used by a truly advanced attacker to help with the attacker’s R&D? The answer here is that it is highly unlikely. Even so, it’s still in the realm of possibility. This is the concern now of the architects, fellows, executives, security experts and managers at Microsoft. 

The key is to responsibly continue sharing information with the security community for the purpose of protecting customers and users while going through these calculations internally and perhaps even adapting development practices to minimize what an attacker can glean or use from future “viewings.”

At Cybereason, we are all about sharing information with our customer base. That’s why we published a statement discussing how the Cybereason Defense Platform can protect customers against SUNBURST and the SolarWinds attack. You can view the alert here. 

DB: Thanks for sharing. I appreciate the insight.

SC: Glad to help.