This is a story of a backdoor planted in the IT supply chain.
On December 17, 2020, the US Cybersecurity and Infrastructure Security Agency (CISA) released a sobering alert on the SolarWinds attack, noting that CISA had evidence of additional access vectors other than the SolarWinds Orion platform.
CISA’s advisory specifically noted that one of the principal ways the adversary is accomplishing this objective is by compromising the Security Assertion Markup Language (SAML, see my post here) signing certificate using their escalated Active Directory privileges. Once this is accomplished, the adversary creates unauthorised but valid tokens and presents them to services that trust SAML tokens from the environment. These tokens can then be used to access resources in hosted environments, such as email, for data exfiltration via ‘authorised’ APIs.
The malware used in the original attack, codenamed Sunburst (or Solorigate), was delivered to SolarWinds customers as a boobytrapped update for the network monitoring tool Orion. Hackers had managed to alter the versions of Orion that the company released between March and June.
On infected networks, the malware would ping its creators and then download a second stage-phase backdoor trojan named Teardrop that allowed attackers to start a hands-on-keyboard session, also known as a human-operated attack.
Microsoft, FireEye were customers of Solarwinds and were hit and both made a very detailed analysis of the two-stage attack. They concluded that the hackers first compromised SolarWinds’ Orion update mechanism so that its systems could distribute tainted software to thousands of organisations. The attackers could then use manipulated Orion software as a backdoor into victims’ networks. From there, they could fan out within target systems, often by stealing administrative access tokens. Finally, with the keys to the kingdom the hackers were free to conduct reconnaissance and exfiltrate data.
This sort of so-called supply chain attack can have dire consequences. By compromising one entity or manufacturer, hackers can undermine target security efficiently and at scale.
SolarWinds has hundreds of thousands of clients in all; it said in a Securities and Exchange Commission disclosure that as many as 18,000 of them were potentially vulnerable to the attack.
FireEye remedy
FireEye has already taken measures of its own to block the actual malware that took advantage of the SolarWinds Orion flaw. FireEye decoded the Sunburst malware and was able to find a kill switch. Working with GoDaddy and Microsoft, FireEye used the kill switch to deactivate and disable new and previous Sunburst infections and deployments.
However, FireEye acknowledged that the attackers have been able to set up other means to access the networks of victims beyond the Sunburst backdoor. As such, the kill switch won’t remove the culprits from such networks but will make it harder for them to leverage previously distributed versions of Sunburst.
Lessons Learned
Attacks like SolarWinds is an all-hands-on-deck event that requires every organisation to prove it is safe. Much like WannaCry or NotPetya (see my post here), the attack on SolarWinds ended on a mass scale. In fact, even if the adversaries may have targeted only a few public agencies, the collateral damage is experienced at tens of thousands more places.
And do not assume that you are safe if you don’t have a Solarwinds product; this is what supply chain attacks do, they move fast and they move far. And as attacks grow in sophistication, likely aided/funded/directed by nation-states, attackers are recognising that patience is a major asset. Indirect supply chain attacks are very difficult to detect in part because the attackers have traded off their control and time for increases in success-rates. Due to the collateral damage of nation-state directed attacks, every organisation today has to assume to be under attack, as a fact of life and not just a risk.
Attacks are shifting to SDLC infrastructure
As an industry, we’ve assumed that a binary signed using a valid certificate is safe. For many years it was but clearly we can no longer make that assumption. Attackers tend to go after the weakest link, which creates a natural evolution of which types of attacks are most common.
In the pre-cloud days the weak point was often the network. However, Amazon AWS, Google Cloud and Microsoft Azure have done a good job protecting the network so the weak point has now become the applications themselves. As organisations shift their development efforts left, and embrace DevSecOps (evolved from DevOps), application security is improving, and the applications we build are more secure.
This shifts the weakest link again. Indeed, the integrity of SolarWinds’ development pipeline was probably compromised such that attackers could tamper with SolarWinds’ code undetected. The development infrastructure itself, with its code repositories, CI/CD systems, Infrastructure-as-Code and open source libraries, has become the new weakest link.
Hardcoded secrets still exist
Another example of the presumption of security creating weak links is the explosion of hard-coded secrets in source code. Indeed, this has probably played a major role in the SolarWinds breach, too.
Changes in the SDLC, such as the adoptions of cloud-computing, microservices architectures, and APIs, rapidly increased the need to handle API security. But rather than using access tokens, we still see symmetric secrets be used and stored in code. Developers believed this was secure because only insiders had access to source code. However, at the same time, enterprises embraced open-sourcing some of their own code, which increased the complexity of managing repositories. These two trends combined to create a dangerous security situation in which many organisations have accidentally exposed legitimate credentials in publicly accessible repositories.
Steps to take
1. Enforce multi-factor authentication for developers and admins. Enforce least privilege policies across the entire process.
2. Harden your infrastructure access controls. First, inventory your infrastructure assets. Ensure all of your pipeline services are not publicly accessible. Audit all systems to remove default credentials.
3. Search public repositories for your organization’s proprietary code. Search your own repositories for hard-coded secrets.
4. Adopt integrity checks to confirm that the output of each phase of the SDLC is as expected in the next. Ensure that source code files cannot be tampered with in production.
5. Adopt commit signing practices to ensure that code can always be traced back to when it was merged and who wrote it.
Controlled AI services 