11 Ways To Defend The Software Supply Chain From Code Signing Abuse

Recently, a hacker attempted to install a tool for hacking into a customer’s computer by using a fake code signing certificate impersonating the cybersecurity firm Emsisoft. The attacker attempted to spoof or create a fake certificate, using a similar name to Emsisoft, aiming to appear as a legitimate publisher and trustworthy source. The official report from Emsisoft stated, “We recently observed an incident in which a fake code signing certificate supposedly belonging to Emsisoft was used in an attempt to obfuscate a targeted attack against one of our customers. The organization in question used our products and the attacker’s aim was to get that organization to allow an application the threat actor installed and intended to use by making its detection appear to be a false-positive.”

Code signing is the process of digitally signing software, executables, and scripts using a digital certificate (public and private key) to verify the publisher and guarantee that the code has not been altered or corrupted since it was signed. In this particular attack, the bad actor installed a remote access application, MeshCentral, and signed the MeshCentral executables with a fake Emsisoft code signing certificate to make the application appear safe and allow-listed.

Another primary avenue of attack related to code signing is when the private key becomes compromised. When a private key is compromised, the certificate loses its trust, thereby also jeopardizing the authenticity and integrity of the software signed by the code signing certificate. Compromised code signing keys are goldmines for hackers, as they can use the keys to sign malware that appears to be legitimate software or firmware.

How does Code Signing work?

1. A publisher or developer uses a code signing certificate, consisting of a public and private key, to sign a file or code.
2. A digital signature is applied and a hash of the code is generated.

a. The hash is created using a mathematical algorithm and is used to condense the file down to a fixed size, in order to be signed. The hash is encrypted using the code signing certificate private key.

b. The encrypted hash and the signer’s public key are combined into a digital signature.

3. The file/code is then distributed and made available via publishing to a website or mobile network.
4. When a user downloads or encounters the code, the user’s system software or application automatically uses the public key (included in the digital signature with the code) to decrypt the hash.
5. The user’s system/application calculates a new hash for the code and compares it to the original hash of the code. If the hashes match, then it’s clear that the code has not been altered and the download of the software or code is permitted.

Potential Software Supply Chain Threats and Abuse of Code Signing

One form of code signing abuse is when attackers obtain a valid code signing certificate and sign malware under a company name that appears to be legitimate in order to steal users’ sensitive information or outright destroy their systems. Another form of abuse happens when attackers manage to steal code signing certificates from trustworthy organizations, enabling them to publish code under another reputable organization’s name and spread malware to more victims. Unfortunately, sophisticated attackers are able to abuse code signing practices through a variety of ways, including:

• • Private Key Compromise: Threat actors can gain access to trusted users’ private keys when code signing certificates or keys are improperly maintained and managed. Using these compromised keys, they can digitally sign malware in the name of trusted organizational identities. To prevent this, keys can be safely stored and safeguarded using Hardware Security Modules (HSMs).
  • Software/Code Vulnerabilities: Code can also be exploited if the software contains vulnerabilities. The code signing will mean nothing if these vulnerabilities are discovered by attackers before they are patched. Even when the code is signed, attackers can still use these vulnerabilities in order to install malware on victims’ computers. Before deployment, code should be rigorously tested to make sure vulnerabilities are not exploitable.
  • Compromised Certificate Authority (CA): The Certificate Authority (CA) organization that issues trusted code signing certificates can or may suffer from direct attacks.Therefore, it is always recommended to make sure that CAs issuing certificates are in good standing and adhere to industry best practices. Incidents of cyberattacks against CAs may potentially result in the company mis-issuing certificates and as a result going bankrupt. For example, a Dutch certificate authority named DigiNotar experienced an attack in 2011. DigiNotar filed for bankruptcy after their Certificate Authority was compromised by hackers, who were then able to issue fraudulent certificates for countless prominent websites.
  • Using revoked or expired certificates: Compromised and unrevoked certificates may be exploited to permit the code signing of malicious software. Certificates that have been compromised should be revoked and immediately added to the Certificate Revocation List (CRL) so that replying parties are warned that the certificate is no longer valid and trusted.
  • Weak Cryptography and System Vulnerabilities: When weak and insecure cryptographic algorithms are used for code signing certificates, such as with self-signed certificates, vulnerabilities can be exposed and exploited by hackers to launch cyberattacks like brute force attempts at hacking into code signing keys. System invasions can also result from weak governance controls in development and production. These security flaws can lead to the signing and authentication of malicious codes. To develop a secure environment, CISOs should take suitable governance controls into consideration. Additionally, carrying out an appropriate evaluation of code signing procedures would help prevent security breaches.

Fortunately, there are effective solutions that can help mitigate the risk of code signing attacks and abuse. Here are the top recommendations for protecting Code Signing Certificates and mitigating the risk of potential abuse:

Best Practices for Protecting the Software Supply Chain with Secure Code Signing

