Adversaries understand that attacking high profile organizations directly is tricky and will typically be harder and yield slower and fewer results. Shifting "upstream" in the software supply chain increases the number of targets and the chances for successful infection and therefore adversaries often prefer this approach. A successful supply chain attack usually involves compromising software while maintaining its legitimate digital signature, implying that the attackers either modified source code on the victims' production environment or patched software on the build servers, abusing the validity of the signing process.
FireEye disclosed yesterday that unknown attackers, they track as UNC2452, were able to compromise the code signing process of an update of the widely-used network monitoring and management software Orion by SolarWinds.
According to FireEye CEO Kevin Mandia, the attackers “tailored their world-class capabilities specifically to target and attack FireEye. They are highly trained in operational security and executed with discipline and focus” and were searching for information related to some of the company's government customers.
According to Reuters, “The U.S. government has not publicly identified who might be behind the hacking, but three of the people familiar with the investigation said Russia is currently believed to be responsible for the attack.”
Importance of securing the code signing process
The details of the attack are yet unknown, however from a statement released yesterday, it is clear that SolarWinds experienced a highly sophisticated, manual supply chain attack on SolarWinds® Orion® Platform software builds for versions 2019.4 HF 5 through 2020.2.1, released between March 2020 and June 2020.
This type of attack would suggest that SolarWinds did not adequately protect their code-signing process and maybe their code signing credentials. Had that been done, the adversaries who breached SolarWind's security defenses would not have been able to inject malicious code to the Orion update and remain its SolarWinds valid signature.
Venafi suggests the following best practices for securing the code signing process:
- Never, ever store code signing keys on a build server, web server, or a developer’s computer. They should always be stored in an encrypted location with very limited and controlled access. Code signing keys should never leave this location, even during a code signing operation.
- Create a process that segregates duties amongst multiple people: InfoSec specifies security and encryption parameters, the software project owner defines who is authorized to sign & what approvals are needed first, a limited list of persons (or computers) that are authorized to sign, and then independent auditors who can verify that processes are being followed.
- Limit access to code signing keys by specifying what machines are able to access them, what people are authorized, what time of day they can be used, and the types of code signing tools that are allowed.
- Create and enforce an approval process that could require multiple approvals (for high-value code assets) before a code signing credential can be used for signing
- Maintain a log (company-wide visibility) of all code signing activities so that you know what code has been signed, what certificates were used, who used them, what code signing tools were used, and which computer was used to sign them
- Offer code signing as a service to development teams so that critical security issues about type of encryption, certificate authority, etc are made by the InfoSec team but extremely easy/simple/fast access to a code signing service is available to your development teams
- Protecting Your Software Infrastructure in these Uncertain Times
- Study: How Well Are You Protecting Code Signing Certificates?
- The Hidden Dangers of Unsigned Firmware
- What Is a Code Signing Certificate