Did Duqu fix the bug that revealed Stuxnet?

 
Count DookuDuqu 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.

image_print
36 replies
  1. emptywheel says:

    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?

  2. WilliamOckham says:

    @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.

  3. orionATL says:

    if symantec can identify the virus, why can’t symantec, avg, etc., develop a detection/removal routine?

  4. WilliamOckham says:

    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.

  5. WilliamOckham says:

    @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.

  6. WilliamOckham says:

    OT (and on my own post, too):

    Reuters is reporting that the two guys in the “Scary Iran plot” have been indicted.

  7. YankeeFrank says:

    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.

  8. WilliamOckham says:

    @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.

  9. Jim White says:

    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?

  10. orionATL says:

    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.

  11. William Ockham says:

    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.

  12. MadDog says:

    @MadDog: And just as an FYI, commentary from Iran’s intelligence chief via CBS News:

    2 charged in Saudi plot; Iran rejects allegations

    Iran’s intelligence chief said Thursday there are holes in the U.S. allegations that Iranian agents plotted to kill the Saudi ambassador to the United States, and dismissed the American claims as a “foolish plot” nobody will believe…

    [snip]

    …On Thursday, Iran’s intelligence minister, Heidar Moslehi, dismissed the American allegations, saying no professional intelligence agency would issue orders to an agent in a foreign country over the phone or transfer money to drug cartels through a New York bank.

    “When you probe the allegations from an intelligence perspective, you find major contradictions and shortcomings and you can’t believe a government like the U.S. … has ended up in a situation where it designs a foolish plot,” he said on state TV…

  13. oldtree says:

    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.

  14. emptywheel says:

    WO (or anyone else):

    What do you make of the 36-day lifecycle?

    The malware is configured to run for 36 days, after which it automatically removes itself from an infected system.

  15. orionATL says:

    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.

  16. Wancia D. says:

    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 .

  17. WilliamOckham says:

    @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).

  18. WilliamOckham says:

    @orionATL: I would guess that your scenario is incredibly unlikely. As you know, the risks of messing with the HAL are huge and unpredictable.

  19. WilliamOckham says:

    @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.

  20. WilliamOckham says:

    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:

    Our lab, the Laboratory of Cryptography and System Security (CrySyS) participated in the discovery of Duqu malware within an international collaboration. While gathering deeper knowledge about its functionality, we have confirmed Duqu is a threat nearly identical to Stuxnet. After the thorough analysis of samples we prepared a detailed report about Duqu, named by us. We immediately provided competent organizations with the initial report in order to jointly step up in a professionally prepared way. Our research lab will provide the professional community and the public with all relevant details in the future as well. But we can not reveal further information about the ongoing case. Instead of speculating we encourage all professional organizations to enhance the joint process of finding a solution, since strong international collaboration will remain to play a key role.

    I wonder if they were infected or if some other organization sought them out.

  21. orionATL says:

    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.

  22. JohnLopresti says:

    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.

  23. Truth B. Hind Truths says:

    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.

  24. WilliamOckham says:

    @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.

Comments are closed.