Yesterday Kaspersky Lab posted on their research blog that they had discovered a Trojan dropper file in the wild. The malicious code, designed to commit click fraud, was signed by a legitimately issued VeriSign code signing certificate. This was a result of private keys being compromised at one of our customers. The code signing certificate used to sign the malicious code was authenticated and issued by VeriSign to a legitimate organization. The certificate has since been revoked, as it appears that the private keys, which were controlled by the customer, have been compromised.
Allow me to emphasize that Symantec takes these situations very seriously. We’re working closely with the customer to resolve their security issue and to ensure that they are taking precautions and applying best practices for private key before we re-issue another code signing certificate to them. Symantec employs the highest levels of stringent authentication for every certificate we issue. This was not in any way a breach of Symantec’s network or infrastructure. Symantec strongly encourages organizations worldwide to follow security best practices to protect the integrity of their private code signing keys.
Secure your digital certificates, secure your private keys, wash, repeat.
I’ve said it this before, but I feel that it bears repeating: If you own or control a digital certificate – whether it be for SSL, code signing, or to sign documents – it is critical that you safeguard your private keys. If an attacker can steal a code signing private key from your private business network, you have to assume that other data in your network is at risk, including customer information, employee files and intellectual property. As it is our responsibility as a CA to thoroughly authenticate each organization that applies for a code signing certificate, it also the responsibility of the certificate owners to protect those certificates from becoming compromised. When malicious code makes its way into the wild, it hurts everyone.
Now, I won’t speculate as to how the customer in question was compromised, however I strongly urge that any organization that controls code signing certificates employ the following recommendations to better protect it’s private keys:
· Separate Test Signing and Release Signing – It is best practice to set up a parallel code signing infrastructure using test certificates generated by an internal test root certificate authority. This ensures that business-critical private certificates used to sign officially released software aren’t stored on insecure build systems used for routine R&D software development tasks, reducing the likelihood that they will be compromised.
· Cryptographic Hardware Modules– Keys stored in software on general-purpose computers are susceptible to compromise. Therefore it is more secure, and best practice, to store keys in secure, tamper-proof, cryptographic hardware devices.
· Physical Security – There is no security without physical security. If it’s possible for an outsider, or malicious insider, to gain unnecessary access to code signing keys then all the cryptography measures are for naught. Cameras, guards, fingerprint scanners and additional measures are all appropriate to protect critical assets and should be taken seriously.
Think of it this way: by hardening your network you not only protect your business, you’re also helping to win the war against cyber-crime.