3 min read

Misuse of X.509 Certificates & Keys Involved in SolarWinds Attack

Dawn M. Turner (guest) : 14. April 2021

CSG code signing Solarwinds Attack
Misuse of X.509 Certificates & Keys Involved in SolarWinds Attack

This article discusses the misuse of X.509 certificates and keys in the SolarWinds attack and how Cryptomathic CKMS and CSG could help protect against such attacks.

In December 2020, it was reported by the Washington Post that SolarWinds, a major U.S. information technology firm, fell victim to a massive cyberattack that went undetected for months, presumably beginning in March 2020. But it was not just SolarWinds that was affected. The attack spread to its clients, including private companies, 425 companies out of the U.S. Fortune 500, top 10 telecommunications companies, and universities and colleges around the world. But what was most worrisome is the attack on vital agencies of the United States government, including the Military, the Pentagon, State Department, Treasury Department, and the Department of Homeland Security, through a compromised update to SolarWinds’ Orion software.

Most Organizations Unprepared for Such Attacks

The software supply chain attack, named Sunburst, involved hackers compromising SolarWinds’ infrastructure and using Orion, a network and applications monitoring platform, to produce and distribute trojanized updates to that software. This attack not only highlighted the severe effect that software supply chain attacks could have. It also highlighted that most organizations are completely unprepared to prevent and detect such a threat.

While multiple failures led to the attack, one of the most glaring failures was that the attackers could misuse X.509 certificates [1]  and keys to forge and undermine trust. An article released by the Microsoft Security Respons Center [2]  ]explained some of the details of this supply chain attack.

How X.509 Certificates and Keys Were Misused

In the Sunburst attack, the attackers were able to modify source code to include a malicious backdoor. This code was compiled, signed, and delivered unbeknownst by SolarWinds to almost 18,000 of its customers through its software update and code-signing systems.

However, this initial breach was not caused by a stolen code-signing certificate. Instead, the tampered library had been signed by what appeared to be a valid certificate, even though it had been compromised. Unfortunately, this and other similar supply chain attacks that involved the theft of code-signing certificates or compromised signing systems are becoming increasingly familiar.

In explaining such attacks, Microsoft states that “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.”

In the case of SolarWinds’ Sunburst attack, the attackers used forged SAML tokens and then signed them with legitimate but compromised certificates. In doing so, they could impersonate trusted users and accounts, which allowed them to move freely with their attack without being detected.

It is also possible for hackers to modify Azure Active Directory settings that allow them to get long-term access. This would allow them to also add credentials, such as X.509 keys or passwords, to one or possibly more legitimate OAuth applications. Once inside, the attacker must often continue to find ways to stay there. With the attack on SolarWinds and its clients, the attackers used X.509 certificates to access the network through legitimate OAuth access [1].

Meeting Best Practices with CSG+CKMS

There is a growing trend involving the misuse and theft of keys and digital certificates. The bottom line is that the use of certificates needs to be effectively tracked and monitored across apps, cloud, and network infrastructure. Therefore, there is an increased need for awareness and best practices to prevent breaches from occurring.

The following six best practices can be fully met with Cryptomathic’s Crypto Service Gateway (CSG) and Crypto Key Management System (CKMS) [1]:

  • Do not store code-signing keys on developer workstations, web servers, or build servers. Private keys should only be kept in a FIPS 140-2 validated HSM (accomplished through CSG)
  • Segregation of duties between users who are authorized to sign code, who can approve the request, and monitor and enforce compliance with signing policies. (accomplished through CSG’s Endorsed Code Signing functionality)
  • Defining policies that limit access to code-signing keys by the user, machine, location, duration, time of day, signing method, or other parameters that make sense to your organization. (accomplished by CSG policy engine)
  • Maintaining an active inventory of all certificates, where they are installed, who they were issued from, and who owns them and your domains. (accomplished by CKMS)
  • Controlling issuance of certificate and approval workflows ensures that every certificate is trusted, compliant with policy, and up-to-date. (CKMS can accomplish this to some extent)
  • Regular testing of certificate re-issuance and revocation capabilities to ensure effective and rapid response to a compromise. (accomplished by CKMS)

Solution brief - CSG Code Signing

References