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
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-3783
PUBLISHED: 2018-08-17
A privilege escalation detected in flintcms versions <= 1.1.9 allows account takeover due to blind MongoDB injection in password reset.
CVE-2018-3784
PUBLISHED: 2018-08-17
A code injection in cryo 0.0.6 allows an attacker to arbitrarily execute code due to insecure implementation of deserialization.
CVE-2018-3785
PUBLISHED: 2018-08-17
A command injection in git-dummy-commit v1.3.0 allows os level commands to be executed due to an unescaped parameter.
CVE-2018-10873
PUBLISHED: 2018-08-17
A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially,...
CVE-2018-5546
PUBLISHED: 2018-08-17
The svpn and policyserver components of the F5 BIG-IP APM client prior to version 7.1.7.1 for Linux and macOS runs as a privileged process and can allow an unprivileged user to get ownership of files owned by root on the local client host. A malicious local unprivileged user may gain knowledge of se...