News and analysis started coming out last week about the Duqu Trojan and the threat which 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.”
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.”
I’m hoping to get more information so I can establish 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 organisations 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:
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 organisations 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.
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 organisations 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 organisations 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 organisations 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.
The Stuxnet malware incident offered a clarion wakeup call to IT security, as it intentionally exploited the poor management practices that exist in many organisations today. The first consideration was how a compromised Verisign digital certificate was leveraged in the attack. The signed certificate was used to authenticate itself within the environment, thereby allowing the malware to act as a trusted application to communicate with other devices.
This was the first reported incident of a digital certificate being deployed in this type of attack, and this new variant gives our original warning more relevance. Organisations must maintain a complete inventory of all certificates issued by certificate authorities, monitor them, and know which ones are within policy. That way, administrators will know which ones aren’t compliant and revoke them.