Did Duqu fix the bug that revealed Stuxnet?
Duqu isn’t Christopher Lee in Attack of the Clones, but it is the newest computer malware to hit mainstream consciousness. It’s attracting attention mainly because it is based on the same software source code base as the Windows portion of Stuxnet. If you haven’t heard about Duqu, check out the Wired article that first alerted me to its existence. If you are interested in the technical details, you need to read the excellent write-up by Symantec (pdf link).
Unfortunately, the twitterverse, blogosphere, and the computer security profession all seem to be caught up in a hype/debunking/speculation cycle that is spreading more heat than light. The primary significance of Duqu is what it tells us about the operation behind Stuxnet and Duqu, i.e. that it is an on-going enterprise conducting computer espionage and sabotage around the world. The fact that it is rather obviously (though not publicly) run by the U.S. intelligence community should concern everyone.
I’ll put up a more extensive post later (including a timeline!) detailing what the Duqu phase of the Stuxnet operation tells us about the cyberwarfare strategy of the U.S. and how it is endangering the safety and security of the U.S. and the whole industrialized world. But first, I want to remind everyone how Stuxnet was originally discovered:
… the VirusBlokAda security firm in Minsk, received what seemed to be a relatively mundane email on June 17, 2010. An Iranian firm was complaining that its computers were behaving strangely, shutting themselves down and then rebooting. Ulasen and a colleague spent a week examining the machines. Then they found Stuxnet. VirusBlokAda notified other companies in the industry, including Symantec.
This incident became curiouser and curiouser as Symantec, Langner, and others took apart Stuxnet. There wasn’t any obvious reason that Stuxnet would have caused that sort of behavior on an infected computer. I even wondered at the time whether or not Stuxnet’s cover was blown intentionally since the perpetrators moved quickly to call further attention to themselves. But, thanks to the good work of the Symantec team, we can surmise something quite revealing about the initial discovery of Stuxnet.
The rootkit component of Duqu is quite similar to, but not exactly the same as, the one in Stuxnet. In both cases, if the infected computer gets rebooted while it is infected, the rootkit wants to make sure that it is running before the operating system is fully loaded. That’s why this rootkit (both flavors, Stuxnet and Duqu) is packaged as a hardware device driver. Here’s a feature of Duqu’s driver that wasn’t present in Stuxnet (as described by Symantec on page 4 of the pdf linked above):
The driver then registers a DriverReinitializationRoutine and calls itself (up to 200 times) until it is able to detect the presence of the HAL.DLL file. This ensures the system has been initialized to a point where it can begin injecting the main DLL.
The bolded portion is the new functionality that wasn’t present in Stuxnet. As a software developer, this detail tells me a lot. The driver is checking to make sure that the hardware abstraction layer (HAL.DLL) of Windows is loaded before it proceeds with the re-infection routine. The HAL is a portion of the Windows OS that really needs to be loaded before device drivers can function properly. Between the time that Stuxnet was deployed and this later version was compiled, the Stuxnet team identified a problem (a race condition) with their software being loaded before the HAL, probably only under the rarest of circumstances. So they modified their program to take this possible condition into account.
As I thought about this, I realized that the likely impact of the Stuxnet device driver being loaded before the HAL was properly initialized would almost certainly be that the machine would continuously crash and reboot. Look again at how Stuxnet was first discovered (remember it was in the wild for at least a full year before it was noticed by any anti-virus vendor):
… the VirusBlokAda security firm in Minsk, received what seemed to be a relatively mundane email on June 17, 2010. An Iranian firm was complaining that its computers were behaving strangely, shutting themselves down and then rebooting. Ulasen and a colleague spent a week examining the machines. Then they found Stuxnet. VirusBlokAda notified other companies in the industry, including Symantec.
By November 3, 2010 (the compile date of the Duqu component), the Stuxnet team had fixed the bug that led to the discovery of Stuxnet last year. And then went almost another full year without being discovered by the anti-virus vendors. It is likely to be a lot harder to reconstruct what the Stuxnet team has been up to this time around, but it is clear that the operation is on-going and we can assume (unless specific information turns up pointing in a different direction) that the primary target is still the Iranian nuclear program.
WO
Thanks so much for doing this.
So do you think they just kept working on Duqu all the way through, or that they saw the bug, and immediately set about trying to fix it?
And does this have anything to do with what Aaron Barr found here?
@emptywheel: I think the Stuxnet operation has been on-going for at least 3 years. I suspect they fixed the Stuxnet bug almost immediately. They obviously have a testing lab that they use to ensure that the stuff they put out isn’t identified by any of the major A-V vendors.
Barr was obviously trying to get contracts to create stuff like this, but I haven’t seen any evidence he was involved in the Stuxnet operation.
if symantec can identify the virus, why can’t symantec, avg, etc., develop a detection/removal routine?
Just in case anyone is wondering why you should care about this, I just saw a tweet from someone attending the Grid Security Conference. Apparently Dillon Beresford (a well-known white hat hacker who specializes in industrial control systems) just demo’ed a hack of a piece of ICS software and showed how to use it to install the infostealer component of Duqu on to any system running that software. Because the infostealer (also known as a RAT for remote access trojan)is a separate executable, it will be much easier to repurpose than the other pieces of Stuxnet/Duqu.
@orionATL: They (and all the other A-V vendors) can now after it was manually brought to their attention. But will be very easy for the Stuxnet team to recompile with just enough changes to get past the “signatures” that they are using to identify it now. The Stuxnet team just needs to make a few changes and run it through their lab to check to see how many A-V products catch it. Then, rinse and repeat until the malware is invisible to all the major products and get back to work on placing this crap on the target PCs.
OT (and on my own post, too):
Reuters is reporting that the two guys in the “Scary Iran plot” have been indicted.
Innaresting. So if I understand correctly, the only reason the stuxnet virus was detected at all was that windows, for some reason, was loading it prior to the hal, and then the pc would crash since device drivers depend on hal. Since device drivers require the hal in order to operate on the last decade’s worth of windows OS’s, it is odd that the OS would load one prior to loading the hal. Just another bit of windows weirdness I guess, though this time it proved fortuitous.
@YankeeFrank: The HAL always starts loading before device drivers. For some unknown reason, there were a some PCs in Iran that had particularly slowly loading HALs so that the HAL didn’t finish loading before the Stuxnet device driver. Given the variety of hardware that will run Windows, even the most unlikely scenarios will play out occasionally. As a side note, knowing how your code will run on slow hardware is usually the software developer’s biggest blind spot. We always want the latest, greatest, fastest hardware around. We usually get pretty fast hardware.
Is there any reason to think that, in addition to the known Iranian targets any of this technology, it is being used against other targets, especially ones the US would like to keep an eye on? It seems to me that the basic parts (invisible rootkit and a callable keylogger) would make for powerful surveillance technology.
No, I’m not paranoid at all. Why would you ask?
@Jim White: North Korea does come to mind.
it seems that duqu and stuxnet are to software in war, what drones are to hardware in war –
unusual refinements of existing technology that have suddenly greatly expanded the reach of war,
and are in the process of redefining (once cheap drones are available) who can play the war game.
i’d predict that this box is going to be as hard to close as the nuclear one.
what a mess we humans are creating for ourselves.
@WilliamOckham: Yup. It’s not in the docket yet, and I don’t think I’ve gotten the announcement from DOJ.
MadDog and Jim White,
No evidence just yet, but plenty of reason to be suspicious. We need more info about the targets of Duqu. I am currently looking at the similarities and differences between the various components to see what we can gather about the pre-Stuxnet rootkit that must have existed.
@MadDog: Heh. I was thinking more of domestic individuals…
@emptywheel: The AP has the news as well, but no link to the indictment.
Anonymity and full access. What individual/government would willingly overlook or underuse this power?
@MadDog: And just as an FYI, commentary from Iran’s intelligence chief via CBS News:
Who would use a windows computer knowing they are designed to fail like this? Is it masochism? When you have companies that do nothing except fight contamination of virus in windows machines, do you not realize it is the goal of microslop to profit from this?
It is incredible that people would voluntarily offer their information to the world by using something designed to give it up. It is even more strange that a government would consider using it for a sensitive operation where it has never, and can never be trusted. How is that FBI computer program they bought working out? Have they canned it yet and moved to open source? Oh, the humanity.
@MadDog: Okay–I’ve put up a Scary Iran Plot post–so any more updates you can put there.
@oldtree: Tis not just limited to Windows usage. Folks who use an iPhone or an iPad 3G are recording their own geolocations and likely not even knowing it.
WO (or anyone else):
What do you make of the 36-day lifecycle?
i am glad comments here are finally getting back to the topic of the wm.okm. essay. this is serious stuff.
stuxnet is an important new weapon with, i suspect, not well understood consequences.
when one installs the win os, xp for example, one has the option, at the very beginning, to mess with win hal (hardware application layer)
my bitter personal experience as a diy computer builder is: “don’t never, ever do that. ever”
but an experienced iranian systems programmer might decide to play with the hal options, options which are tied in with ms power control/saving features,
or,
an inexperienced iranian systems programmer might make an error in his hal choice as he installs win xx.
my question is: would it be possible to use the iranian choice of hal (if it were known) to completely defeat stuxnet/ duqu?
yes, the computer would not run (start,abort,resart, etc),
but one would have a salient warning of the possible presence of duqu/stux.
Are they still running a lot of Lenovos in Iran? That might be a place to start.
The computer malware Stuxnet has been tough for many computer experts to determine. In 2010, it infected nuclear control systems in Iran. Industrial control computers in Europe have been infected with a brand new malware. The Duqu virus doesn’t appear to have direct influence, but mines for information that could be used for further attacks. The big news is Duqu virus uses Stuxnet DNA to mine industrial data .
@emptywheel: I think the reason for the lifecycle is pretty obvious. They are going to a great deal of trouble to stay under the radar of A-V software. They want to ensure that if they lose contact with an infected machine (for example, a laptop that goes off the internet for an extended period) their software cleans itself up. As to the exact period (36 days), my only guess is that they heuristically choose that based on the frequency of virus definition updates and the periodicity of their own deployment cycle. I suppose it represents 5 weeks + 1 day (to account for time zones, maybe).
@orionATL: I would guess that your scenario is incredibly unlikely. As you know, the risks of messing with the HAL are huge and unpredictable.
@WilliamOckham: One more thing on the 36 day cycle. Before the command and control (C&C) server was taken down, Symantec observed duqu downloading an update that extended that infection’s lifecycle by another 36 days. So, they are obvioulsy prepared for opportunities to keep the infection alive when they are still looking for more information on a particular machine.
Also, I wonder if the fact that the C&C server got taken down is preventing them from pulling current infections back off machines.
For anyone still following this post, the European research lab who discovered and named Duqu has chosen to come forward:
The Laboratory of Cryptography and System Security at Budapest University of Technology and Economics.
Here is their statement about Duqu:
I wonder if they were infected or if some other organization sought them out.
wm ockham-
your first two posts on stuxnet have been an education. i do hope you will continue with a third (or more).
i’m intrigued by this statement:
“I’ll put up a more extensive post later (including a timeline!) detailing what the Duqu phase of the Stuxnet operation tells us about the cyberwarfare strategy of the U.S. and how it is endangering the safety and security of the U.S. and the whole industrialized world.”
i can imagine a few bad things from malware that targets industrial processes. i will wait with interest for that next post.
@orionATL: I’m working on it. I do have to occasionally do work on my day job…
@WilliamOckham:
yes, there is that little matter of bread and a roof :)
thanks for your efforts.
I wonder how the stux discussion in the blogpost correlates with what I remember as friar W.Ockham’s much earlier comment to the effect that the fuge motor scada pathway exploit utilizing stux involved somewhat of a shrinkwrap util modified in a simplistic way. Also, recalling a personal extranet IT responsibility I had once, I would think beyond just scada hacks of motors’ controller boards as in the foregoing sentence here, and examine the pulsetrains of chipsets. The incident I reference was a modem shelf freshly installed but discovered to have nonstandard responses to the server; then someone went thru the modem chipsets and discovered they were shipped after the extranet spec was written, and were populated with chips built to a later, unforeseen design. I once saw a funny article by a firmware codewriter gent working as an independent contractor for a Detroit car mfgr, who admitted a few bugs with car computers because of ancient code of his still used by engines.
I noticed prof Ockham’s Hungarian excerpt’s claim of participating in naming the instant virus, and, at first thought of some people who organized an accredited studies program and founded a small regional university called “Deganawidah-Quetzalcoatl University”, usually called D Q Univ; but that was nothing to do with duqu and took place several decades prior. However, and OT, I located a prof’s obit from that dq there.
The USA had very little to do with Stuxnet and almost nil with regards to Duqu. Uncle Sam supplied the ex-libyan uranium enrichment centrifuge set which was erected at Dimona and used to test-cycle Stuxnet prototype code. That’s it.
All the programming work on Stuxnet and Duqu malware came from the Unit 8200 electronic warfare branch of the zionist military. Since Tel-Aviv is untouchable in the UN due to USA veto power, they can do whatever they want with impunity.
The BitDefender anti-virus scan engine (also licence-used by at least four other AV vendors) detected the DuQu trojan from the first minute, using super-deep heuristics.
@Truth B. Hind Truths: What’s your source for the assertion that the Israelis did all the coding? I haven’t seen any Israeli sources making that claim and I have seen several anonymous U.S. sources claiming otherwise.
@Truth B. Hind Truths: If by “from the first minute”, you mean at least eight months after it was released, then sure.