This article is more than 1 year old

Win 95 code gaffe nearly made Stuxnet Suxnet, say infosec blokes

But was the Iranian nuke lab bothering malware really that buggy?

RSA 2015 [Please see the bootnote on this story, which we've added post-publication. The code shown at the conference does not appear to marry up with the claims made by the speakers. – ed.]

Super-worm Stuxnet could have blown its cover and failed its sabotage mission due to a bug that allowed it to spread to ancient Windows boxes, malware analysts reckon.

The stealthy software nasty, specially crafted by the US and Israel mystery miscreants, knackered Iran's Natanz uranium enrichment facility by subtly wrecking computer-controlled fuel centrifuges.

Malware probers Tillmann Werner, of Crowdstrike, and Felix Leder, of BlueCoat, say the clever cyber-spy tool – said to have put back Iran's nuclear program by two years – was on the brink of failure thanks to buggy code.

Stuxnet had to remain undetected to the Iranians or else it would have blown the operation. Unfortunately, a programming blunder would have allowed it to spread to PCs running older and unsupported versions of Windows, and probably causing them to crash as a result. Those blue screens of death would have raised suspicions at the Natanz nuclear lab.

"Stuxnet could have been over before it started by crashing Windows 95 and Windows 98 systems,” Leder told the RSA security conference in San Francisco on Thursday.

"Unfortunately, someone had a bad day when they programmed Stuxnet, and swapped the characters 'and' for 'or' – and the result was that it was checking 'or' … which resulted in it installed on any version of Windows, even Windows 95 and 98 which were not supported.

"[This is] a problem when you've spent, like, years on the campaign, and suddenly you get detected in minutes by crashing remote systems.”

In the end, Stuxnet was able to successfully vandalize the centrifuges before it was discovered in 2010, so either the worm couldn't find any old Windows boxes, or perhaps the Iranian boffins were used to Windows 95 and 98 falling over anyway.

Wait, there's more!

Stuxnet is just the most high-profile piece of malware in which the pair have found bugs. The duo said a programming error in the Conficker worm slashed its potential victim base.

Conficker, which attacked Windows machines across networks and the internet, should have infected nearly everybody. Instead, it could only scan a quarter of the entire IPv4 addresses due to a bug in the way it generated addresses at random: its random number function spat out 15-bit integers – from 0 to 0x7fff (0 to RAND_MAX) – and called that twice to create a 32-bit IPv4 address. So, in fact, it was creating a 30-bit number, leaving out chunks of the IPv4 space.

“If you sequentially attack victims, that is easily detected, so these guys did it a bit smarter, and chose addresses by random,” Werner told the RSA conference.

“The funny thing is that RAND_MAX is only 15 bits, and that means that when Conficker generates an IP address by calling this function twice, it only gets 30 random bits, and as a consequence it doesn't scan the entire internet – only a quarter of it.”

Corporate security bods may therefore thank chance if their users were spared by the worm.

There were more failures. The Storm worm that peaked in 2007 was whittled down to a mere gust by network intrusion-detection systems that zeroed in on its author's misspelling of Windows as "windoss" in two versions.

Energetic Bear, aka DragonFly, a software nasty designed to infiltrate and wreck utilities in 2014, became a toy for Werner and Leder, who discovered how to pluck the private and public crypto-keys from its cache, gaining unfettered access to lists of victims, and even details of its upcoming sorties.

Likewise a skeleton key discovery meant files on Android devices encrypted by ransomware SimpleLocker could be recovered. And the chaps said “beautiful SQL injections” and “failed sanitization” summed up the Yaludle banking trojan's vulnerabilities.

Malware dissecting is not merely for reverse-engineering nerds; sufficient work can allow researchers to commandeer the servers that orchestrate the infections – either through direct (and probably illegal) exploitation of holes in the systems, or through (as the duo recommends) squeaky-clean channels.

For example, the guys were able to painlessly neuter Conficker.A: once running on a PC, the worm downloaded an IP-address-to-location database from MaxMind to find out where in the world it was. Since Conficker did not attack systems in Ukraine, if that database mapped all the world's IP addresses to Ukraine, the worm would kill itself and stop spreading. By serving this specially crafted MaxMind database to Conficker, the guys were able to beat down the epidemic.

“We want to encourage everyone to do this,” Werner said.

The pair's slides from the conference are available online, here [PDF]. ®


We've noticed that the conference slide showing a disassembly of Stuxnet does not support Werner and Leder's comments regarding the worm and Windows 9x: the code shown at the conference would actually stop the malware from installing on Windows 95 and 98, rather than allowing it.

It is possible the duo accidentally showed instructions from a fixed version of Stuxnet – there are variants floating around – and talked instead about their experiences reverse-engineering an early build that was buggy. It is possible they flashed up code from another part of the worm that was correctly coded, whereas other components were flawed as described at the conference.

The problem lies in this block of C, derived from the x86 instructions in the Stuxnet executable:

if ( GetVersionExW(&OsVersion)
  && OsVersion.dwPlatformId == VER_PLATFORM_WIN32_NT
  && (OsVersion.dwMajorVersion >=5 || OsVersion.dwMajorVersion <= 6))

The guys said this condition...

(OsVersion.dwMajorVersion >=5 || OsVersion.dwMajorVersion <= 6))

...will always evaluate as true on Windows 9x, XP, 200x, Vista and 7, and they are correct. However, this part...

OsVersion.dwPlatformId == VER_PLATFORM_WIN32_NT

...will always evaluate as false on Windows 9x because dwPlatformId is 1 on Windows 95 and 98, and VER_PLATFORM_WIN32_NT is defined 2. Therefore, Install() will never be called on Windows 9x according to the above code.

The slide shown at RSA 2015 (click to enlarge)

We'll try to contact Werner and Leder to clarify the situation. Thanks to Stefan and other readers who have been in touch about this.

The Register's Darren Pauli traveled to this year's RSA Conference and stayed in San Francisco as a guest of RSA, an EMC-owned company.

More about


Send us news

Other stories you might like