In 2018 cybercriminals modified the ASUS Live Update Utility to deliver a backdoor to approximately one million people which implanted malicious code. This supply chain attack took place between June 2018 and November 2018, through software which comes preinstalled on all ASUS machines to allow updates to be automatically received from the manufacturer. Why was this attack so successful? It was because the update was authenticated using a code signing certificate which signalled that the malicious code could actually be trusted and run. A similar incident happened with CCleaner in 2017.
Code signing provides a highly valuable function within any software company – which thanks to digital transformation makes it essential to pretty much all businesses. It has been around for decades and is used to ensure the real author of the software and that it hasn’t been tampered with by a third party, such as hackers. Nearly every major operating system uses code signing to verify the authenticity of software that gets installed. The use of code signing is only going to rise in the near future due to technology trends such as mobile apps, DevOps and IoT devices; in fact, 69 per cent of organisations expect their usage of code signing to grow in the next year.
The real danger with unprotected code signing keys is that once used to sign a piece of malware, that malware will appear legitimate to unsuspecting users forever. Revocation of the certificate does not necessarily invalidate the signed malware.
So, what can companies do to protect themselves?
Getting to the root of the issue
Companies have no choice of whether to use code signing or not; it’s a fundamental building block of software distribution. But this is not to say that the system is perfect. Code signing credentials provide high levels of trustworthiness, which makes them very valuable target for cybercriminals, who steal code signing credentials from legitimate companies to sign their malicious code. If the code is signed with a legitimate certificate, defences will let malware through without triggering any alerts and unsuspecting users will trust that the application is safe to install and use.
One of the reasons code signing attacks are so effective is that cybercriminals are successfully stealing and misusing company’s’ legitimate code signing keys. This implies that organisations aren’t doing enough to protect code signing keys and certificates. This was illustrated in a recent Venafi study which found only 28 per cent of organisations consistently enforce a defined security process for code signing certificates. Even worse, they don’t have workflows that restrict the use of code signing credentials to a limited list of authorised personnel, so in essence anyone could be signing the code – 35 per cent of companies don’t have a clear owner for the private keys used in the code signing processes at their organisations.
It isn’t all doom and gloom, companies can take control of their code signing processes. It’s imperative for organisations to know what code signing certificates they have in use and where. Today, IT teams have so many different things coming at them all the time it can be very difficult to keep track of everything, and with digital transformation accelerating at most companies this is only becoming more complex. Here are five questions to help you do a health check on your code signing procedures and get back on track:
- Policies: Does your company have a code signing policy that defines where private keys are stored, who has access to those private keys, and who needs to approve the use of those keys?
- Control: Does your company enforce its code signing policy across all software development teams – whether they are developing internal-only software or software that will be distributed to customers and other third parties?
- Visibility: Does your company have a complete inventory of all code signing certificates that are being used across the entire enterprise—no matter where they are stored or which certificate authority they came from? If you found malware on the internet signed by your company’s code signing certificate, would you know where to start looking for the source of the breach?
- Speed: Does your company have a labour-intensive, slow manual process for handling code signing operations? If so, do you find your development teams trying to circumvent it (or do you suspect that some are)?
- Bandwidth: Does your company limit the code that it signs because development teams can’t manage code signing certificates themselves or teams don’t have the bandwidth?
If you answered yes to one or more of these questions, then you probably have a problem with your code signing process. If you answered yes to 4 or 5 of these questions, then you have a severe code signing process problem and should act immediately. Taking care of all the processes and concerns around code signing can be difficult, time consuming and ultimately impossible for already stretched IT teams to undertake alone. Companies always need to bring in automation to lift these burdens wherever possible and developed centralised databases to provide visibility.
Next generation code signing
Organisations need to start thinking in terms of creating a secure code signing process. It isn’t enough anymore to store code signing keys in a secure storage location. Additional measures need to be taken including:
- InfoSec needs to know what code signing certificates are being utilised by the organisation – both internally generated certificates and those that come from an external certificate authority
- Have a record of every code signing operation that takes place in the company, including who performed it, which piece of software was signed, what certificate was used, when it was signed, who approved the usage, and what computer was used for signing.
Control, automation, and security
- For each code signing certificate, define who has the authority to use the code signing key and who has the authority to approve each time it is used.
- InfoSec needs to be able to automatically enforce code signing policies on all development teams, BUT…
- Not inconvenience the development teams. The solution should be self serve and must work in a variety of development environments (such as DevOps) with a variety of native signing tools
- The process needs to be automated, but yet flexible. High value code signing certificates should require multiple approvers that approve every use.
- The process cannot slow down development organisations. Software release cycles used to be measured in quarters or years. Now they are measured in hours and minutes. Code signing cannot slow down this process or developers will avoid doing things the right way.
- Code signing private keys must NEVER leave a secure storage location. If someone makes just one copy and puts it on a build server, developer’s laptop, etc that key is now vulnerable to theft which means the entire company’s reputation is vulnerable.
- By having access to data such as which keys are used when and by whom, you can spot trends that could indicate risky patterns, or presence of a hacker. For example, if one particular key is used on a daily basis always at 2PM (by an automated build server), but on one particular day it was used at 2AM, then you should investigate that anomaly.
- By knowing how many code signing certificates are being used and by which teams, you have intelligence that can help establish overall risks.
Armed with this information, you will be ready to put strong processes in place. But to take this on alone would be a mammoth task. To ensure you have a comprehensive system and to mitigate weaknesses you need to implement solutions that provide visibility, intelligence and automation control over code signing for the entire enterprise.
Eddie Glenn, Senior Manager, Venafi