Code signing is a contemporary standard practice in which a software developer is authenticated by a trusted certificate authority and receives certificates and private keys that can be used to sign scripts and executables.
Almost every device, operating system and web browser is hard-coded to trust as few sources as possible. It’s all done in the name of safety. When you write a piece of software and upload it to the Internet without signing it, you trigger a warning in your browser about any attempt to download the software. A warning will state that this download is from an unknown source and its content cannot be trusted.
When you code sign a piece of software, what you are doing is adding a digital signature using the private key associated with your code signing certificate. The browser itself doesn’t trust you, but if they can link your digital signature back to the trusted root, a certificate from one of the trusted cas, it will trust you because the CA vouches for you by issuing you a certificate.
In short, when you sign something properly, the browser can trace it back to a certificate it trusts, which in turn grants you trust.
Code signing is everywhere, you need it to get apps in the Apple and Android app stores, and you need it to get your software downloaded by all the major browsers. To make this practice as safe as possible, there is a validation process before release designed to weed out bad Wells and cyber criminals.
In general, one of the most common practices of certificate authorities and the digital certificate industry is “never let anything happen to your private key.” However, there is always a gap, when your private key is really public, everything is not as easy as imagined.
Researchers found a family of malware digitally signed using compromised certificates from Taiwanese technology companies, including D-Link, a multinational company that makes networking equipment.
It is not clear how the cybercriminals were able to destroy the private keys. They are known to sign off on malware with keys.
When the private key is compromised and digital signatures are applied to malware, it can fool browser filters and antivirus programs that normally scan for downloads. Let’s say the browser thinks it’s from D-Link, rather than seeing the script or executable from an unknown source, and the browser allows the download to begin. This is a very effective medium of attack.
As Hacker News explains, two pieces of malware were signed with compromised keys:
“Security researchers at ESET recently identified two families of malware previously associated with cyber espionage group BlackTech, The malware family was signed using valid digital certificates belonging to the manufacturer of D-Link network equipment and another Taiwanese security company called Changing Information Technology.”
The first piece of malware was called Plead. The Japanese Computer Security Incident Response Team (CSIRT) JPCERT conducted a full analysis of Plead in June. It’s essentially a back door to steal information and spy on people. The second piece of malware is a related password stealer that targets:
● Google Chrome ● Microsoft Internet Explorer ● Microsoft Outlook ● Mozilla Firefox ● D-Link and Change Information Technology have been notified and the certificate has been revoked on July 4th.
BlackTech will continue to use the revoked certificate to sign the malware. This may sound silly, but the problem is inspired by the vulnerability of many different antivirus solutions: they don’t scan for the validity of code signing certificates.
What should happen, as shown in the figure, is that the antivirus program will see the certificate that signed the code revoked and notify the user or block the download. Even if the malware is time-stamped, you should still be notified in advance that the certificate has been revoked. In contrast, many antivirus programs do not check validity at all, which means that expired or damaged certificates can still pose a considerable threat.
It’s not even the first time Taiwanese tech companies have been victimized. In 2010 Stuxnet was signed with stolen certificates from RealTek and JMicron.
So how to prevent the disclosure of private key?
Key breaches can lead to a cascade of problems, whether SSL certificates, code signatures, or personal authentication – all with potentially catastrophic effects. Hopefully those malware clans that get signatures won’t end up causing a big problem, but signing malware is always a dangerous proposition.
Therefore, we have put together the following suggestions:
Store your private key on an external hardware token
The idea that external hardware TokenRight now stores keys on physical hardware tokens has been largely adopted by the cryptocurrency industry, which calls it a hardware wallet. In a way, the cryptocurrency industry is an interesting test case for private key storage of any kind, because it is a platform for gold diggers, and the best place to verify encryption is with a constant stream of hackers and various people.
The cryptocurrency community (as distinct from the crypto community) has pushed a range of key storage solutions, from laminated paper wallets to sculpting physical Bitcoin sides into “cutting-edge” cold storage solutions, fancy cryptography that is so expensive it’s no novelty.
The best approach is always to keep the key offline without giving anyone a chance to get it. If D-Link and Changing Information Technology were already doing this, getting their private keys would be a criminal matter. What hacker would have time for that?
[from SSL China]