How PKI was used in the SolarWinds Orion attack

In December 2020, it was revealed that software company SolarWinds’s Orion platform had been compromised, with hackers injecting a malicious code, now known as Sunburst, into it between February and June 2020. 

The Orion platform provides a range of technical services, including network monitoring, seeking and fixing issues in a great number of organizations’ computer networks. With such deep access to these computer networks as well as a high-profile customer base including US government agencies like the Treasury and Commerce Departments, in addition to the majority of Fortune 500 companies, the potential consequences of this attack are huge. These hackers have had access to a plethora of sensitive data for months.

One worrying element of the hack was the use of compromised X.509 certificates (public-key certificates) and public key infrastructure. 

A malicious backdoor

The attack began with hackers infiltrating Orion’s build environment, injecting malicious code into the software, allowing them to gain a foothold in the network and gain access to sensitive files and credentials. Without being aware of it, SolarWinds code-signed the compromised software and delivered it to nearly 18,000 customers via a software update.

Before we get into the details of the attack, we should give a brief overview of how code signing and X.509 certificates are utilized for security software. You probably already know that SSL certificates are a type of X.509 certificate. When you purchase one from SSLs.com, it is issued to you or your tech team and you install it on your website yourself. Beyond creating an encrypted connection for your site, an SSL acts as a digital passport of sorts. It includes a digital signature that shows that it was issued by a trusted Certificate Authority (CA) and that it was issued to the person who owns the website. With software like Orion, it’s a little different. 

This kind of software comes with its own X.509 certificate that digitally signs software in order to confirm identity of the author and that the code hasn’t been corrupted or altered since signing. This is known as code signing. Its purpose is to authenticate where a file originated from and protects users from spoofing attacks, where the real code is replaced by false codes with identical file names. Instead of being issued and signed by a CA, such certificates are signed by the issuing tech company, in this case, SolarWinds. 

The issue here is not that the X.509 certificate itself was somehow hacked, but that the software had already been compromised and corrupted by malicious actors in the SolarWinds’ Orion build environment prior to code signing. The malicious actors already had access to SolarWinds backend and added the malicious code. Without knowing it, the build system signed a code signing certificate for the updated software, effectively legitimizing a malicious version of the software. 

Stolen certificate

Once the hackers gained access to the network, they had access to the organization’s trusted SAML token signing certificate, another type of X509 certificate that authenticates the identities of service providers. With this certificate, the hackers were able to forge SAML tokens in order to impersonate any of the organization’s existing accounts.

The takeaway

This whole situation raises questions, not about PKI necessarily, but security protocols across the IT industry. 

In this instance, code signing technically worked the way it was supposed to. In much the same way you shouldn’t automatically trust a website that has an SSL certificate, code signing doesn’t guarantee the pure intentions of whoever is signing it, nor even the quality of the code they have signed. As Sectigo pointed out in their piece on this subject, “the fact that it is signed by a public CA does not indicate that any given piece of software is well written, bug-free, efficient, clear of intellectual property entanglements, or indeed benevolent in its behavior”. The only guarantee is that the code hasn’t been altered or tampered with since being signed. The stolen SAML token signing certificate highlights the need to properly effectively track and monitor the creation and use of such certificates to avoid misuse and abuse.

Beyond PKI, this was a highly complex security breach that experts are still figuring out. The initial attack was managed through various servers located in the US, mimicking legitimate traffic and thus circumventing the threat detection techniques of Solarwinds, the US government, and private companies. According to CrowdStrike, a tech firm investigating the malicious tool, Sunspot, that was used to inject Sunburst into the build environment, the hackers added several safeguards to prevent the developers from noticing their presence or the changes they made.

As a result, it’s difficult to place blame on any one thing that allowed the breach to happen. Already considered one of the most complex cyberattacks in history, SolarWinds has been very open about its investigative efforts, in the hopes that sharing this information will, “will help the industry guard against similar attacks in the future and create safer environments for customers.”
For more information about the attack and what you should do if you think you’ve been affected, check out this article from the US Cybersecurity and Infrastructure Security Agency.