Biz & IT —

Revealed: Stuxnet “beta’s” devious alternate attack on Iran nuke program

Version 0.5 shows cyberweapon development began two years earlier than thought.

Revealed: Stuxnet “beta’s” devious alternate attack on Iran nuke program
Aurich Lawson

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.

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.

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 state flow of a never-before-seen attack contained in Stuxnet 0.5. Rather than targeting the speed of spinning centrifuges, this new attack tampered with valves that feed gas into the cylinders.
Enlarge / The state flow of a never-before-seen attack contained in Stuxnet 0.5. Rather than targeting the speed of spinning centrifuges, this new attack tampered with valves that feed gas into the cylinders.
Symantec

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.

Symantec

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 Wired reporter 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.

Stuxnet lite

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.

Symantec

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.

Channel Ars Technica