Attacks/Breaches
2/14/2011
01:23 PM
50%
50%

Stuxnet Iran Attack Launched From 10 Machines

Symantec researchers analyzed the worm's timestamps and found that the 12,000 infections they studied originated from a handful of machines.

Top 10 Security Stories Of 2010
(click image for larger view)
Slideshow: Top 10 Security Stories Of 2010

All Stuxnet worm attacks -- which targeted a nuclear facility in Iran -- were launched by infecting a total of just 10 machines. In other words, the more than 100,000 Stuxnet infections spotted by September 2010 can be traced back to a handful of infections, which likely targeted peripheral facilities to ultimately infect the true target.

That's the surprise finding from a new Symantec report on Stuxnet, released Friday.

Stuxnet was designed to sabotage the high-frequency convertor drives used in a uranium enrichment facility in Iran. The malware adjusts the automated control system's user interface to make it appear that the drives are running normally. But in reality, the malware is quickly adjusting the speed of the drives to very high and low frequencies. As a result, not only does the uranium not get enriched, but the drive motors are permanently damaged.

In November, Symantec's researchers discovered that Stuxnet records a timestamp every time it infects a new machine. "However, at the time, this information was largely useless as we did not have enough samples to draw any meaningful conclusions," they said in a blog post.

Since then, however, numerous antivirus firms have been feeding the researchers every Stuxnet variant they capture, enabling them to amass a collection of 3,280 unique samples, which would have generated about 12,000 infections. Studying this subset, they found that every infection could be traced back to just one of 10 machines.

Since attackers may not have had direct access to the enrichment facility, it’s possible they targeted machines in five related facilities, in an attempt to spread the malware to the enrichment facility. Interestingly, in June 2009, and again in April 2010, the same PC appears to have been infected with different versions of Stuxnet. Meanwhile, another facility was targeted once, but had an initial three infections, which Symantec said suggests that a USB key carrying Stuxnet was inserted into three different PCs.

Symantec said the last Stuxnet attack appeared to have been launched in May 2010, while the earliest known attack dates from June 2009.

Iran began containing Stuxnet in August 2010. "Looking at newly infected IP addresses per day, on August 22 we observed that Iran was no longer reporting new infections," said Symantec's researchers. "This was most likely due to Iran blocking outward connections to the command and control servers, rather than a drop-off in infections."

But Iran's response came too late. According to news reports, the Stuxnet attacks appear to have been successful.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8148
Published: 2015-01-26
The default D-Bus access control rule in Midgard2 10.05.7.1 allows local users to send arbitrary method calls or signals to any process on the system bus and possibly execute arbitrary code with root privileges.

CVE-2014-8157
Published: 2015-01-26
Off-by-one error in the jpc_dec_process_sot function in JasPer 1.900.1 and earlier allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted JPEG 2000 image, which triggers a heap-based buffer overflow.

CVE-2014-8158
Published: 2015-01-26
Multiple stack-based buffer overflows in jpc_qmfb.c in JasPer 1.900.1 and earlier allow remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted JPEG 2000 image.

CVE-2014-9571
Published: 2015-01-26
Cross-site scripting (XSS) vulnerability in admin/install.php in MantisBT before 1.2.19 and 1.3.x before 1.3.0-beta.2 allows remote attackers to inject arbitrary web script or HTML via the (1) admin_username or (2) admin_password parameter.

CVE-2014-9572
Published: 2015-01-26
MantisBT before 1.2.19 and 1.3.x before 1.3.0-beta.2 does not properly restrict access to /*/install.php, which allows remote attackers to obtain database credentials via the install parameter with the value 4.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
If you’re a security professional, you’ve probably been asked many questions about the December attack on Sony. On Jan. 21 at 1pm eastern, you can join a special, one-hour Dark Reading Radio discussion devoted to the Sony hack and the issues that may arise from it.