More doubts linger on Stuxnet's accidental escape theory
September 13, 2012
A security expert has challenged a theory on how the infamous Stuxnet worm, best known for tampering with Iranian lab equipment, somehow escaped into the internet.
New York Times reporter David Sanger wrote what's become the definitive account of how Stuxnet was jointly developed by a U.S. / Israeli team. The sophisticated malware virus was deployed to sabotage high-speed centrifuges at Iran's nuclear fuel processing plant by infecting and commandeering the site's control systems.
According to Sanger's sources, an Iranian technician's laptop was plugged into a Stuxnet-sabotaged centrifuge device and was almost immediately infected by the malfunctioning equipment.
The virus then "escaped into the wild" when the laptop was connected to the web, granting the software safe passage to the wider world, according to the newspaper journalist's contacts.
Worse, university professor Larry Constantine, a software engineer with many years of experience in complex industrial control systems, claims that some parts of Sanger’s account are just not possible.
According to the professor, Sanger may have been misled by his political sources. In an IEEE Spectrum Techwise Conversations podcast, Constantine explained that the Stuxnet worm virus is like a military missile-- one half of it is the rocket engine, designed to spread the malware from PC to PC by exploiting security vulnerabilities in Microsoft's Windows operating system, while the other half is the explosive payload, a block of malicious code injected into Siemens-built industrial controllers.
Constantine further asserted that the specialised payload hidden away in the control systems was incapable of infecting a Windows machine, thus it's impossible for the Iranian technician's laptop to have picked up the worm from the uranium enrichment machinery. It is not known exactly how the engineer's portable PC was infected.
He also said that the malware was designed to restrict itself to local-area networks, specifically the plant's internal LAN, and could not have spread to the wider internet under its own power.
The prof claimed in the podcast-- "First of all, the Stuxnet worm didn't escape into the wild. The analysis of initial infections and propagations by Symantec reveal that, in fact, it never was widespread in the first place, and that it affected mostly computers in closely-connected clusters, all of which involved collaborators or companies that had dealings with each other.
Secondly, it couldn't have escaped over the web, as Sanger's account initially maintains, because it never had that capability built into it. It can only propagate over a local-area network, over removable media such as CDs, DVDs, or USB sticks.
So it was never capable of spreading widely, and in fact the sequence of virus infections is always connected by a closed chain, a loop of events, sort of speak.
And still another element that Sanger didn't get right is the notion that the worm virus escaped when an engineer connected his laptop to the programmable logic controllers (PLCs) that were controlling the centrifuges and his computer then became infected, which later spread over the web.
This is also impossible because the software that was resident on the PLCs is the payload that directly deals with the centrifuge motors. It does not have the capability of infecting a computer because it doesn't have any copy of the rest of the Stuxnet system, so that part of the story is simply impossible.
Additionally, the explanation offered in his book and in his article is that Stuxnet escaped because of an error in the code, with the Americans claiming it was the Israelis' fault that suddenly allowed it to get onto the internet because it no longer recognized its environment.
Anybody who works in the field knows that this doesn't quite make sense, but in fact the last version, the revision to Stuxnet, according to Symantec, had been in March 2012, and it wasn't discovered until June 17 of this year.
And in fact the mode of discovery had nothing to do with its being widespread in the wild because in fact it was discovered inside computers in Iran that were being supported by a Belarus antivirus company called VirusBlokAda.
Professor Constantine, an academic in the mathematics and engineering department at the University of Madeira in Portugal, argued that these technical details matter "because it raises broad questions about the nature of the so-called leaks from administration personnel to Sanger".
He does not dispute that Stuxnet was a joint US-Israeli operation to create malware specifically to sabotage Siemens equipment at processing plants in Natanz, Iran.
Costin Raiu, a senior security researcher at Kaspersky Lab, said the professor was right to question the infected laptop theory, and added "Stuxnet didn't escape into the wild by accident. It's possible that, rather than admit the worm was deployed wider than a specific Iranian installation, the U.S. administration let it be known that its super-weapon had accidentally broken free of its constraints.
We asked several independent experts for a reality check on the technical aspects of Prof Constantine's criticism of Sanger's account. People at security tools biz Sourcefire and antivirus firm Eset agreed that it was unlikely the laptop could have been compromised by plugging it into a Stuxnet-infected PLC.
But the experts were split nevertheless on whether or not Stuxnet was capable of spreading across the internet. Eset earlier published a report jointly written by David Harley, Eugene Rodionov, Juraj Malcho and Aleksandr Matrosov on the Stuxnet outbreak.
The team was rather sympathetic to the professor's fresh take on several counts, but totally dismissed his suggestion that Stuxnet was unable to escape into the wild.
The way the IEEE story describes it, there is some confusion somewhere between the infection mechanism and the payload that clearly casts some doubt on Sanger's account, if it really has to do with a backward infection from a PLC. The account of the backward infection doesn't sound convincing technically.
A security vulnerability in some software interfacing between PLC and another system might account for it in principle, but doesn't seem likely given the nature of the payload programming.
Constantine is more or less correct in that Stuxnet spread by USB device, removable media or network shares rather than normal internet channels. But network share infection is kind of ambivalent and the network file system protocol SMB/CIFS is capable of being used beyond the local-area network.
Stuxnet's primary infection vector was USB, but it also infected through the MS08-67 RPC vulnerability initially exploited by Conficker, the MS10-061 print spooler vulnerability, and network shares.
But it might still be able to propagate through the web under some circumstances via network shares along with VPN and using the RPC vulnerability.
Although MS08-067, MS10-061 are mainly used to propagate inside the local-area network, Eugene thinks that it is possible for these vulnerabilities to allow the malware to cross the borders of adjacent networks. But did it?
As Juraj points out, there's no reason (apart from Sanger telling us so) to assume that if Stuxnet escaped it did so by leaking from a developer's PC via the internet.
The people at Eset also trashed Professor Constantine's contention that Stuxnet did not spread widely. It's nonsense to say that Stuxnet didn't get into the wild. Constantine cites Symantec as demonstrating that Stuxnet was never widespread, but Symantec itself stated: 'As of September 29, 2010, the data has shown that there are approximately 100,000 infected hosts. We have observed over 40,000 unique external IP addresses, from over 155 countries.'
But Dominic Storey, Sourcefire's technical director for EMEA, says that the local-area network protocols exploited by Stuxnet to spread across a nuclear plant's internal systems would be blocked at the firewall in any corporate - or even any sensible home user.
Even a badly managed enterprise set-up would block incoming file and print sharing connections. If it didn't, Stuxnet would be the least of the organisation's problems.
Storey trained as a plasma physicist at the U.K.'s Atomic Energy Authority, specializing in nuclear fusion research, prior to embarking in a career in network security. Recently, he's carried out a lot of work looking into vulnerabilities in industrial control (SCADA) systems.
"Stuxnet was not like a worm. It was written for a specific platform and its vector for spreading was from laptop to laptop or USB drive-- it didn't rip through the universe," Storey said.
The physicist argued there was some merit in Professor Constantine's argument, which if nothing else adds a bit of intrigue to the heated debate about the origins and purpose of Stuxnet, generally considered as the world's first cyber-weapon.
In other internet security news
A security research lab based in Poland, Invisible Things Lab (ITL), has announced Qubes 1.0, the first production release of a new desktop operating system designed to provide unprecedented security through the pervasive use of virtualization.
"Contrary to popular belief, there are no general purpose desktop operating systems that would be formally proven to be 100 percent secure and that's unfortunate," said ITL founder and CEO Joanna Rutkowska, announcing the release on Monday.
"At the very best, there are some parts that are formally verified, such as some microkernels, but not whole OSs," she added.
But to help rectify the situation, Rutkowska and her team built Qubes, an operating system that uses virtual machines (VMs) to isolate sensitive applications and their data from parts of the system that may be vulnerable to potential compromises.
However, in case you have to ask, Qubes wasn't written from scratch, but instead draws upon existing open source code, although it uses it in various and innovative ways.
At its core is the Xen hypervisor, which it uses to create and manage the various virtual machines that form its security model. In Qubes, users can create as many VMs – also known as domains – as they want, and assign them varying security levels based on the sensitivity of the applications and data they will be using in them. For example, one user might decide to create "home", "work", "banking", and "shopping" domains, each shielded from the others and each with its own security rules.
Below all of these application domains, Qubes maintains a separate administrative domain that provides a common graphical user interface for all running applications.
No matter which domains the various applications might be running under, they can all share the desktop on the same screen, and share the same input devices.
Additionally, a Qubes desktop OS running VMs is available in various security levels marked as green, yellow, and red.
But that doesn't mean they can share data. The user has ultimate control over which files and other data can pass between which domains. Even operations as simple as cut-and-paste between domains aren't allowed without explicit user approval. That represents a rather powerful security feature in and by itself.
Qubes can also enforce network policies for each domain, both to prevent unwanted network activity by malware and to block commonplace user mistakes.
For instance, a user could configure Qubes so that only a web browser running in the banking domain can access online banking sites, while browsers running in other domains are totally blocked from those sites.
Qubes can even create disposable VMs for one-time actions that could compromise security even though they would ordinarily be allowed. For instance, a user could choose to open a PDF file from a suspicious source in a disposable VM, minimizing the potential damage it could cause if the file contained exploit code or a virus.
Rutkowska cautions that, particularly in this early phase, Qubes shouldn't be considered a "100 percent safe" OS, but rather a "reasonably secure" one. That's because despite all of the many layers of security built into the Qubes security model, the security it provides isn't automatic, however.
Instead, it relies on the user to make some decisions, which Rutkowska admits won't be the right approach for everyone.
"This provides for greater flexibility for more advanced users," she writes, "but the price to pay is that Qubes OS requires some skills and actual thinking to actually make the user's data more secure."
Rutkowska also warns that there may yet be some bugs in the Qubes code that could be used to compromise its security model. And she should know. In 2006, she made a name for herself in the security community by creating Blue Pill, a rootkit based on the hardware virtualization support features found in modern AMD and Intel processors.
Users who would like to try out the new OS can do so by downloading an ISO and following the instructions on the Qubes website. For those who would like to try to crack Qubes' security, on the other hand, Rutkowska says that you are more than welcomed.
In other internet security news
A prominent group of hackers has released large quantities of sensitive data from banks, government agencies and consulting firms and has promised even more data leaks in the near future.
"Team Ghost Shell's final form of protest this summer against the banks, politicians and for all the fallen hackers this year," wrote in a Pastebin post titled "Project Hell Fire" this weekend.
"With the help of it's various divisions, MidasBank & the newest branch, OphiusLab. One million accounts/records leaked. We are also letting everyone know that more releases, collaborations with Anonymous and others, plus two more projects are still scheduled for this fall and winter. It's only the beginning," wrote the site's blog post.
It's still unclear how much data was published and from how many organizations, but security firm Imperva analyzed the data and said some of the breached databases contain more than 30,000 records.
"It's hard to say with precision just how much data was stolen, but you can say this is a pretty significant breach," said Rob Rachwald, director of security strategy at Imperva.
Whoever stole that data mostly used SQL injection attacks, common attacks that are easy for Web sites to protect against.
The data includes administrator login information, usernames and passwords and files from content management systems, although it didn't appear to have much sensitive information in those files, Imperva said.
You can link to the Internet Security web site as much as you like.