Monday, October 4, 2010

New Clues Point to Israel as Author of Blockbuster Worm, Or Not

From Wired's Threat Level Blog,

New clues released this week show a possible link between Israel and sophisticated malware targeting industrial control systems in critical infrastructure systems, such as nuclear plants and oil pipelines.

Late Thursday, security firm Symantec released a detailed paper with analysis of the headline-making code (.pdf), which reveals two clues in the Stuxnet malware that adds to speculation that Israel may have authored the code to target Iran.

Or, they could simply be red herrings planted in the code by programmers to point suspicion at Israel and away from other possible suspects.

The malware, called Stuxnet, appears to be the first to effectively attack critical infrastructure and in a manner that produces physical results, although there’s no proof yet any real-world damage has been done by it. The malware’s sophistication and infection of thousands of machines in Iran has led some to speculate that the U.S. or Israeli government built the code to take out Iran’s nuclear program.

Read more here


Joe said...

I'm beginning to wonder if Israel was actually behind Stuxnet. The clues referred to in the article seem too convenient and could indicate that the actual programmer wanted to deflect blame to Israel. Unless, of course, Israel wanted to obliquely telegraph that it was behind the infection as a show of power.

Regardless, the press seems fairly confident that a national government is responsible. However, my question is: does it qualify as an act of war or an act of terrorism? Stuxnet has many of the trappings of terrorism (soft targets, surreptitiously executed, lack of wartime status, spreads fear), but it has not yet been labeled as such. Though this is really a game of semantics, it is important that we develop a taxonomy for online threats and attacks to 1) develop appropriate response plans and 2) keep the public and Congress properly apprised of such threats.

Garrett said...

As we move into the more security-heavy half of the class, I keep returning to this article with more questions. If the US and/or Israel so successfully infected Iran's industrial infrastructure with Stuxnet, why didn't they take anything down? Why go to the trouble of infecting those systems yet not actually destroy the target - presumably Iran's nuclear infrastructure - especially given the perceived strategic risks of a nuclear Iran? Whether we consider the actual infection an act or war, espionage, or terrorism, Iran has vowed to respond, so why provoke Iran at all if the US and/or Israel wasn't going to use the program?

I'm not sure what it all indicates. Maybe that someone else is behind this and left red herrings, maybe that something bigger was in the works but got picked up on, but I find it hard to believe that either the US or Israel would get this capability and not use it. The window of opportunity seems to tempting to let it slip by.

Christopher Mika said...

What bugs me (no pun intended) is the level of incompetence on Siemen’s part. It seems they completely disregarded integrating security into their product, not only at the time of its creation, but also when its vulnerability was made public. Indeed, Stuxnet was designed to spread through SCADA systems by three avenues: USB drives, a zero-day vulnerability, and a “hard-coded” password, which Siemens created itself. Yet this password, according to Wired, has been openly available on the Internet since 2008.

Indeed, the default password, which allows the WinCC software to connect to its MS-SQL back-end database, is an easily identifiable route to exploit the SCADA system. It appeared on product forums in Germany and Russia in 2008. Yet, not only has Siemens done nothing to fix the issue, but it also seems they have attempted to cover it up. The moderator of the Siemens technical forum promptly deleted the post, which announced the vulnerability. That deletion, however, did not stem the spread of the password. Furthermore, any consumer attempts to replace the present password with a new, secure one, make the entire SCADA system inoperable.

Even more frustrating: “‘Well over 50 percent of the control system suppliers’ hard-code passwords into their software or firmware,” presenting the same security issue, exploitable in Siemens.