AFDB logo
mn :: comp :: net

Whacking the Microsoft Worms

UPDATE: The RewriteRule trick seems to work nicely on the latest crop of PHP worms, as well...
RewriteRule ^.*\.(\\x90\\x90|\\x02\\xb1).* http://127.0.0.1/$1

So I got tired of my logfiles being full of Code Red and Nimda. The vigilante type responses were starting to look good, but I couldn't quite bring myself to go there ethically. Then I saw a suggestion on Yashy-hack to put a RedirectMatch into Apache, sending the worms off to http://support.microsoft.com. This I could do ethically, but it still isn't really making the world a better place (the worm continues to waste bandwidth) or making my life better (that's my bandwidth it's wasting!). Besides, I quickly found out that Apache RedirectMatch gets overruled by the presence of RewriteRule.

However, it just so happens that I have RewriteRule statements because I'm using Zope to do fun automagical things with my web sites. So I read some and played some and asked some and came up with some solutions that should redirect the traffic away from your site. Unfortunately, it didn't work like I wanted, so I did something else instead. Read on.

Now, where to direct it to? http://support.microsoft.com is still pretty tempting, but... what is the end goal? Why, to make the worm less effective. Slow it down, throw it into a loop, etc. So the best place to redirect it to is a non-existent site. That way it will spend a lot of time waiting for TCP timeouts instead of generating new traffic. But how do you make sure that the site is non-existent? People are registering bizarre names and grabbing new IP addresses all the time, so you can't just pick something at random. If you've got IPs you aren't using you could use LaBrea, but again you're wasting your resources on their stupidity. You could use an RFC 1918 address (10.x.x.x, 172.16.x.x-172.32.x.x, or 192.168.x.x), but chances are pretty good that it will be a real address on the infected machine's LAN, which could have unintended consequences... You could make something up like http://go.away.worm.com, but then you're just tying up your resources in trying to resolve bogus names. In fact, there's only one address that you know the infected machine can send traffic to without screwing anything up -- itself. Therefore, I have all my redirects pointing to http://127.0.0.1. "But wait," you might say, "doesn't that merely amplify the attack against yourself?" Well, no. Redirects are messages from the HTTP server back to the HTTP client. The client still does the address resolution, and in this case the client is the worm, so localhost is the infected machine.

Yashy points out that: another idea (although loopback is good) is there is "example.com" and "192.0.2.0/24" which are non-routable, they have been allocated specifically for documentation authors. Which is true enough. I still like the poetic justice of loopback, but 192.0.2.1 is probably more likely to slowly time out.

Stop everything from Apache

  1. As root, edit your httpd.conf. Insert
    RedirectMatch ^.*\.(exe|dll|ida).* http://127.0.0.1
    This should go ahead of any vhost configuration stanzas you might have, so that it applies in all vhosts.
  2. Reload or restart and voila. NOTE: If you are using RewriteRules, this RedirectMatch statement won't work. Instead, do this:
    RewriteRule ^.*\.(exe|dll|ida).* http://127.0.0.1
    If you are using RewriteRule to host multiple Zope-enabled named vhosts as I am, you only need this rule on your first vhost; the others won't be hit by the worm unless they are IP-based vhosts with their own IP addresses.

Stop Code Red from Zope

  1. Log into your Zope management interface and create a new DTML Document. Name it default.ida and put this in it:
    < dtml-call "RESPONSE.redirect('http://127.0.0.1')">
    This works really well for me; Code Red immediately stopped coming up in my logs.

Stop Nimba from Zope

This doesn't work, but it's a neat idea. It's impossible to reconstruct the 13 directory-traversal URLs that Nimda sends, but all is not lost.

  1. Download the Redirector product.
  2. Rename the download to Redirector1_1.tgz and extract its contents to your products directory (in the filesystem, not in Zope).
  3. Log into your Zope management interface and go to Control Panel -> Restart. Click on the Root Folder and add a new Redirector named scripts and pointing to http://127.0.0.1.
  4. Repeat for MSADC, c, and d. Ideally you would do this for _vti_bin, and _mem_bin as well, but Zope won't accept an underscore as the first character of an object title. These will return redirects for all of the access attempts to subfolders, commands, traversals, &c rooted from those locations. The reason it doesn't work is the Redirector Product will interpret the redirection URL instead of returning it. Theoretically this wouldn't happen if you returned some other website name instead of the loopback IP address, but it's just as likely that you'll just be using your bandwidth to go visit that other site. Anyone who tests this out and gets a definitive answer, please let me know.

If you're using Zope on Windows, rules like this might be a pretty good idea anyway since most of the directories being mentioned shouldn't be accessed over the web anyway.

Other resources

Last modified: Oct 24, 2008 2:28 pm.
Contact me.
Powered by Zope