Quick on the heels of the Code Red II Worm is the Nimbda Worm (or the "W32/Nimbda worm") and it appears to be wreaking quite a fair bit of havoc on the web, including (I am sure) your website. Unlike the Code Red II Worm, the Nimbda worm requests for a "cmd.exe" file in various subdirectories of your server, and affects more than just Microsoft's IIS web servers: it also exploits holes in Microsoft Outlook, Outlook Express and Internet Explorer. This article looks into ways which you can protect your web server, your email software and your web browser against the Nimbda worm.
If you don't run a Microsoft web server on Windows, your web server is probably safe from the above. However, you will not be immune to the degraded network performance caused by other infected machines attempting to infect your server (and others). The amount of traffic going to your site will also increase — alas, there's no cause for joy here: the increase of traffic is due to the Nimbda worm or virus trying to infect your server.
Unlike the Code Red worm, the Nimbda worm can spread itself by email in the form of an attachment named "readme.exe". If you use Microsoft Outlook or Outlook Express, or in fact any email software that uses a vulnerable version of Internet Explorer to render email, due to the way the file identifies itself as an audio file, the worm will automatically execute on your machine when you read or preview a message containing the worm.
Microsoft has a patch which deals with the holes that are exploited by the Nimbda worm at http://www.microsoft.com/technet/security/bulletin/MS01-044.asp
Since the Microsoft IIS web server appears to be a popular target for worm and virus writers, it is in your interest to keep updated (or employ someone to keep updated) with the security issues from Microsoft's site.
If you use Internet Explorer 5.5 and below, you should check out the following article on Microsoft's site. It contains links to the necessary patches for your version of IE.
Alternatively, you may wish to use other browsers, such as Firefox.
If you use any email software that relies on Internet Explorer to render your email, make sure you patch your Internet Explorer as mentioned above. This definitely applies to you if you are using Microsoft Outlook. If you use a different software which allows you to select a different HTML mail rendering engine, do so.
Regardless of software you use, you should not open any attachments which you are unsure of. Attachments with a name like "readme.exe" may have been sent by the Nimbda worm.
If you are running your site on an Apache server, you might still want to take some action to avoid having to pay a huge bill on bandwidth costs at the end of the month to foot the Nimbda worm attacks.
If you don't know what I mean, telnet to your web server, and run the following command on your logs:
If your site's IP address has been targeted by the Nimbda worm residing on some infected machine, you will probably see variations of the following lines in your log:
(... and so on...)
You may or may not have thousands of such lines in your log. (One of my sites has more than 9,000 of such lines in one day alone.)
Imagine the amount of bandwidth consumed for such requests: each of those requests will fail on your web server, since Apache servers running on Unix-based machines are not vulnerable to those attacks. The result is that for each of those requests, your server will return a 404 error code together with your "File Not Found" document. Some of the requests will result in 400 errors ("Bad Request") since the server regards a few of the requests as not being properly formed.
Now calculate the damage you literally have to pay for: if you have a (say) 10 kilobyte customised error page (for 404 File Not Found requests), multiply that with the number of failed requests in your log file (say 9,000 a day) and the number of days in the month that your site is hit (we will take 30 here for ease of computation), and you get a total of 2,700,000 kilobytes of data transfer consumed by the Nimbda worm. Of course this is a rough calculation, and your mileage will vary (even from day to day), but it gives you a rough idea of how you, as a site owner, are also footing the bill for the damage the Nimbda worm causes.
To try to minimize the amount that you have to pay for this useless traffic, if your website is hosted on an Apache server, you might want to do the following.
Note that if you use Microsoft FrontPage to maintain your site, it is possible that doing the following will mess up your FrontPage settings. I don't use FrontPage myself, so I'm not sure about this, but I would suggest that you don't proceed with this if you use FrontPage. I'm not sure if any of the directories mentioned below are used by FrontPage for its internal use.
Create the following directories in your web directory.
Create a zero byte (empty) error page. You can put it anywhere you like in your web directory — for example, you can create such an empty file in your main web directory named "nimbda.html". I will assume you have created a file with that name in the example below.
In each of the directories listed above, create a ".htaccess" file with the following lines:
Important note: This .htaccess file should be placed in the _vti_bin, _mem_bin, c, d, msadc, and scripts subdirectories and not in your main directory! That is, put identical .htaccess files in each of those subdirectories.
While you're at it, if you have not already done so, you might as well take the measures I suggested in my other article to prevent bandwidth-wastage by the Code Red worm: "What is default.ida? Protecting Your Site Against the Code Red II Worm".
Unfortunately, of course, taking the above actions mean that your web directory is going to be crowded with lots of junk directories and files.
With the above configuration, when the Nimbda worm next requests for cmd.exe in the various subdirectories, the Apache web server will attempt to search for the "cmd.exe" file. Finding that it does not exist in the specified path, it will return a 404 error together with the message found in your nimbda.html file. Since that file is empty, you will not consume any bandwidth for these 404 errors.
For certain requests, the Apache server will return 400 errors, since some of these requests are malformed. In such situations, it will return a 400 error, together with your 400 error file which you have specified as nimbda.html.
On occasion, depending on how your web server is configured, and due to the way the web requests are formulated, Apache may return your real 404 error page for some requests. But even with such instances, you would still have saved yourself a lot of bandwidth for the remaining requests.
The Nimbda worm, unlike its Code Red predecessors, directly affects web servers, web browsers, and email clients. As such, it would be a good idea to check up your system and implement the solutions suggested above to ensure that all your systems are protected against the worm. Hopefully, that will help you face this storm. That is, until the next worm arrives. Sigh.
Do you find this article useful? You can learn of new articles and scripts that are published on thesitewizard.com by subscribing to the RSS feed. Simply point your RSS feed reader or a browser that supports RSS feeds at https://www.thesitewizard.com/thesitewizard.xml. You can read more about how to subscribe to RSS site feeds from my RSS FAQ.
This article is copyrighted. Please do not reproduce or distribute this article in whole or part, in any form.
It will appear on your page as: