Software supply chain attacks continue to be successful, and it seems like lessons from previous attacks are not being learned. In December, an unauthorized user accessed GitHub’s systems and stole three encrypted code-signing certificates: one Apple-issued Developer ID certificate and two DigiCert-issued code-signing certificates for its desktop and Atom applications. While the attacker did not decrypt and use the certificates, GitHub decided to revoke them as a precautionary measure. This security breach had highly disruptive consequences for its user base, as outlined in a February announcement.
Another security breach at Micro-Star International (MSI) resulted in a software supply chain attack, where hackers had access to private signing keys for MSI’s firmware and Intel’s UEFI. When malware infects firmware and UEFI, it poses a significant threat. Malware is increasingly being hidden in the software supply chain through compromises in build platforms, poor code-signing hygiene, and exploitation of third-party open source and commercial software. The growing usage of open source software may contribute to this trend.
Code Signing Certificates Are Now a Hot Commodity for Criminals
Software developers use code-signing certificates to digitally sign various artifacts such as firmware, applications, drivers, executables, and apps. This allows end users to verify the integrity and authenticity of the software, ensuring it hasn’t been tampered with by a third party. These certificates typically include a digital signature, a company name, and often a time stamp to enhance trust in the software supply chain. However, criminals are increasingly targeting code-signing certificates as an attack vector.
Instances of code-signing attacks have been rising. In an attack on chipmaker Nvidia, the extortion group Lapsus$ stole employee credentials and proprietary data. To further their malicious activities, they utilized stolen Nvidia code-signing certificates along with private keys to sign malware in Nvidia’s name. The malware appeared legitimate to unsuspecting victims, allowing it to be loaded onto their Windows computers and servers.
The consequences of a stolen code-signing certificate with a private key can be severe for a company’s reputation and financial well-being. Malicious software signed with a stolen private key can propagate quickly, as users are more likely to trust software signed with a reputable certificate. Browsers and operating systems typically display a message confirming the trustworthiness of the software during installation, inadvertently facilitating the spread of malware.
How to Keep Code Signing Certificate Attacks at Bay
Fortunately, in the case of GitHub, the company conducted an investigation and determined that there was “no risk to GitHub.com services” due to the unauthorized access. No unauthorized changes had been made to the affected projects. Although the certificates were password protected, GitHub believes there is no evidence of malicious use during the time between the breach detection and the certificate revocation. While password protection provides some level of security, it is not the recommended method to protect sensitive cryptographic assets like private keys, as it can be susceptible to brute-force attacks. These attacks have shown a high success rate in cracking passwords given enough time. However, the situation could have been much worse if GitHub had not taken swift action to revoke the certificates and conduct the necessary investigation. This helped the company confirm that no unauthorized changes had been made to the code in the GitHub repositories during the period between the breach and the revocation of the certificates.
To prevent such incidents in your organization, consider a comprehensive approach that includes policy, process, and technology. These aspects play a vital role in ensuring security in many areas, including the protection of cryptographic assets.
It is important to establish a robust certificate policy that aligns with industry standards and government regulations. This policy should include internal decisions on how to safeguard the organization. It’s worth noting that as of June 1, 2023, the CA/Browser Forum for code signing will enforce the use of strong key protection for new code-signing certificates. This entails utilizing FIPs and/or Common Criteria-certified solutions and hardware for key generation and protection. This change is necessary, as the current approach is not compliant and carries risks.
Key rotation is another critical policy to enhance software supply chain security. Relying on a single key and certificate to sign all code can result in significant disruptions if the key is compromised. Implementing a robust key rotation strategy, where unique keys and certificates are used whenever possible, can mitigate the impact of a security breach. Additionally, controlling user access to critical signing keys through approval workflows or scheduled release windows adds an extra layer of protection.
You also need to layer on process controls. It’s essential to consider how to secure keys and regulate access to them. It is important to assess signing processes, who has control over access to keys and certificates, and who can sign and when. The software engineers of the organizations that are producing the software had stored certificates with private keys in the code repository for convenient signing automation during the CI/CD process.
Furthermore, ensuring vulnerabilities are not introduced from open source libraries is crucial before signing code. Deep and comprehensive binary software scanners can be used to look for threats such as malware insertion, private key leakage, and other vulnerabilities in the final software image. Generating a complete software bill of materials (SBOM) at the time of signing is also crucial to ensure a record of everything that was included in the binary. SBOMs need to be generated for every release to monitor changes over time. Additionally, SBOMs are becoming a requirement for many industries.
Building in-house solutions with custom flows backed up with hardware security modules (HSMs) is not a core competency of most organizations. A better approach is to seek a partner with solution expertise to help secure the different stages of the software supply chain. [Editor’s note: The author’s company is one of a number of companies that offer such services.] Employing a software supply chain solution equipped with managed signing practices can securely sign artifacts in an automated way without exposing private keys and certificates in the source code repository or on the build server. This approach reduces risk, centralizes controls, and enforces policy.
The moral of the story is this: Businesses that develop business-, mission-, or safety-critical software that they or their customers rely on must learn from previous victims of software supply chain attacks. Taking a multifaceted approach and employing multiple strategies and techniques is essential for software security.