Every year for the past 10 to 20 years has seemingly been the year of public key infrastructure (PKI). The many
benefits of PKI, the underlying technology supporting virtually all types of encryption used on the Internet, have made it a cornerstone of enterprise information security programs. However, there is one major downside to PKI outside of its deployment difficulties: digitally signed malware.
The process relies on the assumption that all digitally signed software is in fact from the vendor and not malicious.
In this tip, I explore the threat digitally signed malware poses and the strategies enterprises can use to stay protected from this risk.
Digitally signed malware: Infiltration and enterprise threats
Digitally signed malware is similar to other malware except that it has been signed by a certificate that is typically trusted inherently by an endpoint. Many vendors today use a code-signing certificate to demonstrate to customers that a given .exe file is legitimately from the vendor, and not a malicious file disguised as a legitimate one. In the enterprise, many different platforms, including Windows, Apple and Android, use digitally signed software to manage which programs may be installed on their systems. Enterprises can establish which digitally signed software is safe and whitelist the approved executables to bypass the sandboxing process and expedite download.
However, the process relies on the assumption that all digitally signed software is in fact from the vendor. Unfortunately, this isn't always the case; hackers are finding new ways to permeate enterprise networks using seemingly legitimate digitally signed malware.
To bypass platform protections and appear as a trusted executable, malware must find a way to get a valid signature. In most cases, it's way too easy: Digitally signed malware posing as a trusted certificate will be allowed in thanks to being on the enterprise whitelist and avoid the sandboxing process. If there aren't any other security protections in place that can identify the file as malicious, the malware will be able to compromise the system.
So how can an attacker get his or her malware signed? This can be accomplished by either getting a code-signing certificate illegitimately or by compromising a vendor's signing process. Attacking the registration authority part of the PKI is easiest way to get an illegitimate code-signing certificate. Attacking the code-signing infrastructure is typically much more difficult because vendors understand there are high-security requirements for the code-signing process.
Once signed, endpoints assume the executable is from a trusted vendor, and therefore trustworthy. For example, Adobe had a security incident where one of its code-signing certificates was compromised and used by hackers to sign two known malicious files. Any attacker could act similarly and steal the code signing certificate and then use it to sign as many files as they wanted with little chance of detection. Once malicious files are signed and running on the target system, they can perform any action that the currently logged-in user is allowed to perform and will not receive a warning about running an unsigned executable. Alternately, attackers could use the existing code-signing infrastructure to sign files, but that might be easier for a vendor to detect.
Enterprise protections from digitally signed malware
While standard malware protection should already be in place in every enterprise network, there are a few additional defensive steps I suggest to specifically protect against digitally signed malware:
- Don't allow users to root or jailbreak their mobile devices. This allows unsigned or unauthorized application stores to be used, subverting devices' built-in protections against digitally signed malware.
- Only run software from legitimate application stores and vendors because their owners perform additional scans on top of just checking for signed files.
- Verify all MD5 or SHA1 hashes for downloaded software match the hashes from the vendors. This requires strong knowledge of all downloaded software and also significant effort from an enterprise. It may not be possible to achieve for all products, as not all vendors publish the hashes for their files.
- Whitelisting can be used to reduce the risk of unauthorized downloads by only allowing in files signed by certain code signing certificates or from specific certificate authorities.
- Blacklisting can also be helpful. When a malicious code signing certificate is identified, be sure to blacklist any files signed by this certificate from executing on the system. Additionally, enterprises should check certificate revocation lists (CRLs) to see if certain certificates or authorities should be blocked.
If a file is identified or blocked using any of the aforementioned methods, it could be submitted to antimalware vendors to add to their software for additional protection.
Software vendors also play a vital role in minimizing the chance of malicious software from being signed. Vendors must ensure that the certificate used for code signing is kept secure and never allow the certificate to be copied out of the environment. Additionally, requiring dual control to use the certificate would add significant complexity and resource needs for signing software and may thwart many hackers. All code signing certificates should also have a short life to minimize the time frame in which it could be used if it were to be stolen. Vendors could also frequent CRLs to discover if one of their code signing certificates is listed for revocation and then analyze the source to determine any suspicious actions.
Using PKI as part of an enterprise security strategy is critical for providing high levels of assurance and better protecting endpoints from malware. In theory, it is a good idea to use digital signatures on software to boost security. Unfortunately, these signatures are often hampered not only by implementation difficulties but also the growing sophistication and cunningness of hackers, as evidenced in the emergence of digitally signed malware. This threat goes to prove that blindly trusting signed software -- or anything, for that matter -- can lead to highly undesirable results. Fortunately, with a strong foundation in malware defense and a few extra configuration changes, enterprises can help greatly increase the trust in digitally signed software and improve endpoint security.