Last week, on New Year’s Eve, Microsoft announced that the SolarWinds attackers had been deeper in their environment than previously believed and had viewed Microsoft’s source code. While the implication of the blog is that attackers viewing source code is not a big deal, we think there are several reasons not to take this new admission lightly.
Timing & Lack of Detail
On their own, the timing of the post and the lack of detail about what source code was viewed aren’t necessarily a big deal. However, Microsoft has such a wide portfolio of software that the difference between viewing the first generation Zune source code, which really wouldn’t matter much, versus Windows Server 2019 or GitHub, which could be catastrophic, is massive. Hence, it’s reasonable to guess that, if the breached codebase was inconsequential, it would have been mentioned to demonstrate the breach was immaterial. Furthermore, holidays are widely known in the PR community to be days to announce bad news. Both timing and lack of detail suggest Microsoft probably viewed this as bad news, which means we probably should too.
Source Code is Core Intellectual Property
While it may not have a broader impact on security in general, this serves as a good reminder that source code is the core of any software company’s intellectual property. Viewing the source code is akin to learning Kentucky Fried Chicken’s 51 herbs and spices, Bush’s Baked Beans secret family recipe, or the architectural drawings for Lockheed’s F22 Raptor. For a software company, any proprietary source code exposure is a big deal. Whenever exposing source code isn’t a big deal, software companies tend to pursue open source strategies to leverage the many benefits of building communities.
Inner Source is not a Shield
While Microsoft claims:
“At Microsoft, we have an inner source approach – the use of open source software development best practices and an open source-like culture – to making source code viewable within Microsoft.”
Attackers viewing the source code still creates risk in 3 key ways.
Hard-Coded Secrets — Whether usernames/passwords, API Keys, or tokens, modern applications are built as a mesh network of microservices, libraries, APIs, and SDKs that often require authentication to deliver the core service. It’s common for developers to write these secrets directly into the source code on the assumption that only insiders can view them. Best practices are to leverage a secrets manager and to scan commits/pull requests for new secrets before they make the master branch. While Microsoft claims their “threat models assume that attackers have knowledge of source code,” it would be far more reassuring if they directly addressed whether or not the breached code contained secrets.
Reverse Engineering — In much the same way that the source code is a software company’s IP, it is also the blueprint on how to reverse engineer and exploit an application. If I can see your source code, I can trace the routes of inputs to determine which routes have security transforms for appropriate sanitization (validation, redaction, encryption, etc.) before they hit their intended sink/database. Hence, by viewing Microsoft’s source code the attackers now may have an easier time crafting zero-day exploits to compromise Microsoft directly and/or its customers, depending on which codebase was exposed.
Observing & Learning — SolarWinds was exploited by incredibly patient and observant attackers. The attackers took the time to learn SolarWinds’ code structure, naming conventions, and implementation details. Hence, if SolarWinds’ developers looked at the malicious code they would most likely assume this code came from another SolarWinds developer and give it far less scrutiny. External auditors had even less chance of identifying the attacker’s malicious code. The attackers even appear to have tested their malicious code with a benign implant via an empty class that was delivered six months before the real backdoor was distributed to SolarWinds customers. While we might not traditionally consider mundane details such as the code structure, naming conventions, or implementation details of software development to be especially security-relevant, for keeping supply chain attacks undetected, they are vital and should not be written off so easily.
Conclusions
We’re glad to hear that Microsoft hasn’t found evidence of attackers gaining access to production services or customer data. However, exploiting an application fundamentally means making it do something that it was not designed to do. Inherently, it’s difficult to tell when something behaves in an unintended manner precisely because that behavior is unexpected.
We know that Microsoft is one of the most critical and widely deployed software companies in the world. That makes them an incredibly tempting target and we know the SolarWinds attackers are both sophisticated and take the long-term view. We know they maybe have gone undetected inside Microsoft from March 2020 to as late as December 2020. That’s a long time to sit and wait, to observe, to learn, and ultimately to peel more layers of the onion.
It goes without saying that we are rooting for Microsoft. Not only is it the right thing to do, but what other choice do any of us really have? The consequences of a widespread Microsoft supply chain attack could necessitate an internet “shelter in place order.” We hope this is the final chapter of Microsoft’s breach, but we fear it may have been recon for the next bigger operation.
How Cycode Can Help
Crises are a time for the community to come together. As such, Cycode is offering a free code repository security assessment to any organization that is looking to harden their development infrastructure. Alternatively, if there is some other way we can help your organization, please get in touch with us.
Originally published: January 4, 2021
