Lessons not learned from software supply-chain attacks

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 read the complete article, visit Dark Reading.