A Detailed Guide to Code Signing Abuse

Building a secure IT infrastructure involves having strong security controls in place. Some examples of this include implementing a Public Key Infrastructure, putting monitoring products in place in your environment, or utilizing legitimate Code Signing Solutions. Code Signing is the process of signing software to authenticate it for users.

Using Code Signing certificates, a software designer signs their software with a certificate containing their public key. The software recipient can then verify that the public key is a part of a key pair with the designer’s private key, thus authenticating the software. Code Signing also confirms the originality of digital information, like software code, and establishes the legitimacy of the author.

Code Signing plays an important role as it can identify legitimate software compared to malware or rogue code. In technical terms, Code Signing creates a hash of the code and encrypts it with a private key adding its signature. During execution this signature is validated and if the hash matches, it gives assurance that the code has not been modified. It also establishes assurance that the code is issued from the legitimate author that it is claiming to be.

While Code Signing provides security to code it can pose issues and can be vulnerable to attacks or abuse if not implemented properly.  The recent Solar winds attack is one such example where the code signing process was compromised and rouge code was implemented in systems and endpoints as legitimate software. An attacker’s goal is to find the path of least resistance.

There are many industries, like the gaming industry, that want to do a much faster release or deployment of their code. Such as, bypassing processes or not following securities best practices is very common, and allows organizations to fall prey to code signing abuse.

How Is Code Signing Used

Code Signing is used for a variety of purposes. The most obvious use is to sign software code with the developer’s private key. As previously mentioned, the software is signed to assure the code does not contain any malicious code, to let the recipient of the data know that the developer is who they say they are, and build trust between the developer and end-user.

With signed code, users can trust that the code holds no malicious intent in the background, as the code signer would be held responsible if this was the case. Other areas that code signing is used in is with enterprise applications, Internet of Things (IOT) devices, and Development and IT Operations (Dev Ops).

With enterprise applications, any internal code, scripts, packages, etc, are all signed via code signing. The scripts and packages are signed for the same reasons that the code is signed, as attackers could hide malicious payloads within these. IOT devices use code signing for authentication and validation purposes. Updates for both firmware and software signed by developers, as are messages between users on IOT devices.

With Public Key Infrastructures (PKIs) in use, code signing certificates authenticate users within an organization’s network. By “signing” their certificate with their private key, using the public key, the users’ identities can be validated. With Dev Ops, integration and code deployment are constantly ongoing. The code is deployed in multiple instances on containers and Cloud systems, meaning these container images must be signed during multiple stages of the code’s lifecycle.

Code Signing Abuse

A common reason for abusing code signing is to provider victims with code that looks legitimate, but contains malicious software that can steal sensitive information from users or completely destroy their systems. Attackers could also steal code signing certificates from legitimate developers, thus giving them the ability to release code under a trusted creator’s name, allowing them to release malware to more victims. Code signing abuse can occur through a number of different ways.

• Key Theft

  When digital certificates or keys are poorly stored and managed, it opens the door to threat actors, letting them steal the private keys of trusted users. Using these keys, they can sign code as another identity, and they can have certificates issued in the trusted identities name and misuse that certificate within the network.

  For instance, a small software development company stores its private key on an unsecured server. An attacker can steal the key by gaining access to the server using a phishing attack targeting the admin. Through the use of Hardware Security Modules (HSMs) keys can be kept completely secure from attackers, as they would need to physically access the HSM with the proper credentials to steal the keys stored inside.

• Coding Errors

  Another, less thought of, error that code signing can be abused is if code signed software contains vulnerabilities. If vulnerabilities are present in software, and threat actors discover them before they are patched, then their code signing was for naught. Even though the code is signed, these vulnerabilities can be leveraged by attackers to deploy malware onto victim’s systems. Code should be thoroughly tested before deployment, to ensure that no vulnerabilities are present.

  For example, a developer rushes a software upgrade to fix a high-priority bug. The code is signed and pushed out to customers without proper security testing. However, this code contains backdoor gateways to access sensitive customer information, which can lead to many consequences for the organization and its clients.

• System Compromise

  If a system is compromised, and software is being signed on that system, the code can be changed before the actual signing. This allows malware payloads to be hidden in code that is legitimately signed, without the developer’s knowledge. Once inside the system, the attackers can inject a small piece of malicious code into the software before the build is signed. Code signing was abused in this way in the recent SolarWinds attack. Ensuring your systems are up to date with all security patches can ensure the security of your online environment.

• Use of Revoked/Expired Certificates

  When a key or expired certificate is compromised, if the validity of that certificate is not checked by a Certificate Authority (CA), then that certificate can be used to allow for code signing of malicious software.

  Certificates that have expired or been revoked should be put in the Certificate Revocation List (CRL) so that CAs can note that that certificate should no longer be used for anything until its replacement or renewal.

