Stuxnet 0.5 is the oldest known version of the computer worm and was in development no later than November of 2005, almost two years earlier than previously known, according to researchers from security firm Symantec. The earlier iteration, which was in the wild no later than November 2007, wielded an alternate attack strategy that disrupted Iran's nuclear program by surreptitiously closing valves in that country's Natanz uranium enrichment facility. Later versions scrapped that attack in favor of one that caused centrifuges to spin erratically. The timing and additional attack method are a testament to the technical sophistication and dedication of its developers, who reportedly developed Stuxnet under a covert operation sponsored by the US and Israeli governments. It was reportedly personally authorized by Presidents Bush and Obama.Researchers have uncovered a never-before-seen version of Stuxnet. The discovery sheds new light on the evolution of the powerful cyberweapon that made history when it successfully sabotaged an Iranian uranium-enrichment facility in 2009.
Also significant, version 0.5 shows that its creators were some of the same developers who built Flame, the highly advanced espionage malware also known as Flamer that targeted sensitive Iranian computers. Although researchers from competing antivirus provider Kaspersky Lab previously discovered a small chunk of the Flame code in a later version of Stuxnet, the release unearthed by Symantec shows that the code sharing was once so broad that the two covert projects were inextricably linked.
"What we can conclude from this is that Stuxnet coders had access to Flamer source code, and they were originally using the Flamer source code for the Stuxnet project," said Liam O'Murchu, manager of operations for Symantec Security Response. "With version 0.5 of Stuxnet, we can say that the developers had access to the exact same code. They were not just using shared components. They were using the exact same code to build the projects. And then, at some point, the development [of Stuxnet and Flame] went in two different directions."
Symantec officials announced the discovery on Tuesday at the RSA security conference in San Francisco. A paper outlining the researchers' findings is here.
The 600K worth of code found in Stuxnet 0.5 is highly modular, just as it was in the 500K Stuxnet 1.0. The encryption algorithms, string objects, and logging functions in the earlier version are almost identical to those of Flame. In contrast, the later Stuxnet version largely eschewed the development conventions of Flame, as Stuxnet developers adhered more to the so-called tilded platform shared with Duqu, another piece of sophisticated espionage malware that targeted Middle Eastern computer systems.
Most significantly, the earlier Stuxnet version contained an alternate method of sabotaging Iran's nuclear-enrichment process, the details of which had never been fully understood. It injected malicious code into the instructions sent to 417 series programmable logic controllers (PLCs) made by the German conglomerate Siemens. Natanz engineers used the PLCs to open and shut valves that fed Uranium hexafluoride, or UF6 gas, into centrifuge groupings. Stuxnet 0.5 closed specific valves prematurely, causing pressure to grow as much as five times higher than normal. Under those conditions, the gas would likely turn into a solid and destroy the centrifuges, possibly even the sensitive equipment used to develop them.
One of the domain names hardcoded into version 0.5 was registered in November 2005, while data on malware-scanning service VirusTotal shows that the version was in the wild no later than November 2007. This means that Stuxnet attackers' detailed familiarity with Iran's nuclear facilities dates back much earlier than previously known. It suggests espionage malware such as Flame, Duqu, or a still-unknown title had burrowed into Iranian systems in the months or years prior to the beginning of the development work.
"The attacker had to have extremely good knowledge of how Natanz operated in order to build this code," O'Murchu said of version 0.5. "They also needed to know the exact layout of the cascade and centrifuges, and they needed to know that they were using 417 PLCs."
Stuxnet 0.5 was programmed to wait 30 to 35 days between the time it took control of a computer and the time it launched the valve attack, which took two to three hours to complete. That month-long wait gave the program time to gather normal equipment readings that would be replayed while the attack was in progress to prevent operators from knowing anything was amiss in the enrichment process. The malware also contained code that prevented engineers from manipulating the valves during the attack. Like later versions, Stuxnet 0.5 was programmed to attack only equipment containing labels found in Iran's Natanz facility, presumably to prevent malfunctions in other plants. The ability to capture normal readings and replay them during the attack was another characteristic found in later Stuxnet versions.
Up to now, however, no one has seen the attack targeting the valves. Instead, as reported by Wiredreporter Kim Zetter in 2011, Stuxnet 1.x versions used an entirely different attack strategy that tampered with the computerized frequency converters controlling the speed at which centrifuges spun during the enrichment process. By injecting code into the PLCs that controlled the centrifuge speeds, 1.x versions caused them to spin too fast and then spin too slow, resulting in fatal damage to key parts of the enrichment process.
Unlike later versions of the worm, 0.5 used a single exploit to spread from computer to computer. Specifically, it exploited a vulnerability in the Siemens Simatic Step7 software that developers use to program PLCs. Once a computer was infected, any removable drive connected to it that contained Step7 files would be infected. When the infected USB drive was later plugged into another computer, it would become infected as soon as the user opened the malicious Step7 files. The exploit was dubbed a "DLL preloading attack" because it allowed Stuxnet to execute malicious dynamic link library (DLL) files on targeted computers running Microsoft Windows.
O'Murchu said there's no way of knowing if Stuxnet 0.5 ever carried out the highly advanced attack on the Siemens 417 controllers inside Natanz. It's also impossible to know how many systems were infected by it. But given changes that were introduced in subsequent versions, it's reasonable to speculate that Stuxnet developers were unhappy with the infection rate of the earlier version and sought new ways to make their malware more aggressive.
Specifically, later versions of Stuxnet relied on at least five previously unknown vulnerabilities to self replicate, including two zero-day vulnerabilities in Windows that caused Stuxnet to infect computers as soon as a compromised USB drive was connected. As a result, 1.x versions ended up leaving a wide swath of collateral damage when they infected an estimated 100,000 computers, the vast majority of which had nothing to do with Iran's uranium-enrichment program. While the PLC attacks were only activated on computers located in the Natanz facility, the mass infection still proved costly to network operators all over the world.
The 100,000 estimate is based on Symantec's success in "sinkholing" Stuxnet command and control channels by getting traffic from infected machines rerouted to servers under the control of the security company. Because traffic from 0.5-infected machines was never commandeered, there's no way of knowing how many systems were compromised by the earlier Stuxnet, although O'Murchu believes it was certainly much lower than later versions. If the speculation is right, the contrasting infection mechanisms underscore the difficult balance Stuxnet developers sought between a cyberweapon that spread too aggressively and one that wasn't able to spread widely enough.
The targeting of valves in Version 0.5 instead of centrifuge speeds in 1.x also demonstrates the contrasting strategies for sabotaging the uranium-enrichment process once Stuxnet took hold. Although signs of the attack targeting the 417 PLCs can be found in later versions, crucial values needed to carry out the attack were stripped out, making it impossible for researchers to know exactly what the exploit did. It remains unclear why later versions of Stuxnet pursued the alternate strategy targeting the Siemens 315 PLCs that controlled the frequency converters of the centrifuges.
"Perhaps the attackers decided the 417 code wasn't working, so they went with the simpler 315 attack strategy instead," O'Murchu said. "Or perhaps they thought the [Natanz] operators had figured out the problems with the valves and then worked around it and they decided to go with a different attack strategy in 315 just to mix things up."
Also making it hard to track the success of Stuxnet 0.5 is the absence of any data indicating an early disruption in operations at the Natanz facility. By contrast, in January 2010, inspectors with the International Atomic Energy Agency detected Natanz technicians jettisoning between 1,000 and 2,000 damaged centrifuges, numbers consistent with the specific attack contained in 1.x versions. There is no analogous data pointing to the success of the earlier malware.
“Deliver what the mind can dream”
The newly discovered version 0.5 also displays similarities to Flame in the way the attackers went about camouflaging the command-and-control servers used to send updates to infected machines. The earlier Stuxnet was programmed to connect to servers with four different domain names, each disguised as hosting a website for a nonexistent advertising agency called Media Suffix. The sites included smartclick.org, best-advertising.net, internetadvertising4u.com, and ad-marketing.net. Ominously, their tagline, according to archived pages of the now defunct sites, read: "Deliver what the mind can dream."
Similarly, the Flame espionage malware relied on servers that were disguised as publishing platforms running a fictitious content management application called Newsforyou. The disguises reduced the chances that the true purpose of sites would be discovered by people working at the data centers where they were hosted or by people who happened upon the sites while browsing the Internet.
Interestingly, the command servers had considerably less granular control over machines infected by Stuxnet 0.5 than they did over machines compromised by later versions. These earlier servers could only issue software updates, compared with command servers that received data about installed software and internal and external IP addresses on machines infected by later versions. Version 0.5 was also programmed to stop connecting to command servers on January 11, 2009 and to stop infecting new machines on July 4 of the same year.
A peer-to-peer update mechanism ensured that even non-Internet-connected machines inside a network would receive revised software based on the Stuxnet 0.5 release. It relied on a Windows component known as Mailslots. A Stuxnet-infected computer would use it to advertise its current version to other compromised machines. Stuxnet code would then use Mailslots to ensure any out-of-date machines received the latest patch. Versions 1.x of Stuxnet also featured peer-to-peer updating, although it relied on a technology known as remote procedure call.
"It's interesting, because the targeted network for the Stuxnet attacks is known to be a non-Internet connected, or limited Internet connectivity, network, so being able to spread updates via a peer-to-peer mechanism is very important," O'Murchu said. Stuxnet developers "couldn't be dependent on Stuxnet waiting for a command from the C&C [server] before it dropped its malicious payload because when it got to the network that it really wanted to infect—you know, the uranium enrichment facility—it wouldn't have Internet connectivity. So it all fits in with what we expect from Stuxnet and what we've seen with Stuxnet 1.0."
In addition to not knowing how many systems were infected by Stuxnet 0.5 and whether its payload targeting centrifuge valves was ever executed, Symantec researchers—who besides O'Murchu also included Geoff McDonald, Stephen Doherty, and Eric Chien—still don't know exactly how the early version made its initial foray into the wild. They suspect attackers intended someone who works on Step7 projects with or in the Natanz facility to unwittingly unleash the worm, but there's no way right now to confirm that.
What is clear is that the work on the sophisticated malware used to launch a surgical strike on Iran's nuclear program was undertaken no later than 2005, some five years before there's any confirmation that it succeeded in its goal of disrupting that country's uranium-enrichment process. Not only does that mean the operation began sooner than previously known, but work also dates back to an era in which malware was considerably cruder in quality in comparison to today.
"That's a five- or six-year period there where the [Stuxnet] attackers were coming up with these incredibly advanced strategies for the time to attack these facilities," O'Murchu said. "Back in 2005, we were dealing with hackers who were still doing it for notoriety—you know, people who were working out of their basement. I think that's really quite amazing when you look at what else was going on in 2005. It stands out even more than it did before."
Article updated to correct wording of the tagline on Media Suffix pages, change language in second paragraph regarding alternate attack method.