Read time: 25 minutes
How Is Code Signing Used
Code Signing Abuse
- 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. 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.
- 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. 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
Safeguarding Code Signing Certificates
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
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.
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.
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.
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.
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.
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.
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.
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.