Security Experts:

Stuxnet Sux or Stuxnet Success Story?

Stuxnet - Win32/Stuxnet - Analysis and Global Infection Rates

When Win32/Stuxnet first crossed my radar in early July, I didn’t really expect it to dominate my life to quite the extent it has. But the story has gone far beyond the LNK vulnerability (see my previous article) that first made it interesting to the security research community.

It may seem odd to talk about whether a malicious program is technically interesting. Perhaps one of the most interesting malicious programs of the early 1990s from a research point of view was a virus called Whale. It was large (for the time, though Stuxnet is far, far larger) and complex, and acquired a certain amount of notoriety at the time despite the fact that it didn’t actually replicate very well: something of a disadvantage in a virus, you might think. In fact, Dr. Alan Solomon suggested at the time that its main channel of replication was the exchange of samples between researchers. Its notoriety, however, derives from its complexity and resistance to analysis.

Win32/Stuxnet might be described as a worm of a slightly different color, though it’s attracted interest from the media that’s comparable in intensity to Conficker, or Code Red, or Blaster. I’m not saying that it isn’t technically interesting, of course: it has too many novel features to be accused of that. I certainly don’t remember seeing so many 0-day exploits in a single malicious package.

Apart from the (now patched) LNK vulnerability (MS10-046) that originally attracted our attention, the more recently patched print spooler attack (MS10-061) proved almost as scary, since it allows a remote user using a Guest account (which should be unprivileged) privileged write access into the %SYSTEM% directory of the target machine. Stuxnet takes this as an opportunity to write (malicious) binary files into %SYSTEM%, so we’re glad to see that one go. Then there are the two privilege escalation issues I can’t discuss yet because of responsible disclosure issues; a new twist on an older patch (MS08-067); an almost incidental sideswipe at Siemens’ naive and persistent and use of a hardcoded password; and a sly use of stolen certificates that should worry anyone who still believes that white-listing and code-signing have rendered all reactive security software obsolete. And I haven’t even mentioned some SQL code that isn’t likely to give up all its secrets until we establish exactly which system (or kind of system, even) is being targeted.

Yet it’s that targeting issue that has come to preoccupy the media (not to mention swathes of the SCADA community). No surprises there: the detail of the malcode is all Geek to most people, and malware is just Geeks bearing gifts, but politics and the possibility of war in the Middle East has concerned us all from day one.

Ralph Langner’s analysis of the Siemens-directed elements of the Stuxnet code has shed some light on its inner workings, though even there, not all his conjecture is borne out by analysis from other sources, but it’s his suggestion that Iranian nuclear facilities are a major target that’s caught the world’s attention. I don’t know if either the Bushehr or Natanz facilities are using SIMATIC WinCC or Step7 software at this point, but I do know that most of this targeting conjecture derives from the high volumes of infections noted in Iran. I’m speaking relatively, here, of course. Stuxnet infections worldwide are tiny compared to Autorun infectors, Conficker and so on. Nevertheless, ESET’s statistics, based on our own telemetry, does show a preponderance of infections in Iran (though it also shows a massive spike at the beginning followed by a steep drop soon after and a steady decline since, which is not abnormal).

Here’s a table abstracted from that telemetry that does indeed indicate a high incidence in certain countries. It shows the distribution by percentage of infected machines from the time we had specific detection of this version of Stuxnet (we had generic detection before that, but including that would distort the figures) to the present (approximately the 20th of September.)

Stuxnet Global Infection Rates

Stuxnet Worm Infection by Country

 

