AIM or Yahoo! Messenger:
GTDreamsmith

Countermeasures

The question arises: what can people do to stop Code Red or worms in general?

Countering Code Red

If you run a Microsoft web server, install the friggin' patch already!

Usually, though, this question is asked by those of us who don't run a Microsoft server, or those who have already patched their servers. What can we do to help bring an end to the Code Red plague?

One interesting attempt at a solution was posted on Slashdot recently. Someone had developed a script that could be placed in your webserver's root directory, named "default.ida". Once you modified your httpd.conf (assuming you use Apache) to recognize this as a CGI script, it would be run any time another system attempted to attack your system. This particular script would fire back a request to the originating server that would attempt to issue the "iisreset /stop" command to stop the webserver, preventing further spread of the worm.

Cute idea, but two flaws. First, once the webserver goes down, someone is likely to notice sooner or later and reset it, at which point it will be promptly reinfected and start attacking other systems again. Second, it doesn't work. Even Microsoft isn't stupid enough to let script users issue an "iisreset" command. (This could be fixed by giving the script user administrator privileges, but regardless of what I may have said about NT sysadmins in the past, even they aren't that stupid.)

In any case, what needs to be done is to get that security patch installed. Also, if the system is compromised, any number of other bad things may have been done to the system, so really, the system needs to be wiped, reformatted, and then the patch applied to the newly installed system. This is not something that can be done remotely for these poor sysadmins.

Informing them, on the other hand, is something that can be done. My own variation on the "default.ida" script idea sends to the offending server the "start http://www.dreamsmith.org/codered/infected.shtml" command, which opens their web browser and points it to a page that lets them know they're infected, and contains links to information on how to fix the problem. They can then fix it permanently, instead of it simply being averted until the server is reset and starts at it all over again.

Ultimately, this doesn't quite work either. It works sometimes, and my access logs show a number of successful browser launches, but sometimes the attacker closes the connection too quickly, which seems to cause the script to either abort before sending the command or even not to execute in the first place. So I see the attack in my log, but no response from the script. This was the main reason I created the Code Red Special Edition of LogJack. Since the attempt gets logged regardless of whether there's enough time for a script to respond, a better way of dealing with this is not with a CGI script but with a logger that recognizes the attack as it's written to the log and responds accordingly. By operating independently of the webserver, it isn't held hostage to the short time Code Red sometimes gives a CGI script.

This works better, but isn't perfect, either. Frequently the attempt to open the other system's browser doesn't work. The worm is obviously running or my system wouldn't have been attacked by it, but the backdoor the worm usually creates in a system either isn't there or isn't exploitable due to other factors. I assume that frequently the IP I'm receiving as the attacker's is in fact the product of NAT (Network Address Translation), and my return request is bring routed to the company's standard webserver rather than back to the machine that actually initiated the attack from behind the safety of the NAT-ing firewall. Thus, I can't even identify the true originator of the attack, much less open its browser to notify its user that it is infected. Even without NAT, some firewalls will allow outgoing but not incoming port 80 traffic, thus the bloody worm can attack anyone but no one can get to it.

Of course, if it's behind a firewall, NAT-ing or not, how the bloody hell did it get infected to begin with? That's easy. The company's externally addressable webserver was infected, and from there the infection spread through the internal machines. Whatever idiot they have administering the webserver may even have patched the thing by now, but he or she probably never bothered to patch the ones behind the firewall. I've gotten so many attacks from one particular IP belonging to CS Solutions, Inc. of Bloomington, Minnesota that I assume there's actually a small herd of infected machines behind a NAT-ing firewall launching these attacks. (Just how many copies of NT/2000 Server do you need running in your organization, anyway? I know they don't scale like a Unix box, but still...)

Aside from firing off notification by email, I'm not sure what more can be done in cases like this. Eventually, the entire office will be upgraded to a newer version of NT/2000/XP/whatever. Any hope of purging the infection before that would require competent system administrators, which they obviously don't have. I doubt the information sent by email is going to help, but what the heck, it was worth a shot...

I've heard all the Code Red worms will simply stop at some point in the future. That'll be nice. But what if the next big worm doesn't come with an expiration date?

Countering Worms and Virii In General

Although the "in general" is harder to actually solve, it's easier to answer. Whether it's with potatoes or computers, homogeneity greatly aids the spread of disease. Too many computers running identical software on identical operating systems under identical microprocessors makes the spread of any worm or virus extremely easy, and extremely devestating. Thus, an ideal network should have a good mix of microprocessor types, operating systems, and software. Don't get all your solutions from a single source. Ideally, don't get a majority from any single source. Create heterogeneous networks. If certain companies refuse to produce products that conform to public standards or don't work well with products that aren't produced by the same company, don't be stupid enough to buy anything from them.

Of course, in the real world, Microsoft uses its monopoly power to ram its products down the throats of anyone who wants to stay in business. Thus, that last bit of advice may be unimplementable. On the other hand, there are certain benefits to this. Although the world in general is a lot less safe, companies that choose non-Microsoft solutions become safer. In any area where one product dominates, any alternative becomes virtually immune to attack. For example (and to pick on someone other than Microsoft for a change), because Intel and Intel compatible processors (AMD, etc.) so completely dominate the market, any computer that uses an incompatible processor (like a Sun SPARC, Digital Alpha, or Apple Macintosh, for example) is guarenteed to be immune to any common virus, or worm that relies on a buffer overflow to execute machine code. What is executable machine code to a common Intel compatible processor is random garbage to these SPARC, Alpha, or PowerPC-based machines. Of course, virii can be written for these processors, or worms that use their machine code, but then because there are so few of these kinds of machines (relatively speaking), these virii or worms just won't spread very quickly or very well. Microsoft's dominance in the OS market and Intel's dominance in the microprocessor market make non-Microsoft and non-Intel solutions much safer that they would otherwise be.

In short, diseases spread best in the herd. The best way to avoid them is not to join the herd. Using non-Microsoft software on non-Intel hardware is the single best defense you can have. This should be done whenever and whereever possible.

Sometimes it just isn't possible, though, for various reasons. The next step then is to do your job as a system administrator. This means keeping informed and applying security patches quickly. Subscribe to BugTraq. Spend some time every day checking into the major IT news sites for the latest information. Code Red only continues to be a problem now because so many adminstrators still don't know what's going on and what they can do about it. You're in the Information Technology field, you need information to do you job. If your boss tells you he's not paying you to surf the web, politely correct him. That's a basic and necessary part of your job, it is in fact exactly what he's paying you for if he's paying you to be a system administrator. You must stay informed and stay on top of those patches! This alone would have prevented the outbreak of Code Red, which occured well after the problem it exploits was discovered and corrected with a free security patch downloadable from microsoft.com. I don't know what the next big worm will be, but I'd be willing to bet the same will be true of it. The only people directly affected by it will be the uninformed -- those who refuse to actually do their job as system administrators.

Unfortunately, if it's like Code Red, those of us not directly affected will still feel the fallout, as the Internet strains under the load of another massive worm infestation.

Or maybe the IT industry will get smart by then...

I'm not holding my breath.