News and analysis started coming out Tuesday about the Duqu Trojan and the threat vectors it represents. The two primary sources of information are McAfee and Symantec. Their posts have some notable differences about an important detail of the attack: how the creator of Duqu was able to get a bona fide certificate that allows Duqu to authenticate itself as trusted code.
McAfee says the following: “It is highly likely that this key, just like the previous two known cases, was not really stolen from the actual companies, but instead directly generated in the name of such companies at a CA as part of a direct attack.” (Seehttp://blogs.mcafee.com/mcafee-labs/the-day-of-the-golden-jackal-%e2%80%93-further-tales-of-the-stuxnet-files/comment-page-1#comment-173796).
Symantec says: “Our investigation into the key’s usage leads us to the conclusion that the private key used for signing Duqu was stolen, and not fraudulently generated for the purpose of this malware.” (Seehttp://www.symantec.com/connect/w32_duqu_precursor_next_stuxnet).
We’re hoping to get more information so we can figure out if the authentication certificate was acquired via a private key compromise or CA compromise. That said, since the certificate used in Duqu is used for authentication—much like SSL server- and client-side certificates—either cause should warrant that organizations look closely at their security and operations management processes and response plans. Certificates are used for authentication, in addition to encryption.
Let’s look at both use cases:
CA Compromise
If the Duqu creator compromised a CA to get their certificate, they could have also fraudulently issued other certificates. The security of that CA could be called into question, as well as all the certificates it issued.
To add fuel to the fire, McAfee’s post also says, “McAfee Labs received a kit from an independent team of researchers that is closely related to the original Stuxnet worm, but with a different goal–to be used for espionage and targeted attacks against sites such as Certificate Authorities (CAs).”
They go on to say, “To start with, the attacks are targeting CAs in regions occupied by “Canis Aureus,” the Golden Jackal, to execute professional targeted attacks against sites such as small CAs, industry systems, and others.”
If a CA was compromised, companies with certificates from that CA must replace them and all organizations must ensure they’re not trusting that CA. Going beyond this incident, if Duqu is targeting CAs, that reinforces the importance of preparing for a CA compromise, especially coming on the heels of the DigiNotar CA breach this summer.
If you’re looking for best practices on how to prepare for and/or respond to a CA compromise, we’ve provided detailed best practices in a PDF at www.venafi.com/CACompromise on the steps organizations should take for CA compromises.
Private Key Compromise
If the Duqu creator stole the private key of C-Media Electronics (the Taiwanese company whose certificate is associated with Duqu), that points to another risk that organizations need to address: providing better protection of private keys.
In a Symantec blog responding to Duqu, Fran Rosch (vice president of Trust Services at Symantec) says, “We have long advocated best practices for safeguarding private keys.” He goes on to recommend several best practices, including 1) separating test and release signing keys, 2) using hardware security modules, and 3) physical security. For #3, physical security, he points out, “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.”
These are good, high-level recommendations. However, the #2 recommendation may not be practical for corporations to implement any time soon (since it would involve purchasing hundreds of HSMs, which are pretty pricey) and most private keys are readily accessible by “insiders” in most organizations, which makes effective implementation of #3 difficult.
Most corporations have hundreds or thousands of private keys (code signing, SSL, etc.). It’s safe to say that over 90% of those private keys used in corporations today are stored on disk, not in hardware security modules (HSMs). Those private keys are largely handled directly by system administrators who can easily make copies of them, increasing the likelihood of a private key compromise when an administrator gets reassigned, fired, etc.
Most organizations assume that when they contract with a CA (e.g. VeriSign, Thawte, Comodo, etc.) that they’re covered from a security perspective. The reality is that these CAs don’t help manage the private keys so administrators have to manage them manually, significantly undermining “physical security.” If organizations are going to implement physical security on private keys, they have to implement automated tools that manage those keys and don’t require administrators to have direct access to them.
