Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

11/20/2013
10:45 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Stuxnet's Earlier Version Much More Powerful And Dangerous, New Analysis Finds

ICS/SCADA expert Ralph Langner analyzes how Stuxnet shifted from super-stealthy to simpler, and dispels common misconceptions about the infamous Stuxnet attack on Iran's nuclear facility -- including the belief that only a nation-state could pull off a similar attack in the future

The later-discovered earlier iteration of Stuxnet was a far more aggressive, stealthy, and sophisticated attack that could have ultimately caused catastrophic physical damage in Iran's Natanz facility. So says the expert who deciphered how Stuxnet targeted the Siemens PLCs, after recently reverse-engineering the code and further studying the attacks.

Ralph Langner, head of The Langner Group and a renowned ICS/SCADA expert, today published an analysis of Stuxnet that shines new light on the game-changing cyberweapon. Langner concludes, among other things, that the attackers moved from a more destructive and stealthy payload to a weaker and more easily detected one, and conventional wisdom that it would take a nation-state to use Stuxnet as a blueprint for attacks against U.S. and its allies' critical infrastructure is incorrect.

One big takeaway from Langner's new analysis is how the Stuxnet attackers so dramatically shifted gears from a dangerous, aggressive, and hidden attack strategy that wasn't discovered for at least five years to a louder, more noticeable, and detectable one that burnt multiple zero-day vulnerabilities and used stolen digital certificates. "What you see today in that analysis is that the first attack was more complex, stealthy, and more aggressive than the second. That is counterintuitive," Langer told Dark Reading. "So why did the attackers go from the ultimate in stealth and aggression to something that's much more simple and comes with a much higher risk of detection?"

The first attack was never meant to be detected, nor was it until Symantec found its malware clue tucked among Stuxnet samples. It was a component that didn't fit with the malware, according to Liam O Murchu, manager of North American operations for Symantec Security Technology & Response. In February Murchu detailed Symantec's discovery of what it nicknamed "Stuxnet 0.5," which dates back to 2005, five years before the later and better-known version of the malware was discovered in 2010.

[Symantec finds 'missing link' in infamous Stuxnet malware that sabotages another piece of equipment in Iranian nuclear facility. See Stuxnet, The Prequel: Earlier Version Of Cyberweapon Discovered.]

Langner says he's still baffled by why the Stuxnet attackers left behind the dormant payload, which overpressured the centrifuge rotors in the Natanz plant. The malware, like its better-known successor, was written to inflict damage on the centrifuge rotors. The main difference between the two attacks is in just how they did so: The early attack overpressured the centrifuges, which could have led to a more catastrophic physical attack. It infected the Siemens S7-417 controllers that control the valve and pressure sensors of the so-called Cascade Protection System -- groups of gas centrifuges for uranium enrichment. The second version of the Stuxnet malware attack sped up the spinning of the centrifuges at various intervals to eventually disable them, targeting the Siemens S7-315 controller.

"If the idea was catastrophic destruction, one would simply have to sit and wait. But causing a solidification of process gas would have resulted in simultaneous destruction of hundreds of centrifuges per infected controller," he wrote in his new Stuxnet paper. "While at first glance this may sound like a goal worthwhile achieving, it would also have blown cover since its cause would have been detected fairly easily by Iranian engineers in post mortem analysis. The implementation of the attack with its extremely close monitoring of pressures and centrifuge status suggests that the attackers instead took great care to avoid catastrophic damage. The intent of the overpressure attack was more likely to increase rotor stress, thereby causing rotors to break early – but not necessarily during the attack run."

Langner told Dark Reading that the early version of Stuxnet would not have been detected had the attackers taken more pains to cover their tracks. "It was only detected given the knowledge of the later version [of Stuxnet]," he says. If they had removed that payload, then it would likely never have been discovered at all, and we would not have learned of the first more deadly attack, he says.

"But with the full story, we have a better idea of how bad things can get: Malware flies under the radar of all antivirus and intrusion detection systems, and you have no chance to discover it just by looking at it. And it attacks the most sensitive components in any big industrial facility -- the protection and safety systems. That's a nightmare for engineers," he says. "That's one thing you put trust in, those systems that are designed and installed to [alert you] that if something goes wrong for whatever reason, still, disaster won't hit you."

Langner says the earlier Stuxnet payload is a wake-up call that attackers can and will go after ICS/SCADA equipment, and can cause major physical damage.

So why the change-up to a less powerful payload for Stuxnet? "The only explanation is a change in policy, strategy. And most likely, a change in stakeholders," Langner says of the attackers.

The attackers behind Stuxnet reportedly were U.S. intelligence and military officials, including the National Security Agency, according to published reports quoting unnamed Obama administration officials.

The earlier version of Stuxnet was less about information security capabilities. "It didn't require and use stolen digital certificates. There must be a reason for that. The one thing I believe that is pretty much obvious is for the second and later version, we see stuff you know is something the NSA has," Langner says.

Despite a common conclusion that Stuxnet could not be repurposed for other attacks on ICS/SCADA systems, Langner contends that Stuxnet, indeed, could be used in copycat attacks. For one, Stuxnet relied heavily on the weakest link in the facility -- its contractors, he says.

Langner argues that simultaneous attacks against multiple facilities with similar equipment could occur. That "scalability" of an attack would supersede the need for a nation-state or other sophisticated attacker, and could indeed cause power failure, for example. "These [attack] tactics can be copied -- it's doesn't require nation-state capabilities," Langner says.

Targeting a facility's contractors, for instance, as a way to secretly install the malware is a tactic any savvy attacker could employ. And code can be repurposed, Langner notes in his paper: "One of the toughest challenges is the fact that exploit code can be packaged into software tools. The genius mastermind is needed only for identifying vulnerabilities and designing exploits ... At some level of software maturity, such exploit components can be made available in user-friendly point-and-click software applications, just like it is now for boilerplate malware development. The skill set for those who assemble and deploy a specific sample of cyber-physical attack code will then drop dramatically."

Meanwhile, Langner says his new Stuxnet analysis is his last. "I don't plan to publish anything further. It sucked up too many of my resources. There was no external budget for this; I did it all on my own," he says.

Langner's full and detailed report, "To Kill A Centrifuge," which includes analysis of photos from inside the Natanz plant floor, 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 the Executive Editor of Dark Reading. 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
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18987
PUBLISHED: 2019-11-15
An issue was discovered in the AbuseFilter extension through 1.34 for MediaWiki. Once a specific abuse filter has (accidentally or otherwise) been made public, its previous versions can be exposed, thus potentially disclosing private or sensitive information within the filter's definition.
CVE-2019-18986
PUBLISHED: 2019-11-15
Pimcore before 6.2.2 allow attackers to brute-force (guess) valid usernames by using the 'forgot password' functionality as it returns distinct messages for invalid password and non-existing users.
CVE-2019-18981
PUBLISHED: 2019-11-15
Pimcore before 6.2.2 lacks an Access Denied outcome for a certain scenario of an incorrect recipient ID of a notification.
CVE-2019-18982
PUBLISHED: 2019-11-15
bundles/AdminBundle/Controller/Admin/EmailController.php in Pimcore before 6.3.0 allows script execution in the Email Log preview window because of the lack of a Content-Security-Policy header.
CVE-2019-18985
PUBLISHED: 2019-11-15
Pimcore before 6.2.2 lacks brute force protection for the 2FA token.