Why the SolarWinds Attack Worked…
When Brad Smith, Microsoft’s President, talks about the SolarWinds attack he certainly doesn’t sugarcoat what is now known as the months-long hacking campaign that affected US government agencies and cybersecurity vendors: “I think from a software engineering perspective, it’s probably fair to say that this is the largest and most sophisticated attack the world has ever seen…”
The attack, disclosed by security firm FireEye and Microsoft in December 2020, may have impacted as many as 18,000 organizations as a result of the Sunburst (or Solorigate) malware planted inside SolarWinds’ Orion network management software.
Let’s take a look at why the SolarWinds attacked actually worked.
The SolarWinds attack and FireEye attacks demonstrated 3 distinct vulnerabilities across multiple organizations.
Vulnerability #1: It was a “supply chain” attack.
The criminals gained access to the SolarWinds development process and injected malware. By compromising at the source, their payload was digitally signed and trusted by Solarwinds customers. This code was then shipped by SolarWinds as a software update and installed on thousands of systems. As soon as the software was launched, the attackers had access to the “core” network by establishing a Command and Control (C2) channel, allowing a launching point for many other types of attacks.
FireEye discovered the SolarWinds hack in their own network by seeing some anomalous activity, sparking the massive investigation and mitigation effort. Once the bad guys were inside the network, they began to look for other points of compromise.
Vulnerability #2: They were attacks against single sign-on (SSO) systems
These systems allow organizations to protect many systems with one username and password. This blog post from Microsoft sums up nicely:
“Once in the network, the intruder then uses the administrative permissions acquired through the on-premises compromise to gain access to the organization’s global administrator account and/or trusted SAML token signing certificate.”
“Anomalous logins using the SAML tokens […] can then be made against any on-premises resources (regardless of identity system or vendor) as well as to any cloud environment (regardless of vendor) because they have been configured to trust the certificate. “
This exposure (often referred to as “Golden SAML”) demonstrates the balance cybersecurity professionals must weigh between security and convenience. SSO systems make users’ lives easier by not forcing them to authenticate to the systems “behind” the SSO front door. Still, they move away from Zero Trust, a principle coined by Forrester and being adopted by organizations globally.
Vulnerability #3: An exposure of traditional MFA systems.
This was not directly related to the SolarWinds attack vector, but it was used against FireEye and surfaced around the same time. In this case, the attackers could gain access to FireEye’s email servers with a username and password and then fool the system into thinking they already performed an MFA action.
From Bleeping Computer:
“This allowed the attacker with knowledge of a user account and password to then completely bypass the MFA set on the account” – Volexity
To conclude.
It could be argued that all 3 of these vulnerabilities could be mitigated with strong Identity-Based Authentication. For example, if the attackers had to prove their identity before modifying code or accessing the SAML server, or the FireEye email servers, they might have failed because they could not present the proper cryptographic and biometric controls associated with Identity-Based Authentication. The reliance on legacy MFA and “token-based” secrets such as SAML are essentially relying on hope. They will be exploited again and again unless organizations implement the proper Identity-based controls.
As they say, hope is not a strategy…
