Emergence of a Trojan based on Stuxnet sourcecode highlights security challenges businesses continue to face.
Why let good malicious code go to waste?
That appears to be the operating ethos of whoever was behind the Stuxnet cyberattack, given the recent appearance of Duqu--aka the Trojan application W32.Duqu--which is based on the Stuxnet source code. "Stuxnet source code is not out in the wild--only the binaries. Only the original authors have the source code. So, this new backdoor was created by the same party that created Stuxnet," said Mikko Hypponen, chief research officer at F-Secure, in a blog post.
"The code similarities between Duqu and Stuxnet are obvious," he said. "Duqu's kernel driver (JMINET7.SYS) is actually so similar to Stuxnet's driver (MRXCLS.SYS) that our back-end systems actually thought it's Stuxnet."
In the history of malicious code, Stuxnet broke new ground on several fronts. First, it showed that many industrial control systems--long known to be poorly secured, if it all--really were vulnerable to malicious code, and furthermore that a digital attack could disable a physical system.
Stuxnet also highlighted that Middle Eastern countries running uranium-enrichment programs using a few specific makes and models of centrifuges and control systems should be especially alert to malware meant to disable their operations. "What we know about Stuxnet is that it was a very complex delivery mechanism just to get into a control system," said Eric Knapp, director of critical infrastructure markets for security intelligence and event management vendor NitroSecurity, in a recent interview.
Unlike Stuxnet, however, Duqu doesn't target control systems for attack. Instead, security researchers say the malware was designed to collect information for cyberespionage purposes. In addition, while the reappearance of anything Stuxnet-related would seem to be cause for concern, security researchers have said that it's a rare malware developer who doesn't reuse their code.
What did get reused, however, is interesting. "The components that were reused were not the pieces used to target SCADA/industrial control systems, but rather related driver files that provide the malware the ability to download additional components," said Chester Wisniewski, a senior security advisor at Sophos Canada, in a blog post.
With all of that in mind, what can businesses learn from the emergence of this Stuxnet-derived threat? Duqu highlights three ongoing security challenges:
1. Control systems remain vulnerable. While Duqu hasn't been attacking control systems, it is gathering related information, presumably to put to use in the future. "The attackers are looking for information such as design documents that could help them mount a future attack on an industrial control facility," according to a blog post from Symantec. "Duqu does not contain any code related to industrial control systems and is primarily a remote access Trojan (RAT)."
2. Digital certificate authorities can be bypassed. As with Stuxnet, Duqu components were signed using legitimate--but likely stolen--digital certificates, in this case for Taiwanese audio chipset manufacturer C-Media. Likewise, "Stuxnet used digital certificates which had been 'stolen' before," said Martin Kuppinger, principal analyst at identity and information security research firm KuppingerCole, in a blog post. Coming on the heels of this year's attacks against DigiNotar and Comodo, that highlights the need to strengthen current approaches to issuing and validating digital certificates.
3. Stopping one-off attacks remains tough. Many information security defenses rely on signatures, meaning that before an attack can be blocked, security vendors need to have spotted the malware elsewhere, first. Accordingly, attackers continue to refine their ability to generate so-called polymorphic malware, which is able to constantly change, and thus fool many signature-based security tools.
What can businesses that are worried about the consequences of Duqu do? Primarily, anyone using an Internet-connected or network-connected control system should ensure that appropriate security defenses are in place. "If feasible, technical isolation of these networks is a pretty good idea," said Kuppinger. Notably, if they're not online, then attacking them remotely gets more difficult.
But don't expect to spot and stop every attack. "There is no reason to assume that you are safe against attacks, whichever precautions you take," he said. In other words, even if you're not running a control system, Duqu and Stuxnet illustrate that a determined attacker can find a way into almost any network. Be prepared.
Security Job #1 For FedsThe 2014 InformationWeek Government IT Priorities Survey shows federal IT pros care about security - itís rated as very important by 69% of respondents, 30 percentage points ahead of the No. 2 priority, disaster recovery. Will the upcoming NIST cyber-security framework help manage risk?
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.