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
________________________________________________________________________
AUTHOR'S NOTE
In an effort to keep the Linux Security information flowing, check out
my new weekly column: 'Linux Security: Tips, Tricks, and Hackery'. It
will offer weekly tidbits of security knowledge to help you keep your
Linux (or other Unix) system secure. You can sign up now by going to the
following URL: http://lists.onsight.com/
Or send an email with the word 'Subscribe' in the subject to:
Linux_Security-request@lists.onsight.com
Please note that you will *not* be automatically subscribed to the new
list.
I look forward to having you on the new list!
Brian Hatch (bri@hackinglinuxexposed.com)
