Mystery Malware Affecting Linux/Apache Web Servers

lisah writes "Reports are beginning to surface that some Web servers running Linux and Apache are unwittingly infecting thousands of computers, exploiting vulnerabilities in QuickTime, Yahoo! Messenger, and Windows. One way to tell if your machine is infected is if you're unable to create a directory name beginning with a numeral. Since details are still sketchy, the best advice right now is to take proactive steps to secure your servers. 'We asked the Apache Software Foundation if it had any advice on how to detect the rootkit or cleanse a server when it's found. According to Mark Cox of the Apache security team, "Whilst details are thin as to how the attackers gained root access to the compromised servers, we currently have no evidence that this is due to an unfixed vulnerability in the Apache HTTP Server." We sent a similar query to Red Hat, the largest vendor of Linux, but all its security team could tell us was that "At this point in time we have not had access to any affected machines and therefore cannot give guidance on which tools would reliably detect the rootkit."'"

Comments

Re:Something's fishy!

[JeepFanatic]

If you run those values through a hex to ascii converter you get SKYNET

The register's older writeup on this ...

[chris.dag]

The Register has been on this for a while and although the story is older it is better written and has more interesting details: http://www.channelregister.co.uk/2008/01/16/mysterious_web_infection_continues/

my $.02 of course

ssh + bad password

[Panaflex]

I see this type of attack all the time, the fact that someone automated it and gave it a zombie machine is not surprising.

* Don't allow root to ssh into your machine.
* Disable ssh1.
* Limit sudoers.
* Have good passwords.
* ???
* PROFIT!!

Seems like a formula everyone should know.

Re:ssh + bad password

[Niten]

I'll see your good point, and raise you a pf.conf snippet:

### MACROS AND TABLES SECTION
table <wan_bruteforce> persist

### PACKET FILTERING SECTION
block in quick on $if_wan inet from <wan_bruteforce>
# ...
pass in on $if_wan inet proto tcp from any to ($if_wan) \
port ssh flags S/SFRA synproxy state \
(max-src-conn-rate 3/30, overload <wan_bruteforce> flush global)

That's how you can block non-massively-distributed password dictionary attacks on the BSDs, anyway. Sadly, the fact that OpenBSD's firewall can perform this task on its own means that we probably won't see this feature worked into OpenSSH itself any time soon -- so on Linux you'll need a third-party script such as DenyHosts, as others have already pointed out.

(And yeah, unlike this PF configuration, DenyHosts lets you synchronize your table with a sort of universal blacklist of blocked hosts, so some might choose to run it on BSD anyway. It sounds like a good idea on paper, but boy does it suck when your home IP address keeps inexplicably winding up on the blacklist due to what turns out to be a single site's massively misconfigured server.)

But I think the most important lesson to be learned here, assuming that this thing does turn out to be an ssh attack, is that allowing single-factor, password-based administrative logins to a highly connected host is never a good idea. If you have the luxury of complete control over the site and its users (or are simply a highly empowered BOFH), disable password-based logins entirely and force the use of ssh public keys:

# /etc/ssh/sshd_config
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
KerberosAuthentication no
GSSApiAuthentication no
UsePAM no

As a concession, if you want to ensure access without having to carry around an encryption key on a USB dongle, on Linux you can use PAM and libpam-opie to set up secondary access using a dual-factor combination of an S/Key one-time password and your regular login password (S/Key is like Steve Gibson's much-trumpeted "Perfect Paper Passwords" system, which is ingenious in its own right, except that S/Key is designed so that you don't need to keep your secret key stored unencrypted on the very server you're worried about protecting):

# /etc/ssh/sshd_config
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
KerberosAuthentication no
GSSApiAuthentication no
UsePAM yes

# /etc/pam.d/ssh
auth requisite pam_opie.so
auth required pam_unix.so nullok_secure

With the above configuration you can still log in seamlessly using your ssh private key. But if you get stuck somewhere without access to your private key, you just pull your S/Key passwords list out of your pocket and enter the next password in the sequence, as prompted, followed by your login password. This PAM configuration has the nice property that if you enter the correct S/Key password but then an incorrect Unix password, you will be asked for the next one-time password in the sequence before you can continue: so unless your attacker is exceptionally good at plaintext attacks on large cryptographic hashes, a successful brute-force attack becomes impossible.

Wow, this post got a lot longer than I wanted it to... I'm, um, going out to get some fresh air or something.

More details are available...

[Anonymous Coward]

... though a solution has not been yet:

http://blog.trendmicro.com/e-commerce-sites-invaded/

If you happen to have one of these compromised systems, I am sure that Trend would like to talk to you about it...

Re:Fail2ban

[whoever57]

Fail2ban is another nice way to deal with these brute force attacks.

You can use fail2ban, but SSH can be protected very nicely with Netfilter/IPTABLES -- just limit the rate of new connections to something like 3 per 3 minutes for each host and this will slow down any dictionary attack to the point that it is very unlikely to be successful.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Should have used IIS

[Niten]

In all seriousness though, IIS 6 has a pretty darn good security track record; seemingly better than Apache 2's, even if it is blasphemy for me to say it. I've previously decried the use of raw vulnerability statistics to make comparative claims about different products' security, but I think the fact that such a widely-deployed product as IIS 6 has been found to have only a single remote access vulnerability in the last four years really speaks for itself.

I mean, I'm just a Unix guy who's never had much use for a Windows web server, but that's my $0.02...