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 complexity 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 geniuses 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.



Rooting Exploit for Android Works Silently

In our last blog about Android malware, we discussed the expanding threat landscape for Android malware. Recently, we received an Android package in our collection and observed that this malicious application uses a rooting exploit that targets Android devices running OS Versions 2.3 or earlier to gain root privileges on the compromised device.

The malware binary is packaged with a legitimate application. In this case, the malicious exploit code comes with “Daily Beauties,” which showcases pictures of celebrities that are updated periodically. Attackers use this repacking approach to hide their malware within genuine applications, which users will download and install.

The following image represents the repacking a legit application with malicious code. These repackaged applications are made available in Android black markets and third-party markets.

                           Figure 1: Repackaged application

This malicious application requires the following user permissions:

Figure 2: User permissions required by the malicious application


From the preceding list of permissions requested by the malicious application, I was curious about two in particular.

  • android.permission.MOUNT_UNMOUNT_FILESYSTEMS
  • android.permission.WRITE_OWNER_DATA

 

Why would an application that displays pictures of celebrities require permission to write user data and mount/unmount file systems?

Upon opening the malicious application we see the names of celebrities, as shown in the below figure. The victims would see the pictures, but they wouldn’t see the malicious service running in the background.


Figure 3: A picture of the celebrity showcased by the application

So how does the exploit work? The malicious application has four files bundled along with the legit application. They can be found in the asset folder of the application package. The file names appear in Figure 4:


Figure 4: Malicious files in the asset folder of the Android application package

The file gbfm.png carries the exploit code; the others are script/shell files. all four masquerade as PNG image files, although they are originally ELF (gbfm.png, runme.png) and shell script (install.png, installsoft.png) files.

When the required services start, the malicious application renames the .png extension to .sh and executes the exploit as shell script.

Figure 5: Renaming the .png extension to .sh extension

The malicious application first checks for the version of the Android OS and then exploits it:

Figure 6: Malware checks for the Android OS version and executes the exploit

The malware next checks for the Unix user identifier of the currently running process and stores it. Then it triggers the exploit (gbfm.sh). If it’s successful, the malware will elevate the device to the root privilege.

When the device is successfully rooted, it will run the install.sh script, which will set the appropriate file permissions (chmod 4775) to the system partition and copies the shell from the bin folder /system/bin/sh to the folder created by the malicious application /system/xbin/appmaster. Thus the shell can be accessed whenever it wishes and the system partition is remounted.

Figure 7: Setting up the file permissions

After a while, the malware executes the installsoft.sh script, which silently downloads more APK files in the background and installs them by executing the “pm install” command in the root shell.

Figure 8: Installing APK files in the background

The malware retrieves the following information from the compromised device and sends that information to a remote site:

Figure 9: User information retrieved by the malicious file

The exploit will work only when the device has an SD card installed. If not, it will not run. McAfee products detect this malware in our latest DATs as Linux/Exploit-Lotoor.

TWiT.tv – malware infects Leo Laporte’s website

TWiT.tvThe website run by internet celebrity Leo Laporte, TWiT.tv, has been hit by a malware infection intended to infect visiting computers.

Hackers have managed to inject a line of malicious code, in the form of an iFrame, at the very top of the TWiT website pointing to a webpage with a .cz.cc domain name.

Although Sophos products intercepted the compromised TWiT.tv webpage as Mal/Iframe-V, and prevented users from having their computers compromised by the attack, users of other vendors’ products may not be so lucky.

TWiT infected webpage

The .cz.cc webpage attempts to run a file called worms.jar which Sophos detects as Troj/Java-AL.

The Java Trojan is normally associated with fake anti-virus attacks, and may also trigger a PDF-based vulnerability attack detected by Sophos as Troj/PDFJs-ST.

Surfing the web without malware protection is pretty dangerous these days – it’s like sky-diving with nothing more than a picnic hamper strapped onto your back. We see tens of thousands of legitimate webpages which are hosting malware every day.

The TWiT network is famous for scores of popular internet podcasts and streaming video shows, including “This Week in Tech” (which gave the network its name) and “Security Now” co-hosted by Steve Gibson.

As you can see below, Google Chrome is also warning of the infection:

Warning via Google Chrome

Of course, Leo Laporte is far from the first social media celebrity to suffer at the hands of hackers. For instance, a couple of years ago, Robert Scoble – himself a regular on TWiT.tv broadcasts, found that hackers had managed to breach his website after he failed to upgrade his version of WordPress.

If you run a website make sure you are doing everything to keep it as secure as possible – for both your company’s sake, and that of your users. If you haven’t already done so, read this informative paper by SophosLabs, “Securing websites”, which covers some of the issues.


Google relents, offers "WiFi sniffing" opt-out

An article on Google’s grandly-named European Public Policy Blog, which offers “Google’s views on government, policy and politics in Europe”, has gently announced what the search-and-advertising behemoth calls A new option for location-based services.

Google’s location-based services rely extensively on its controversial global database of WiFi access points.

The idea is simple. Google’s many StreetView cars and bicycles spend their time driving around our suburbs, snapping a continuous stream of photographs of houses, gardens, offices, parks – whatever they pass on their all-encompassing journeys.

Whilst they’re about it, the StreetView vehicles also make digital recordings in other parts of the electromagnetic spectrum – to wit, they sniff out WiFi access points and record their identification information and location.

Most access points spend long periods of time with the same MAC address and network name, and in the same place. So, a list of the access points currently within range of your laptop or mobile phone lets Google make a pretty good guess at your current location.

Wi-fi hazardThis obviates the need for GPS – which is slow to lock when you first power it up, drains your battery if you leave it running, and doesn’t work well indoors.

Google’s outward-facing explanation of the benefit of its massive WiFi database is that it represents value to you – it helps you find out where you are. Sadly, most of the time you already know where you are. You’re at home, or in the office, or stuck yet again in a traffic jam on Parramatta Road on your way to work. Or from it.

The inward-facing explanation, of course, is that it represents value to Google – it helps Google know where you are. And that’s good for targeted advertising, and that’s great for business.

Anyway, after pressure from various privacy-minded data protection authorities in Europe, Google has changed its stance on its WiFi location database. You will soon be able to opt out, Google says, from being a part of the access point service.

The details of how this will work have not yet been released. How you will opt out has not been explained. And calling it “opting out” when you didn’t opt in in the first place is a little cheeky.

It doesn’t even sound from the blog article as though Google intends to remove your access point data from its database if you opt out. The lawyerly prose in the article simply says that if you opt out, “[Google’s] services will not use that access point to determine users’ locations.”

(Actually, this is a Catch-22. Google pretty much has to keep you on file, simply in order to know that you didn’t want to be on file in the first place. Otherwise they’d just add you back in next time the StreetView WiFi scanner came round – and then you’d have to opt out again. Sadly, you can’t opt out of the StreetView collection process proactively.)

Nevertheless, this is an interesting change because it shows that, with enough pressure, even data-accumulation juggernauts like Google can be persuaded to change their ways.

In short: if big companies are doing things online with your data which you aren’t happy with, don’t just keep quiet. Write to your Privacy Commissioner. You can make a difference!