Attacks/Breaches
12/14/2010
02:29 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

China Likely Behind Stuxnet Attack, Cyberwar Expert Says

Security expert connects the dots to China, not Israel, U.S.

Israel and the U.S. so far have been pegged as the most likely masterminds behind the Stuxnet worm that targeted Iran's nuclear facility, but new research indicates China could instead be the culprit.

Jeffrey Carr, founder and CEO of Taia Global, an executive cybersecurity firm, and author of Inside Cyber Warfare, says he has found several clues that link China to Stuxnet. ”Right now I'm very comfortable with the idea that this is an attack that emanated from China," Carr says. "I'm fairly certain this was China-driven."

Carr, who blogged about his new theory today, says Vacon, the maker of one of the two frequency converter drives used in the Siemens programmable logic controller targeted by the Stuxnet worm, doesn't make its drives in its home country Finland, but rather in Suzhou, China.

Chinese customs officials in March 2009 raided Vacon's Suzhou offices and took two employees into custody, allegedly due to some sort of "irregularities" with the time line of when experts think Stuxnet was first created, according to Carr. "Once China decided to pursue action against this company and detain two of its employees, they had access to everything -- this is where they manufacture the drives, so they would have easy access if they were looking for that material," such as engineering specifications, he says.

A second connection uncovered by Carr is that the digital certificate pilfered by the Stuxnet attackers was RealTek Semiconductor's. RealTeck is headquartered in Taiwan, but has a subsidiary called Realsil Microelectronics in Suzhou, China.

Carr also notes China's access to Windows source code, which would have given it ample access to finding the four zero-day flaws in Windows that were used to pull off the attack. Microsoft signed an agreement with the Chinese government in 2006 that gives officials access to most of Microsoft products' source code, including operating systems Windows 7, Vista, XP, and Server 2008. The deal was meant to assuage Chinese concerns about the security features in the software.

Interestingly, China didn't report any Stuxnet infections until more than three months after Stuxnet was discovered, when media there said some 1 million machines were infected with the worm. Carr notes that Chinese AV firm Rising Antivirus International was the source of that data, and this is the AV firm that called on Chinese citizen to download its software to fight a virus that it actually created. "Considering this new information, RI's Stuxnet announcement sounds more like a CYA strategy from the worm's originators than anything else," Carr wrote in his blog.

But Liam O Murchu, manager of operations at Symantec Security Response isn't sold on China -- or any particular nation at this point.

"Stuxnet is a very sophisticated and well-funded threat. It seems clear that the group that developed Stuxnet also had access to proprietary information about one or more target industrial installations in Iran. The resources required to access such data is likely to be beyond the capability of most hacking groups, even if they had the motivation to create a worm targeting an industrial control system," Murchu says. Aside from specialized coding expertise, the group behind Stuxnet also had to have intimate knowledge of industrial control systems and access to those systems to perform quality of assurance testing, he says.

"Symantec believes Stuxnet is likely the work of a government entity, but which nation state is behind the threat is still unknown to us," Murchu says.

So why did Stuxnet end up spreading beyond its targeted PLCs at the Iranian nuclear facility? Carr says that question has yet to be answered. "Perhaps the design was intentional to spread to facilities we don't even know about, as Langner Communications said," Carr says. Or it just spread accidentally, he adds.

Have a comment on this story? Please click "Discuss" 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
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-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web