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.

Risk

1/16/2011
07:48 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Report: Stuxnet Joint Israeli-U.S. Operation

A story published this weekend adds evidence to what many have suspected all along: that the Stuxnet worm was nation-state designed and developed to set-back Iran's nuclear ambitions.

A story published this weekend adds evidence to what many have suspected all along: that the Stuxnet worm was nation-state designed and developed to set-back Iran's nuclear ambitions.According to unnamed sources in a story published in the New York Times Saturday, the Stuxnet worm was a two year long operation coordinated among the United States and Israel.

The Stuxnet worm was discovered this summer, and is the first publicly known worm that can snoop and re-program industrial control systems. And is widely believed to target Iranian nuclear centrifuges thought by many countries to be part of a weapons program.

According to the story, Stuxnet was thoroughly tested at the guarded Dimona complex in the Negev desert. It was at that site where Israel tested Stuxnet against equipment built to closely match what Iran was running at its controversial Natanz installation.

The paper also said that the U.S. Idaho National Laboratory identified vulnerabilities in the Seimens systems in use by Iran.

The worm, also in the report, is credited with not only with the ability to disrupt Iran's nuclear centrifuges but to only (incredibly) feed fake data back to technicians that made it appear all was well with the equipment:

The worm itself now appears to have included two major components. One was designed to send Iran's nuclear centrifuges spinning wildly out of control. Another seems right out of the movies: The computer program also secretly recorded what normal operations at the nuclear plant looked like, then played those readings back to plant operators, like a pre-recorded security tape in a bank heist, so that it would appear that everything was operating normally while the centrifuges were actually tearing themselves apart.

The worm is credited with sending back the alleged Iranian nuclear weapons program by several years.

It's impossible to tell if these reports are accurate. But I do believe we'll soon know who the creators of the Stuxnet worm are exactly.

No matter who created this worm, it's certainly changed the way we have to think about defending industrial control systems and our own critical infrastructure. That's because if Iranian systems are vulnerable to such attacks – so are ours.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.