SolarWinds, Code Signing, and the Limits of Cryptography

The SolarWinds breach is one of the biggest and most famous cyberattacks in recent history. An attacker compromised the SolarWinds update server and used it to distribute malicious code in the form of updates to its Orion software. An investigation into this attack uncovered a number of different attack campaigns and a variety of different malware samples used by attackers to leverage and expand their access on compromised enterprise networks.

The SolarWinds attackers exploited a few different security flaws to gain access to SolarWinds’ systems, but this isn’t what made the breach headline-worthy. The massive scope of the SolarWinds incident - affecting dozens of companies - was made possible by a misplaced trust in code signing.

What is Code Signing?

Every organization is dependent on third-party software. At a minimum, companies are running third-party operating systems on their computers, and most companies are using desktop software or cloud-based SaaS applications to do their business. All of this software creates cybersecurity risk for an organization, but these risks are accepted because the benefit of the software outweighs the risk. Additionally, in most cases, the software is developed by companies that are well-known and trusted.

But how do we know that the alleged creator of a particular program actually wrote the code? This is where code signing comes in. Public key cryptography provides the ability to generate digital signatures. Data can be signed with a private key, and the signature can be verified using the corresponding public key. As long as the private key actually belongs to the company and is kept secret, then this process verifies the authenticity and integrity of the signed data (since no-one can generate a valid signature with an invalid key and modifying the data invalidates the signature). Software developers use digital signatures to prove the authenticity and integrity of their code. When installing a program or any updates to the program, it is possible to download the associated digital signature and public key and verify the signature. As long as the signature is valid, the software has not been modified and was actually signed by the alleged creator.

Garbage In, Garbage Out

The digital signature algorithms in use today are secure against attacks with modern computers. However, the SolarWinds attackers managed to infect other organizations with malware using software updates with valid digital signatures. So what went wrong? The simplest answer to this question would be that someone stole the private key that SolarWinds uses for code signing. However, this isn’t the case.

At the end of SolarWinds’ development pipeline, its update code was digitally signed just like it was supposed to be. However, at this point, the damage had already been done. The SolarWinds attackers inserted malicious functionality into the update code during development, where it remained undetected. Once packaged as part of a legitimate update, it was trusted, installed, and executed on the systems of SolarWinds customers, providing the attacker with access to their networks as well.

The SolarWinds incident underscores the limitations of cryptography. Cryptographic solutions like digital signatures can be powerful tools for protecting the confidentiality, integrity, and/or authenticity of data. However, the protections that they provide are limited to the time after a signature is generated or the time between data encryption and decryption. Any modifications to the data outside of these time periods may go undetected, and trusting blindly in code signing leaves organizations vulnerable to attacks like the SolarWInds incident.

Trust But Verify

Code signing is a powerful tool and should definitely be used to help verify the authenticity and integrity of data from trusted providers, like software and software updates. However, a valid digital signature doesn’t mean that the data itself is legitimate and was not compromised before the signature was generated and applied. As supply chain attacks become more common, organizations need to take a “trust but verify” approach to verifying the data and software that they rely upon.