The main payload clearly targets certain kinds of site: to whit, sites using Programmable Logic Controllers (PLCs) equipped with very specific software, though exactly what kind of site is being targeted is, I think, still speculative. But the distribution figures don’t tell us anything about the main payload: they’re an artefact of the infective mechanism, which is far more promiscuous, and that promiscuity is doing a pretty good job of concealing the targeting detail. As I pointed out in my article last month, we don’t usually see targeted attacks that use self-replicating malware nowadays. That’s probably because:There are two challenges when it comes to statistics. The first is to generate accurate data: the second is to draw accurate conclusions from those data. If we accept the assumption that overall infection rates within a region are an indication of targeting (which I don’t), there are other regional clusters that might suggest multiple targets. And indeed, Langner’s speculations do try to address that possibility. To assume that link is naive, in part because it rests on another misconception. I don’t believe this is a targeted attack at all: rather, I’d describe it as semi-targeted, and the distinction is crucial.

• It’s difficult to control effectively where a self-replicating program goes once it’s launched: that’s one of the reasons the AV community has always tended to oppose the use of “good” viruses and worms.

• The bad guys are more likely to be influenced by a corollary to that point: the more successful a program is in self-replicating, the sooner it’s likely to be detected. As happened here.

What factors influence the spread and infection rate of self-propagating malware? Well, targeting could be a major factor: distributing Trojanized thumb drives at a SCADA conference for initial seeding would affect a very different population to a binary posted to a porn forum, or a piracy-friendly site. But it could also be quite a minor factor compared to regional factors such as tailored social engineering, not to mention the effectiveness of system patching and the availability or otherwise of effective and up-to-date security software. Iranian cyberspace may be as tightly regulated as its airspace, but I’ve seen no evidence that Iran is as focused on mitigating malware as it is on threats to its political infrastructure and agenda.

There are at least three issues that most observers are missing. One is that percentage statistics like these are to some extent from self-selecting populations: while security software makes frequent use of threat-monitoring measures such as honeynets, a major telemetry resource is the end user whose PC is calling home with reports of malware that has just tried to infect it. That can be an interesting indicator of what’s really out there on the wild and woolly Internet, but extrapolating to the total population of potentially infected machines is a mug’s game. But here’s the major problem.

Most of the infections reported are collateral damage: they’re machines that aren’t targeted by the payload, but are merely being used as a transmission medium. That applies as much in Iran as anywhere else.

Even worse, the known infection of a SCADA site is by no means proof that the site was specifically targeted. The sparse information released by Siemens about actual infection of SCADA sites using (and affecting) Siemens software suggests that most of the sites affected are in the German process industry sector, and Germany scores very low in global infection statistics.

Sophistication apart, how dangerous is Stuxnet? Well, SCADA sites are not altogether typical of other corporate sites. There are concerns that many cannot easily take the same countermeasures as a “normal” business, since a PLC controlling a critical function cannot always be taken down easily, even to apply such commonsense precautions as disabling unnecessary ports, applying patches, updating unsupported Operating Systems, and so on. The other question I’m frequently asked is whether this is really an attack by a nation state. I don’t know, and if it was, I’ m not going to speculate further on the attacker or the target. But I will quote myself here from the blog in which I announced a research paper devoted to analysis of the Stuxnet worm:

“Was it really the work of a nation team rather than hackers? Well, our analysis of the code certainly indicates the participation of someone who knows SCADA, Siemens software, and SQL: not the skills we normally associate with the samurai (hackers for hire) that governments and certain military groups have often used in the past for cyber espionage. In fact, it's by no means unlikely that this malware project was put together by a team with a range of skills and backgrounds, not unlike the sort of multi-disciplinary tiger team that is often put together to counter attacks.”

 

Tags: Stuxnet, Win32/Stuxnet, Stuxnet Worm, SCADA Virus, Stuxnet Virus infection rates

Subscribe to the SecurityWeek Email Briefing
view counter
David Harley CITP FBCS CISSP is Research Fellow and Director of Malware Intelligence at ESET LLC , Chief Operations Officer at AVIEN, and on the Board of directors of AMTSO. He is a prolific blogger and author of security-focused conference papers and articles. His books include “Viruses Revealed” (Osborne/McGraw-Hill) and the “AVIEN Malware Defense Guide” (Syngress.) He joined ESET's Research team in January 2008 as Research Author, and was appointed Director of Malware Intelligence in August 2008.