Well-Known Code Signing Abuses

By learning from past code signing abuses, we can safeguard data in the future. A number of notable code signing abuses have occurred in the past, but today we will focus on three of the higher profile ones, starting with SolarWinds. In 2020, the organization SolarWinds found that its core systems had been compromised. Utilizing a supply chain attack, attackers managed to gain access to a Microsoft365 account owned by SolarWinds in September 2019.

This allowed the threat actors to gain access to SolarWinds code and other systems, and giving them the ability to implement code signing abuse. By editing code before it was signed, these attackers were able to implement a type of malware called a Remote Access Trojan, or RAT, that gave them remote access to victim’s computers.

This RAT was hidden inside the updates of a network monitoring software created by SolarWinds called Orion. This started a campaign that created a command-and-control infrastructure on the victim’s devices. Government officials, private organizations, and many US federal government agencies were affected by Solar Winds.

Another attack that utilized code signing abuse was the D-Link attack. A network equipment provider called D-Link accidentally published their private code signing keys when publishing their source code for a firmware update. In this case, attackers could utilize these keys to side code of their own making, but have recipients believe that they are receiving trusted code from D-Link.

The importance of protecting private code signing keys cannot be overstated, as having your digital identity stolen can lead to sensitive data loss, lawsuits, and more. With the D-Link attack, only one of the four signing keys leaked was valid, but all it takes is one valid certificate for it to be misused.

One last code signing abuse we will talk about is Shadow Hammer. In 2019, a big-name computer manufacturer called ASUS had their code signing process compromised. Using ASUS’ software’s live update utility, the threat actors released malware to create backdoors into thousands of users’ computer systems.

Because the malware was signed by ASUS, the live update tool updated the systems, allowing the attackers to steal sensitive data from the victims. Again, protecting systems by updating software and keeping your other systems secure will stop your code signing process from being taken over.

Safeguarding Code Signing Certificates

There are a number of different code signing best practices that can be followed to ensure your code signing process has a secure environment to work in. The National Institute of Science and Technology (NIST) releases a number of recommendations on certificate and code signing best practices for users to view. Some are more obvious than others, but we will go through all types of them anyways.

1. Securing private keys on HSMs

   One of the weaknesses of many organizations is the lack of security surrounding their private keys. Whether on the Cloud or on-premises, Hardware Security Modules can fully protect your private keys from attackers. A Hardware Security Module is a specialized, highly trusted physical device which performs all major cryptographic operations, including encryption, decryption, authentication, key management, and key exchange.

   HSMs are specialized security devices, with the sole objective of hiding and protecting cryptographic materials. They have a robust OS and restricted network access protected via a firewall. HSMs are also tamper-resistant and tamper-evident devices. As an on-premises HSM must be physically accessed to steal keys, they are considered one of the best possible ways to stop unwanted users from accessing private cryptographic keys.

2. Control of the Code Signing Process

   Just from two of our three real life examples of code signing abuse, you can see that controlling your organization’s code signing process is vital for following code signing best practices. Part of securing the code signing process is using authentic and secure code signing solutions, if you decide to go this route.

   Code signing solutions provide all the infrastructure for signing code and other documents, while you deal with the security of system. Along with secure code signing solutions, controlling who can access private keys, validation of user’s identities, and use of two-factor authentication on code signing services are just a few other ways to manage your code signing process.

3. Code Validation

   Before signing any code, applications should be thoroughly checked for vulnerabilities or malware. Along with this, deprecated function calls should be removed from code. Double and triple checking code for vulnerabilities or security gaps can save your organization from releasing insecure code that can be leveraged by threat actors to steal sensitive data from your users.

4. Code Signing Devoted Systems

   To ensure the highest level of security with the code signing process, the system implementing code signing should ONLY do code signing. In this way, there is no vulnerability caused by another type of software that can affect your code signing services. Two of the previously mentioned cases of code signing had their code signing process hijacked due to vulnerabilities in other software.

   If a computer has many different software downloaded on their computer, each one is a potential vector for attackers to misuse. Also, part of this practice is the idea that the system should be fully updated and patched, to allow for the most secure environment possible.

5. Certificate Validity Checking

   When running a PKI, certificates must be validated before they are allowed to be used. With code signing, the case is the same. No certificate should be used for code signing, unless its validity has been verified. Certificates should be checked for their validity not only before code signing, but as a part of the process as well. This protects from any oversight in the Public Key Infrastructure that may occur.

