The SolarWinds Orion Attack and PKI

The SolarWinds Orion attack at present is dominating IT news cycles, and for good reason. This attacker gained backdoor access and tremendous permissions to about 18,000 organizations including government agencies, large enterprises, technology providers, and even leading IT security vendors. Sectigo is not among those, and there is no evidence to indicate that Sectigo’s systems or operations have been affected in any way.

Plenty has been written already about this attack. Due to its nature as a supply chain attack and the use of escalated privileges to enable lateral movement and other activities, the SolarWinds Orion attack touches on digital certificates and identity authentication in some important ways. We are focusing on those for this post.

Code Signing

To conduct its core attack, the APT appears to have inserted code into the SolarWinds’ Orion build environment, where it was included in signed software builds and distributed with apparently routine software updates. Because the malicious DLL was hidden inside signed updates from a legitimate vendor to its own software, there is no practical way for victim organizations to detect the injection of this malicious code into their systems.

It’s important to understand the nature of code signing and its role in protecting against malware. Signing code ensures that each signed file is bit-for-bit identical to the file when it was signed. This guarantees that no party made any modifications to the file, including adding new malicious code, after it was signed. That is a critical capability when transmitting code across the open internet, as it protects against attacks that intercept and modify code in transit.

Code signing also includes authenticated information about the file’s originator, who signed it. This is valuable in combatting spoofing attacks whereby an actor substitutes false code with identical file names to real, expected code.

Neither of these scenarios applies here. Because the APT injected its malicious code prior to build, the signed, distributed code already included the malicious DLL. In fact, if that DLL could have been somehow removed after signing and before distribution, the updates would have failed as the distributed file did not exactly match the condition of the file upon signing.

What code signing cannot do is compare the code that is signed to the intention of the party signing it. Code signing cannot provide any guarantees or assurances about the nature or quality of the code signed. 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. Code signing simply guarantees that the code is free of tampering since being signed by a known source.

Another way to think about it is that the build system was owned by a malicious actor. This actor perverted the build system to create malicious code. The build system legitimately signed its (unknowingly) malicious code using a legitimate code signing certificate. Because SolarWinds customers had chosen to trust the Orion product inside their own environments, legitimately signed software updates containing this malicious code were able to deploy.

SAML

The NSA has reported that after gaining back door access through the Orion software updates, the attacker used “abuse of authentication mechanisms” for follow-on goals such as logging in to cloud resources. One of those is SAML Single Sign On Federation. In the compromised network the attacker can potentially forge SAML tokens to impersonate a credentialed user with privileges into federated resources. This is accomplished using existing private keys obtained through access to a Microsoft Active Directory Federation Services (AD FS) account’s private store.

Public SSL/TLS

This attack depended on command and control in communication with a variety of domain names. It shouldn’t be surprising that most of these domains were equipped with public-trust, domain validation (DV) SSL certificates, including some from Sectigo.

Similar to Code Signing, TLS certificates ensure that client-server communication is unaltered and not spied upon during transit, and they guarantee that the domain name of the server is known (along with additional organization information in the case of an OV or EV SSL certificate). Once again they provide no assurance about the quality or intent of the services employing them.

MFA

Researchers have noted that the APT employed techniques to bypass MFA protections from DUO. The APT used its ill-gotten admin privileges to generate the necessary MFA artifacts to simulate a real MFA authentication, thereby bypassing MFA protections.

These bypasses share a common theme, which is that the mechanisms themselves all worked correctly for what they were designed to do. By inserting itself into the business process “upstream” of these mechanisms, the attacker nullified their protective value.

Exposed FTP Credentials?

Researchers have discovered a SolarWinds FTP credential exposed on GitHub with the password Solarwinds123. We do not know if the exposed credential enabled this particular attack, but whether or not that’s the case, it illustrates the danger of simple username/password logins at this late date in history.