Attacks/Breaches

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

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 Executive 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 ... 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- -
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
The Data Security Landscape Is Shifting: Is Your Company Prepared?
Francis Dinha, CEO & Co-Founder of OpenVPN,  8/13/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-13435
PUBLISHED: 2018-08-16
** DISPUTED ** An issue was discovered in the LINE jp.naver.line application 8.8.0 for iOS. The Passcode feature allows authentication bypass via runtime manipulation that forces a certain method to disable passcode authentication. NOTE: the vendor indicates that this is not an attack of interest w...
CVE-2018-13446
PUBLISHED: 2018-08-16
** DISPUTED ** An issue was discovered in the LINE jp.naver.line application 8.8.1 for Android. The Passcode feature allows authentication bypass via runtime manipulation that forces a certain method's return value to true. In other words, an attacker could authenticate with an arbitrary passcode. ...
CVE-2018-14567
PUBLISHED: 2018-08-16
libxml2 2.9.8, if --with-lzma is used, allows remote attackers to cause a denial of service (infinite loop) via a crafted XML file that triggers LZMA_MEMLIMIT_ERROR, as demonstrated by xmllint, a different vulnerability than CVE-2015-8035 and CVE-2018-9251.
CVE-2018-15122
PUBLISHED: 2018-08-16
An issue found in Progress Telerik JustAssembly through 2018.1.323.2 and JustDecompile through 2018.2.605.0 makes it possible to execute code by decompiling a compiled .NET object (such as DLL or EXE) with an embedded resource file by clicking on the resource.
CVE-2018-11509
PUBLISHED: 2018-08-16
ASUSTOR ADM 3.1.0.RFQ3 uses the same default root:admin username and password as it does for the NAS itself for applications that are installed from the online repository. This may allow an attacker to login and upload a webshell.