As reported Wednesday, Symantec has discovered a malware threat that has strong similarities to the Stuxnet malware that hit the headlines this time last year. As with the original Stuxnet code, the vendor published an in-depth report on the malware, which bears a strong similarity to the original and may have been developed using the Stuxnet source code.
According to the Symantec report, Duqu – which comes in 300 kilobytes of code versus 500Kb seen in Stuxnet – could be a precursor to the “next Stuxnet” and, while it is similar to the original malware, it appears to have a different purpose, namely the gathering of intelligence on industrial control systems.
McAfee's research reveals that the code is delivered via exploitation and installs drivers and encrypted DLLs that function very similarly to the original Stuxnet code. Only a few sites, it said, are known to have been attacked by the code, and it does not have PLC (programmed logic control) functionality like Stuxnet.
Stuxnet was, the vendor claimed, possibly the most complex attack of this decade, and McAfee expects that similar attacks will appear in the near future. One thing for sure, however, is that the Stuxnet team is still active, as recent evidence has revealed.
Duqu, said McAfee, has a different goal to that of Stuxnet in that it can be used for espionage and targeted attacks against sites, such as certificate authorities (CAs).
So how does McAfee know it was the Stuxnet team behind Duqu?
To start with, said the vendor, the attacks are targeting CAs in regions occupied by 'Canis Aureus' – the Golden Jackal – to execute professional targeted attacks, against sites such as CAs.
“The threat that we call Duqu is based on Stuxnet and is very similar. Only a few sites so far are known to have been attacked by the code, and it does not have PLC functionality like Stuxnet. Instead, the code, delivered via exploitation, installs drivers and encrypted DLLs that function very similarly to the original Stuxnet code”, said McAfee in its analysis.
In fact, added the company, the new driver’s code used for the injection attack is very similar to Stuxnet, as are several encryption keys and techniques that were used in Stuxnet.
Furthermore, said McAfee, Duqu is very time sensitive, and is controlled by an extended, encrypted configuration file, communicating with a command server in India, and with an IP address that has since been blacklisted at the ISP and no longer functions.
Yet, said McAfee, it was specially crafted to execute sophisticated attacks against key targets and has remote control functionality to install new code on the target. These include keyloggers that can monitor all actions on systems: running processes, window messages, and so on.
Furthermore, added the firm, the keylogger component also contains functionality to hide files with a user-mode rootkit.
In view of its findings McAfee is advising CAs to carefully verify if their systems might have been affected by this threat or any variations.
Over at Venafi, meanwhile, the enterprise key management specialist said its research – which is ongoing – shows that, since the certificate used in Duqu is used for authentication, organizations need to look closely at their security and operations management processes and response plans.
Jeff Hudson, the firm's CEO, said that, if the Duqu creator compromised a CA to get their certificate, they could have also fraudulently issued other certificates. The security of that CA, he explained, could be called into question, as well as all the certificates it issued.
If a CA was compromised, Hudson noted that companies with certificates from that CA must replace them and all organizations must ensure they’re not trusting that CA.
Going beyond this incident, he added, 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, as seems possible, Infosecurity notes, the Duqu creator stole the private key of C-Media Electronics – the Taiwanese company whose certificate is associated with Duqu – this points to another risk that organizations need to address, that of providing better protection of private keys, Hudson went on to say.
“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.”, he explained.
Hudson concluded that 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, he said, 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.