Attacks/Breaches
2/26/2013
10:46 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

Stuxnet, The Prequel: Earlier Version Of Cyberweapon Discovered

Symantec finds 'missing link' in infamous Stuxnet malware that sabotages another piece of equipment in Iranian nuclear facility--attackers became more aggressive as campaign ensued

SAN FRANCISCO -- RSA CONFERENCE 2013 – Researchers at Symantec have identified an earlier version of the Stuxnet malware that shows that the cyberattacks on Iran's Natanz nuclear plant date back as early as 2005 and targeted another piece of uranium-enrichment equipment.

RSA Conference 2013
Click here for more articles.

Symantec found what it calls Stuxnet version 0.5 of the sophisticated cyberweapon among the samples it had collected from the version of the malware that was first discovered in the wild back in July 2010 and was created in 2009. The newly detected version of Stuxnet was in action mainly between 2007 and 2009, according to Symantec.. The cyberweapon malware was reportedly launched by the U.S. and Israel against Iran's nuclear facility to derail the possible development of nuclear weapons.

"This [version 0.5] was not new in the wild. We looked back through our Stuxnet samples and found a component that didn't fit," says Liam O Murchu, manager of North American operations for Symantec Security Technology & Response. After studying the malware more closely, Symantec found it was indeed an older version of Stuxnet, and the security firm has detected a small number of machines around the world infected with the older Stuxnet—albeit dormant infections.

There may even other Stuxnet versions that predate 0.5, because there are signs of activity back in 2005 as well, when the attackers registered domain names for the attacks, O Murchu says. "This may not be first" Stuxnet iteration, he says. "There's a chance there could be an older version than this."

The new timeline and malware version reveal how the attackers became increasingly aggressive in their attacks with the later versions of the malware, O Murchu says. "As you go up through Version 1, you see more zero-day exploits being added," he says. Another puzzle it solves: Stuxnet was definitely based on the Flame/Flamer/TildeD, malware platform as many researchers had theorized, and the writers of those malware families are either one in the same or work closely together, he says.

Flame is a cyberespionage platform used for gathering intelligence. Kaspersky Lab n June of last year found what was the first true link between the two targeted malware families -- shared source code, indicating that the efforts were intertwined.

"With 0.5, we see Flamer code .. so we know when they created the original Stuxnet, they used Flamer. It was probably one team using the same source code, then Stuxnet was developed and that went in one direction, and Flamer in another," O Murchu says.

[Experiment shows how the infamous cyberespionage families can be repurposed -- with exceptions -- in other attacks. See A Flame, Duqu Test-Drive.]

Unlike Stuxnet 1.10, which disrupted and is believed to have damaged the plant's centrifuges used to enrich uranium by attacking the Siemens PLC equipment that ran them, Stuxnet 0.5 went after the Siemens 417 PLCs that operate the valves that feed uranium hexaflouride gas into the uranium enrichment centrifuges. The attack closes the valves, one of which releases depleted uranium, and the other, enriched uranium, which would seriously damage the equipment and sabotage the uranium enrichment process. "In one of the attack scenarios with this code, it turns off the vales at both ends, so no gases are leaving," O Murchu says. The pressure buildup could turn the gas to a solid and ultimately damage the equipment as well, he says.

That solves the PLC 417 mystery in Stuxnet 1.10, which included a nonworking version of a payload attacking those PLCs. That nonfunctional element in the Stuxnet 1.01 had baffled researchers who studied the malware. "For me, it was interesting that Siemens PLC 417 was targeted [in 0.5], as everybody said this was broken in the 'new' Stuxnet," says Boldizsar Bencsath, a member of the CrySys Lab that was instrumental in studying Duqu, a related malware family to Stuxnet.

"It's also strange that it was built on Flame, but basically not that surprising. We already expected that Flame is rather old, and that parts of the code were used in different projects and that these campaigns -- Duqu, Flame, Stuxnet, Gauss, SPE etc. – are related in some way," Bencsath says. "For each goal, they probably used a different tool, but the whole campaign is still the same."

It appears the attackers knew the system and actual code that was deployed in the Iranian facility, he says. "They had surely important information about the system, but the careful design of the attack makes it possible to interact with a not exactly known system-- a system that is slightly different from the original target goal, or a system for what the attacker does not have all details," he says.

Symantec says the 0.5 version of Stuxnet was set to stop spreading on Independence Day--July 4-- of 2009, the same year version 1.10 was written. It spreads via now-patched Siemens Simatic Step 7 programming software used in PLC environments. The malware takes great pains to hide an attack: it takes snapshots of a normal system state and replays those views to fool plant operators into thinking the system is working normally. It also prevents any valve adjustments by the operator during an attack.

"Whether Stuxnet 0.5 was successful is unclear, but later versions of Stuxnet were developed using a different development framework, became more aggressive, and employed a different attack strategy that changed the speeds of the centrifuges instead suggesting Stuxnet 0.5 did not completely fulfill the attacker’s goals," according to a white paper released today by Symantec.

Still, some SCADA security experts working on security for critical infrastructure systems say Stuxnet is interesting, but not their top priority today. More common malware is a bigger concern since Stuxnet is so targeted. "Stuxnet is not relevant. It's not what keeps us up at night," says Jose Fernandez, assistant professor of computer and software engineering at Ecole Polytechnique in Montreal, which conducts SCADA and smart grid security research.

The full Symantec white paper on the newly identified version of Stuxnet is available here (PDF) for download.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cbabcock
50%
50%
cbabcock,
User Rank: Apprentice
2/27/2013 | 7:37:19 PM
re: Stuxnet, The Prequel: Earlier Version Of Cyberweapon Discovered
Excellent history of Stuxnet by Kathy Jackson Higgins and good work by Symantec to unravel the trail. It's important to add to the timeframe around Stuxnet, since it appears to illustrate our own participation in cyberwarfare. Symantec's Liam O Murchu says, "This (2005 version of Stuxnet) may not be the first." Fascinating that we may have been targeting the Iranian nuclear site since at least 2005. Highly preferable to employing explosives in a direct act of war, but still a cyberwarfare initiative. Charlie Babcock, InformationWeek-Š -Š
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web