1. Private key protection and verification: Effective June 1, 2023, all newly issued, publicly trusted code signing certificates must adhere to the new Code Signing Certificate Working Group requirements and guarantee that the subscriber’s private key is generated, stored, and utilized on appropriate FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent hardware. Essentially, organization-validated or standard Code Signing Certificates will now have to adhere to the private key generation and protection standards that Extended Validation code signing certificates follow, in accordance with the Code Signing Baseline Requirements (CSBRs). These new private key storage requirements, where compliant tokens or HSMs must be used for private key generation and storage, will lessen the risk of compromised private keys.
2. Implement access control: Implementing role-based access control (RBAC) helps to secure private keys and reduce the risks of keys being stolen or compromised. When bad actors gain unauthorized access to a legitimate private key, they could masquerade as the developer and distribute malicious code to unsuspecting users. Using secured vaults and cryptographic hardware products, like HSMs ensures high-end security and prohibits the exportation of private keys to software where it can be compromised. Private keys must be protected and stored on FIPS 140-2 Level 3 validated HSMs or hardware, with limited or restricted access. This goes a long way towards protecting private keys and other encryption assets.
3. Authenticate code before it is signed and released: Follow a streamlined code signing submission and approval process to prevent the signing of unwarranted and malicious code. Even after signing, the code needs to be authenticated and validated before it can be released to the users. A well-defined authentication process can help to ensure that software does not contain any questionable code that can erode customer trust and damage the reputation of the business. Maintaining logs of all code signing activities for auditing and reducing incident-response time should also be part of the process.
4. Use test-signing certificates: Employ private trust test certificates or those issued by an internal CA to sign the pre-release code. Test certificates are chained to an internal root certificate which is different from the publicly trusted root certificate which is used to sign the released products.
5. Timestamp code: Applying a timestamp ensures that the code signing digital signature remains valid, even after the certificate used for signing expires. Timestamping your code also reduces the impact of certificate revocation. In case malware is detected and the associated certificate is to be revoked, timestamping will ensure that revocation will affect only the software released after the date of the security compromise. Timestamping enables you to verify the code after the certificate is expired or revoked.
6. Rotate keys: Key rotations should be done when the client or CA certificates expire. The organizational policy should include either proactive periodical rotation, or reactive key rotations when a CA or a client key is compromised. Private keys or encryption keys are a gateway to critical information. They are the cornerstone of PKI-based authentication and digital signing. When private keys are compromised, they can be used to impersonate enterprise servers and steal data.
7. Revoke compromised certificates: In the occurrence of unfortunate events like compromised keys and signed malware, you have to report the security incidents to your certificate authority (CA). The compromised code signing certificates need to be revoked, which will invalidate the software and prevent the further propagation of malware. A certificate should be revoked immediately when its private key shows signs of being compromised. It should also be revoked when the domain or organization for which it was issued is no longer operational.
8. Follow certificate policies: The certificate policy (CP) defines the rules a CA needs to follow when issuing digital certificates, and the certificate practice statement (CPS) provides a more detailed description of these practices and procedures required to efficiently manage the certificates. These rules and regulations are tailored to match the organization’s public key infrastructure (PKI) requirements and operational processes. The documents contain specifications about your PKI architecture, which includes digital certificate uses, authentication, identification, key generation, and technical controls. Setting accurate policies in place and abiding by them is fundamental to the successful execution of PKI management procedures.
9. Centralize the certificate inventory: A centralized certificate inventory is fundamental to safeguard certificates from misuse. Track every certificate within the organization’s environment, whether presently in use, expired, discarded, or revoked. A centralized certificate inventory ensures holistic visibility into the certificate infrastructure, making it seamless to renew and manage the certificates. Even a rogue or temporary certificate can sabotage corporate IT operations and give hackers a chance to exploit the certificates.
10. Monitor and audit compliance: Code signing security is an ongoing process and not set-and-forget deployment. Digital certificates have limited validity and inevitably expire, keys weaken over time and the attack surface continues to expand and evolve. Monitor code signing certificate requests and authentication procedures for fast detection of anomalous activities within the certificate infrastructure. Create comprehensive audit logs and review them periodically to identify unauthorized actions.
11. Embrace certificate lifecycle automation: Automated certificate lifecycle management (CLM) tools enable continuous discovery of certificates across your infrastructure through a variety of modes. Certificate lifecycle management tools help manage code signing certificates and keys end-to-end by integrating with trusted CAs that issue these certificates. An efficient code signing solution that supports native client integrations, allows you to continue utilizing existing DevOps tools and platforms without impacting performance or security. Users can choose between a FIPS-compliant, AES 256 encrypted key store or an industry-standard HSM to store private keys. Properly documenting, managing, and storing certificates are critical steps in preventing certificate-related vulnerabilities and security risks.

Code signing depends on cryptographic procedures, like many aspects of modern cybersecurity. The private keys must therefore be protected with the strictest security measures because they are a mission-critical asset. Security is paramount because a stolen code signing key could have disastrous consequences.

Talk to an expert today to learn how AppViewX CERT+ and PKI+ help organizations to ensure the confidentiality, availability, and integrity of private keys and digital certificates at all times—while maintaining agility and compliance.

Request Live Demo

About the Author

Debarati Biswas

Senior Specialist- Product Marketing

A content creator and a lifelong learner with an ongoing curiosity. She pens insightful resources to address the pain points of the readers and prospective buyers and help them make well-informed decisions.

More From the Author →