6. Certificate Lifecycle Management

   A key component of running a successful PKI is having a strong Certificate lifecycle management plan in place. The steps of the Certificate Lifecycle, and how to secure certificates in each phase, are as follows:

   1. Discovery

      With the discovery phase of the certificate lifecycle, the network is searched for missing, expired, compromised, or unused certificates. If found, these certificates must be revoked, renewed, or replaced. This phase of the lifecycle is extremely important, since it finds gaps in the Public Key Infrastructures’ security and relays these gaps to any monitoring tools in place. This allows the breaches in the system to be patched without any sensitive data loss.

      This management phase also inventories the certificates within the PKI, to help in future Discovery phases and any PKI audits that may occur. Discovering of mismanaged or expired certificates should be done with only trusted software, as missing a certificate in the Discovery phase can lead to attackers being able to use that certificate for code signing abuse.

   2. Creation/Purchasing

      In the Creation/Purchasing phase of the lifecycle, the certificates are created or purchased for use by the certificate requestor. A user or device sends a Certificate Signing Request (CSR) to an Issuing Certificate Authority. The CSR contains the public key and other enrollment information needed to enroll the user within the PKI. The CA then verifies the information contained within the CSR and, if the information is valid, creates the certificate for the user.

      The Issuing Certificate Authority can be a part of the organization’s own PKI or a member of a third-party Public Key Infrastructure. If a third-party PKI is used, then the certificate must be purchased. When creating or purchasing certificates, the Issuing CA should be certain that the data contained in the request is legitimate, as an attacker may be posing as another person to gain a certificate for malicious use.

   3. Installation

      The installation of a certificate is extremely important to get right, as a poorly installed certificate can be misused for malicious activity. Access to the certificate should be possible, as browsers and other users must be able to verify the authenticity of the certificate.

      Even so, security of the certificate is still of the utmost importance in the Installation process. To ensure the strongest level of certificate handling and security, when the certificate is installed, the CA puts policies in place which ensure only authorized individuals can make changes to the certificate.

   4. Storage

      To prevent compromise, storage of code signing certificates is vital, as poorly stored certificates can be taken and used by threat actors. As previously mentioned, though it should be securely stored, certificates still need to be readable by software and other users to authenticate the certificates. To provide strong storage, utilize Hardware Security Modules to store certificate private keys.

   5. Monitoring

      Keeping track of certificates and their status is vital for a strong code signing process. This is a phase that is constantly occurring, as certificates can expire or become lost at any time. The Monitoring stage keeps track of certificates that must be revoked, renewed, or replaced, via the inventory initially created in the Discovery Phase.

      If a certificate is found to be in need of replacement, renewal, or revocation, that certificate is moved on to the next portion of the Certificate Lifecycle. Strong, automated monitoring systems should be in place for proper monitoring. Automated monitoring ensures that human oversight will not occur, and certificates in need of the next phase are not overlooked.

   6. Renewal

      A certificate enters the Renewal stage of the certificate lifecycle when it nears its expiration date. Certificates should have an expiration date of more than 5 years at the most to follow best practices.

      Depending on if automated or manual certificate renewal is in place, certificates can be set to renew automatically as their expiration date nears, or a system administrator can keep a list of all the certificates’ expiration dates so that they can be manually renewed at the proper time. It is best practice to automate the renewal process, as human error can cause oversight of certificate expiration dates.

   7. Revocation

      Certificates must be revoked if they have been found to be improperly used, or otherwise misused. When a certificate is revoked, that certificate as well as its data is entered into a Certificate Revocation List.

      This list is regularly checked by Certificate Authorities so that any Certificate Signing Requests containing that same data are rejected. To protect the revocation phase of the Certificate Lifecycle, CRLs should be kept up-to-date, as allowing the use of revoked certificates to occur will give threat actors access to sensitive data.

   8. Replacement

      The final phase of the Certificate Lifecycle is the Replacement phase. When moving from purchasing certificates to creating your organizations own, the purchased certificates must be replaced. This is rarely done, as it is much easier to just renew a certificate from the original provider rather than replace that certificate.

      Replacement of certificates should be done only by trusted Issuing Certificate Authorities. Along with this, best practices should be followed in each phase of the Lifecycle following the Replacement phase, as the Certificate Lifecycle restarts when a certificate is replaced with a new one.

Encryption Consulting’s Code Signing Services

To protect your Code Signing Process at every phase, take a look at Encryption Consulting’s Code Signing Solution – CodeSign Secure. CodeSign Secure provides a secure and flexible solution to your code signing needs for all Operating Systems including Windows, Linux, Macintosh, Docker, and Android and iOS applications. Digitally signed code ensures that the software running on computers and devices is trusted and unmodified.

We protect your code signing keys with your choice of HSM that is FIPS 140-2 Level 3 compliant. We help you design workflows and policies to secure and streamline your job submission and approval process. Along with this, we will fully integrate your malware and virus detection software with CodeSign Secure to give you the best possible monitoring of the code signing process. CodeSign Secure was developed on an open REST API, allowing for custom integrations and requirements.