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

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 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
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.