Summary: Proactive security would have blocked the Linux Slapper worm and could help stop future worms in their tracks.

Windows users are accustomed to worms, viruses, and Trojans. It's much more rare for Unix-like operating systems to become targets. Perhaps it's because we're more likely to secure our systems; perhaps it's because Open Source software 'is not designed to enable virus replication' [1]; or maybe it's because there are so many Windows machines out there, it's a much more appealing target.

When a worm that attacks Unix-like systems comes round though, it's noteworthy. While there was an Apache worm [2] about two months ago, it didn't seem to catch on at all. Now a new worm -- dubbed linux.slapper.worm -- has started targeting SSL-enabled Apache servers and has had noticeable impact: 30,000 hosts have been compromised as of September 17th. [3]

By now [4], news about the worm has been all over the place, so I won't rehash it in detail. Suffice it to say that a buffer overflow in OpenSSL [5] can be abused on Apache servers that support SSL (Apache + mod_ssl or Apache-SSL) to gain access as the apache user. Patches (OpenSSL 0.9.6e and later) have been out for a while. The bug is in the SSL negotiation, which happens before the actual HTTP data (GET/POST/etc) is sent, which means you won't have any indication in your logs that the attack is occurring.

If the buffer overflow succeeds, the worm uploads a file '/tmp/.bugtraq.c', compiles it, and runs the resulting executable /tmp/.bugtraq. This program starts listening for connections on UDP port 2002, joining a Peer-To-Peer network of cracked machines. This P2P network can be used to create Distributed Denial of Service attacks (IPv4 and IPv6 TCP floods, DNS floods and more) and allow the cracker to run any arbitrary commands on your machine. (A useful example would be to upgrade the P2P code to include new functionality.) Though he does not get root access directly, it's possible to get in and poke around more to see if he can elevate his privileges.

Whew. Now that we've gotten the background out of the way, here's the worst thing about the situation: it's completely preventable. If you follow paranoid procedures when setting up your machine, you would have stopped this worm at several points and either avoid becoming infected at all, or at least keep yourself from becoming part of the P2P network. Let's take a look at generic security practices that could keep this worm in check:

ServerTokens

Many worms check the Daemon's banner before attempting an exploit in order to choose the best attack available. If you set the Apache 'ServerTokens' configuration variable to 'ProductOnly' then it will only broadcast 'Apache' and not the version and installed modules. (For more info about this configuration setting, see [6].)

SSLv2 Support

Most, if not all, Web browsers support SSLv3 now. This particular vulnerability is in the SSLv2 code. If you'd turned off SSLv2, you'd be safe even with buggy OpenSSL libraries.

Upgrades

You need to keep abreast of the security-related patches for your system. Your distro may even have tools to automate this, such as up2date on a Red Hat machine or 'apt-get update && apt-get upgrade' in cron on a Debian machine. Upgrading buggy software means you're not running buggy software. Hard to exploit something that isn't broken....

Minimal Software Installations

The worm requires gcc to compile the .bugtraq.c file. If you didn't install gcc, then the worm will fail before even if it managed to break into your web server. Just as you'd turn off a daemon you aren't using, why keep software installed that you don't need? It only gives an attacker another tool that can make the cracking easier.

Restrictive File Permissions

If you need to have gcc on your machine, put it in a special group that can only be used by developers:

        # groupadd devel
        # chgrp devel `which gcc`
        # chmod 750 `which gcc`

If you restrict the groups allowed to run your software, then meta users like 'apache' and 'www-data' won't be able to use them.

Restrictive Mount Permissions

This worm uploads a file to /tmp, compiles it, and runs it. If you mount /tmp with the 'noexec' flag (and 'nosuid' would be good too) then even if the worm got this far, it wouldn't be able to run the executable.

Paranoid Kernel Networking ACLs

If you've created rules that permit just the network traffic you expect, then the P2P packets on UDP port 2002 would be blocked. You should create rules that detail both inbound (to prevent folks from contacting you) and outbound (to prevent cracker processes on your machine from connecting out) connections. You may only need outbound UDP 53 to your DNS server, for example, and all other UDP packets could be blocked. This would prevent you from being part of the cracked P2P network, even if the exploit had gotten this far.

So if you took these steps, which are not specific to this worm, you would have been protected from this worm at multiple stages. Proactive security would have saved the day.

NOTES

[1] The original quote, "Other e-mail programs are not designed to enable virus replication" was listed in the Melissa Virus warning from Microsoft, as if Outlook had this enviable feature and no one else did. This section was later silently removed from the Web page. http://www.microsoft.com/mac/products/office/2001/virus_alert.asp
[2] September 17th was, incidentally, my fiancee's birthday. Feel free to send her an email at 'birthdaywishes@zerbert.org'.
[3] The Apache Chunked vulnerability, discovered by GOBBLES. *BSD exploit code was distributed, a Linux exploit was hinted at, but never publicly proven.
[4] Due to a mix-up in the ITworld posting system, the wrong message went out last week, so my spectacularly boring worm write-up wasn't sent out on time. Don't worry, you didn't miss anything.
[5] http://online.securityfocus.com/bid/5363
[6] http://www.hackinglinuxexposed.com/articles/20020312.html

Bri Hatch is Chief Hacker at Onsight, Inc., and author of Hacking Linux Exposed and Building Linux VPNs. He believes there's only one piece of software that he considers essential for every machine, and that's vi. Everything else is negotiable. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 24-Sep-2002.