Memories of the Nimda virus

This weekend is the tenth anniversary of the infamous and pervasive Nimda virus.

In this article, we take a look back in time at the outbreak. After all, as the US philosopher George Santayana warned a century ago, "Those who cannot remember the past are condemned to repeat it."
Nimda first showed itself on 18 September 2001.

Those were heady days. The Code Red worm had appeared in July, taking everyone by surprise with its collateral damage - massive amounts of network traffic, dedicated only to redistributing the worm.
Microsoft's "Whistler" project had been released to manufacturing as Windows XP in August.

Terrorists attacked and destroyed the World Trade Center towers on 9/11 as a shocked world watched on.

And whilst US flights were grounded as a post-9/11 precaution, Australia suffered its own aeronautic outage as the country's second-biggest airline, Ansett, abruptly stopped operating, stranding passengers around the region - including a whole raft of Sophos Sydney colleagues who found themselves camping out at Melbourne airport with tickets to nowhere.

Nimda storms the internet
Boy, did Nimda show itself. It could spread every-which-way, and it did: by sending itself out to your email contacts; by breaking into web servers and infecting files all over your website; by spreading automatically across your network; and by parasitically infecting existing programs on your hard disk.
The result was that if an infected file made its way into your organisation and ran, you could end up with hundreds or thousands of infected computers on your network. And each infected computer - whether PC or server - might have hundreds or thousands of infected, damaged or modified files.

Coming just a week after 9/11, Nimda attracted plenty of speculation that it might be a form of cyberterrorism.

The virus code includes the text:

Concept Virus(CV) V.5, Copyright(C)2001 R.P.China

Since adjectives go before the noun in English, the country of China is known as PRC, not RPC. Does this tell us something? Is the error the sign of a mistake by a Chinese who knows only a bit of English? Are we looking at a Frenchman pretending to be a Chinese who knows a bit of English? Are we looking at a Russian pretending to be a Frenchman pretending to be a Chinese who knows a bit of English?

The answer is, as so often with malware and cybercriminals, that we just can't say. We couldn't know ten years ago when Nimda came out; and we often can't tell today.

Nimda as cyberterrorism
Perhaps, ten years on from Nimda, we can learn to tone down the finger-pointing a bit. It's certain that State actors around the world (that means "hackers paid by a country's intelligence services", not students at the Royal Academy of Dramatic Art) are involved in what might tabloidally be called cyberspying.

But if we trot out the talk of cyberwar and cyberterrorism too much, we distract attention from the clear and present danger of plain-and-simple cybercrime - which almost certainly costs us billions of dollars a year - by making it sound comparatively unimportant. (Things can be simple and important. In fact, simplicity is often the key to significance.)

Nimda as a proof of No Good Viruses
One intriguing aspect of Nimda - to techies, at any rate - is its parasitism: the mechanism it uses to infect other files.

Basic parasitic malware of the day usually carried the original host file around tacked onto the end of the virus. More sophisticated viruses inserted their content as a new code section, or even - as in the CIH, or Chernobyl, virus - into unused parts of the executable.

Nimda took the simplistic approach - carry the original host around with you - but in a complicated way. It embedded the infected host inside itself as a Windows resource. And needless compexity is often the enemy of correct behaviour (if any behaviour by a virus can be called "correct").

Nimda, indeed, would happily reinfect files it had already hit. So you could end up with NOTEPAD embedded inside Nimda, embedded inside Nimda, embedded inside Nimda, and so on.

Not ad infinitum, of course, since only in Turing Machines do you get an infinite amount of memory. But the embedding could get very deep: a colleague and I ended up preparing samples which had been reinfected up to 250 times each to use in testing Sophos's virus cleanup code.

This sort of unintended side-effect is yet another reminder of why there is no such thing as a harmless virus, since even a virus which was supposedly "just for fun" might have unexpected bugs. And once a virus is in the wild, spreading of its own accord, there's no chance of issuing a recall notice.

It also reminds us that virus writers aren't always the programming genuises which they're sometimes made out to be, and why decent security companies don't queue up to hire virus writers - even if they're willing to overlook the business and moral issues of hiring a crook.

Nimda says we still make old mistakes
Of further interest in Nimda was its network-spreading technique. One problem facing a network-spreading virus is how to persuade users elsewhere on the network to run the newly-added files.

Nimda did this by dropping infected DLLs called RICHED20.DLL around your network. A DLL by this name is loaded as-needed by a variety of Windows programs when you start dealing with documents more complex than just plain text.

By putting an infected RICHED20.DLL into directories containing .DOC files, for example, the Nimda DLL would be loaded instead of the official DLL if the user were to browse to that directory and examine a document. This is because Windows loads DLLs from the current directory by default unless the programmer explicitly instructs otherwise.

And this is interesting because I wrote about sloppy DLL loading just two days ago! Two of the very latest Patch Tuesday updates from Microsoft fix bugs of exactly this sort.

Ouch. Ten years on, and we're still writing software which is incautious about how it chooses its add-on code libraries.

Nimda reminds us about patching
Another important lesson to be learned from Nimda is just how vital it is that we patch known holes inside our network quickly, so that if malware breaches our first levels of defence, it doesn't get open slather to roam internally.

Nimda greatly accelerated its spread by breaking into and infecting websites, using what is known as a directory traversal vulnerability in the IIS web server. Web servers aren't supposed to let you access files outside their own data directory, so they are supposed to watch out for character sequences such as "../../..", even if cunningly disguised.

The "dot-dot" element in a path name means "go up one level", and if allowed in a URI, could allow an outsider to access files which aren't supposed to be visible at all.

One month after Nimda, Microsoft issued security bulletin MS01-078, entitled "Patch Available for 'Web Server Folder Traversal' Vulnerability".

But this bulletin didn't actually announce the arrival of a patch. It was issued simply to remind everyone that a patch had been issued in MS01-057, more than a month before Nimda appeared.

Ouch, again. Ten years on, and at least some of us still have change control bureaucracy which dithers for weeks about individual patches. As I've written before, if you have a change control committee of that sort, you probably need to appoint a change control committee change committee.

Nimda shows us that prevention is better than cure
There. I've said it. I'll say it again, truism though it might be. Prevention is better than cure.

nb : nakedsecurity.sophos