In light of the ongoing concern over last week's attack on the World Trade Center and the likely fallout of imminent military reaction to that, it should not be surrpising that Nimda has failed to get quite the same media coverage as Codered did a month or so earlier. However, the multi-fanged spreading machine that is Nimda has spread as fast, if not faster than, CodeRed.C (aka CodeRedII) which was the fastest moving worm to date. Nimda has been reported to have hit several large New Zealand sites, including universities and web-based banking. Cleanup is far from simple and there are many traps for the unwary because of the multiple angles that Nimda can come back at you from. Everything else pretyt much pailed into insignificance this week, and combined with your newsletter compiler having a serious cold means we have a slim issue this week.
IIS adminstrators may be interested in looking at a new tool that promises to generically improve IIS security by blocking 'odd' URL requests -- a common sign 'something is going on' -- and the trial of the writer of the Anna Kournikova virus starts.
Nimda -- admin madness
Early Wednesday morning, a complex malicious program, technically dubbed Win32/Nimda.57344@mm by the antivirus research community, started spreading very quickly around the world. Its rate of spread was amongst the highest ever seen, perhaps even outstripping the recent CodeRed.C worm. This was because, unlike most other worms or viruses before it, Nimda combined both viral and network worm spread mechanisms. Further, it employed several spread mechanisms -- in total, having at least four ways to distribute itself.
Because of its multiple, successful spread mechanisms, there really is no "typical" Nimda infection scenario, so we will just describe each mechanism, and in no particular order...
Nimda can spread by searching the network for IIS servers that are vulnerable to the (now venerable) "Unicode directory traversal" bug and the newer, but related, "double decode" bug. It also searches for signs of a web server having been compromised by CodeRed.C or CodeRed.D. Web servers found to offer any of these access points are then sent specially crafted URLs that will cause them to download a copy of the Nimda's main executable from the "attacking" site. This is done by running the standard Windows tftp client and pointing it back to the attacking machine. Once Nimda has been transferred to the web server another specially crafted URL is sent to the server, causing it to execute the just uploaded copy of Nimda.
Aside from its web server-based distribution methods, Nimda is also a parasitic virus, infecting Windows executable files. In this, it not only infects files on the local drives of its host, but also any suitable executable files it can write to across file sharing (LAN) network connections.
And, as if that is not enough, Nimda also distributes copies of itself via a mass mailing function. Although the mass-mailing is, in some respects fairly standard, the copies it sends also depend on the malformed EML method descriobed above for the web server to client infection method, so will normally only affect users of e-mail client software that uses vulnerable versions of Internet Explorer to handle its message display (Outlook and Outlook Express are clearly two such e-mail clients, but some third-party mailers also depend on IE).
Because of its very active network components, scanning for web servers, sending e-mail and transferring itself over network shares, Nimda can have a massive impact on network speed and many sites that fell victim to it reported huge network loads rendering their network access all but unusable.
Cleaning up from a Nimda attack is a very messy, and potentially problematic, exercise. Aside from all the precautiuons one must take in disinfecting executables of a parasitic virus, one has to take all the extra precautions of ensuring that no other infected machines ever get to 'see' the machines being cleaned and the already cleaned machines on the local network. Entirely shutting down file sharing, which can include preventing all access to intranet web servers and the company's public web servers will have an enormous impact on productivity at many businesses, but failure to do this in infected environments will, more than likely, see the 'chasing your tail' problem that has prevented the complete removal of FunLove from many company LANs. Unfortunately, because of Nimda's proclivity to spread and the likelihood it will quickly find its way to your web servers and into your e-mail, ignoring a certain 'background noise' level of Nimda infection will not be an acceptable solution, even if that approach 'worked' with the less tenacious FunLove.
Aside from all the above, under NT and Windows 2000, Nimda can recreate the Guest user account (if it was missing) and put it and the Guests group in the Administrator group. Should this privilege escalation have occurred, you have to take a very careful approach to cleanup, as any manner of other security breeches could have occurred since Nimda hit through exploitation of this 'hole'. This, plus the extent of changes Nimda makes by infecting files, modifying web pages and so on, strongly suggests that, facing a Nimda cleanup, the prudent administrator should take a 'scorched earth' approach to the task and rebuild the machines from scratch and restore to backups from before the infection.
Finally, the jaded cynicism of your newsletter compiler spurred him to note that much of what has been written by 'well intentioned' non-experts 'just trying to help' is very incomplete. Just because a given sequence of steps is reported to work on one person's machine(s) does not mean they are a complete cleanup guide for another machine. For example, many of the early 'I cleaned up like this...' reports posted to public newsgroups and other discussion forums were written by people who had entirely missed the fact that Nimda was a parasitic virus, so made no mention of disinfecting infected program files.
Various antivirus developer descriptions:
Other pages of potential interest:
Kournikova virus writer's trial
Jan de Wit, the 20 year old Dutch man who has admitted writing the VBS/VBSWG.J virus (better known as 'the Anna Kournikova virus') went on trial late last week. His lawyer asked for de Wit to be released and the prosecutor asked for 240 hours of community service and the non-return of de Wit's computer and computer virus collection.
URLScan to improve IIS security?
Microsoft has released a tool aimed at improving IIS server security. Named URLScan, it is essentially a filter that 'sanity checks' URL requests before they are passed to the server for processing. URLScan's filtering rules are said to be powerful enough to allow an experienced web server administrator to prevent any 'odd' page requests from being serviced and thus should mean the server itself only processes valid page requests.
URLScan works with IIS 4.0, 5.0 and 5.1 but is too new to have a track record indicating its usefulness yet. Note, however, that Microsoft recommends 'the tool only be used by experienced web administrators, as it is possible to configure the filters in a way that would interfere with normal web site operation'. That means 'test extra carefully if you plan to use it'.
Microsoft URLScan page and KB article on its use: