Backdoor Targeting Apache Servers Spreads To Nginx, Lighttpd

An anonymous reader writes "Last week's revelation of the existence of Linux/Cdorked.A, a highly advanced and stealthy Apache backdoor used to drive traffic from legitimate compromised sites to malicious websites carrying Blackhole exploit packs, was only the beginning — ESET's continuing investigation has now revealed that the backdoor also infects sites running the nginx and Lighttpd webservers. Researchers have, so far, detected more than 400 webservers infected with the backdoor, and 50 of them are among the world's most popular and visited websites." Here's the researchers' original report.

Comments

Re:I have a stupid question.

[TheCarp]

Are you refering to the http headers that identify the server version? If so then yes, it is a stupid question since, every webserver which I have ever configured has had an option to turn that off. Not that I ever bothered, if it was so useful, it would be turned off by default.

Fingerprinting doesn't take that long, especially for well known services. Might be of some use if you really to run something obscure. In any case, even if they don't know if you are vulnerable, how long does it take to find out? Little use there.

Why?

[centipedes.in.my.vag]

Why isn't there a list of infected sites? Avoiding them would seem to be a priority.

Re:Why?

[Skapare]

Are you afraid of little infected web site? Something wrong with your browser?

Re:Why?

[centipedes.in.my.vag]

Yes. My entire family will be calling for free tech support as their machines eat crap. This affects me directly and greatly, as I'm sure it similarly affects many other frequent posters here. Also personally, yes, no browser is invincible and I'd like to avoid infection as well.

Re:Why?

[dotancohen]

Why isn't there a list of infected sites? Avoiding them would seem to be a priority.

Here is how to make sure you are not one of the infected sites: Compile and run this:
http://www.welivesecurity.com/wp-content/uploads/2013/04/dump_cdorked_config.c

If you don't want to vet that, you can get a first-aproximation with "ipcs", just look for the Apache PID, which you can get from "ps aux | grep apache2".

Re:Why?

[mwvdlee]

How exactly does your browser recognize the difference between a normal page and the exact same page delivered from the exact same server at perhaps a microsecond delay?

This backdoor may simply be passing on POSTs with passwords (a webserver receives these unencrypted, you know) to another server without altering anything on the page. The only one who'd notice would be a webserver admin that happens to monitor outgoing traffic.

Re:Why?

[Opportunist]

Find out what they're experts in, become a complete idiot in that field and start pestering them with requests for help.

Keeps my dad away. Though I now have to pay for repairs when my car breaks down.

Name the 50 sites

[PNutts]

The actual quote is, "50 are ranked in Alexa’s top 100,000 most popular websites." Quite different than the summary but would still be interesting to know.

And they still don't know the initial vector

[Skapare]

We also don’t have enough information to pinpoint how those servers are initially being hacked, but we are thinking through SSHD-based brute force attacks.

So does this mean I need to remove sshd? Doubtful. More likely the initial vector is social engineering or weak passwords (social stupidity). That makes this whole infection uninteresting ... it's just an app from the web server perspective. OK, so it can break into your browser with a zero-day. Fix the browser.

Re:And they still don't know the initial vector

[phantomfive]

So does this mean I need to remove sshd?

No, it means you need a more complicated password.

And it seems to be just a guess, they probably came to 'sshd' by following a line of reasoning starting with the only thing they could think of that all the hacked servers have in common.

Re:And they still don't know the initial vector

[lgftsa]

Worried about exposed sshd? Install pam-abl and watch the brute force attackers waste their time. With my config, three failures from any IP address in an hour (or 6 per day) and that IP is locked out for a week through PAM. They can still try, of course, but even if they somehow guess the correct password, it must be in their first three guesses each week.

There's no indication to the attacker that pam-abl is there, and there's very little chance of a DOS attack against legitimate logins.

Oh, and you've denied root logins from the internet, haven't you?

Warning: Source tarball, but if I debian-ized it, then anyone can.

Re:And they still don't know the initial vector

[thetoastman]

There are quite a number of ways to harden access

1. pam-abl (as noted above)
2. denyhosts
3. VPN (openvpn works for me)
4. Hosting ISP firewall

Also as noted above, do not permit direct remote root access. Doing anything less is just advertising yourself as a platform for malware.

The first three are quite easy to set up. There is really no excuse for not setting up a least a minimum level of security on your system. That plus careful use of mod_security, and you've done quite a bit towards thwarting the casual drive-by cracker.

. . . . just my two cents

Re:And they still don't know the initial vector

[mtb_ogre]

[quote]No, it means you need a more complicated password.[/quote] Or better still, generate a key and turn off passwords entirely.

Re:And they still don't know the initial vector

[nedwidek]

And if not fail2ban, a good first step is updating the firewall rules to have a rate limiter on sshd. Mine allows only 2 attempts to connect a minute.

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --set
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 2 -j DROP
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Fix

[Frankie70]

You can download a fix here.

Re:There is something wrong with EVERY browser

[DarkTempes]

I run lynx/links/etc in a chroot jail, you insensitive clod!

In my experience most of the major browser exploits attack vulnerable plugins (flash, java, acrobat/pdf viewer, etc) or abuse scripting.
If you restrict or disable said plugins and javascript then I'd say you're pretty darn safe.
Granted, most "web 2.0" websites work like shit without javascript enabled but some stuff still works. For the more sane of us there are things like NoScript.

It's kind of hard for plain text and images to do bad things though I suppose it's been done before.

screw it

[clam666]

I knew this was a mistake. Secure my ass. I'm going back to Windows.

Re:and this is why....

[Anonymous Coward]

FreeBSD runs the same software stack, so it would make little difference.

That's why our organization uses a custom server software written in 68K assembly running on MacOS 7.6.1 on a cluster of Quadra 610s.

Re:There is something wrong with EVERY browser

[lindi]

From Debian 7 release notes:

"Therefore, browsers built upon the webkit, qtwebkit and khtml engines are included in Wheezy, but not covered by security support. These browsers should not be used against untrusted websites. For general web browser use we recommend browsers building on the Mozilla xulrunner engine (Iceweasel and Iceape) or Chromium."

-- http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security

Re:I have a stupid question.

[Bert64]

It's all about advertising, to show just how many people use their webserver.

Re:There is something wrong with EVERY browser

[Bert64]

They attack plugins because flash/java/acrobat are still installed on over 90% of potential targets, whereas the browser market is now diversified...

Re:I have a stupid question.

[gmack]

Quite frankly, I don't think the webserver was the entry point for Cdorkd.A since as far as I read it was mainly machines with cpanel that were infected. Even if the problem wasn't cpanel Apache doesn't run with the right permissions to change it's own binary. If the entry point is elsewhere, once they are in the machine with root access discovering what web server software being used is trivial.

Rather than worrying about something as trivial as the web server software, I would be much more concerned about why none of the control panels I've come across seem to have any sort of secure design. They run as root without any sort of privilege separation and edit the config files even when daemons are available that have a database back end.

Re:There is something wrong with EVERY browser

[dkf]

It's kind of hard for plain text and images to do bad things though I suppose it's been done before.

There have been vulnerabilities in PNG and JPG image format handlers in the past, so yes, there has definitely been the potential to have images do bad things. (Arguably none would be as bad as using some of the ones relating to goatse, but that's a different kind of problem.) If you hear of problems in fundamental media type handlers, for goodness sake make sure you're up to date with your security patches!

I don't know if there were any exploits of those problems in the wild though.

Re:I have a stupid question.

[Zontar The Mindless]

What kind of developer thinks that a web server needs a GUI?

Where else are they going to put the ON and OFF buttons?

Re:I have a stupid question.

[Zero__Kelvin]

CPanel is often used to allow Web Hosting customers to have control over their pay per month websites / accounts. If a company allows their customers to create email accounts, enable ssh, etc. on a shared host this is how it is typically done to reduce the huge overhead of fielding requests for such tasks from every Tom, Dick, and Harry, since you clearly cannot give them root access.

Implemented an idea poorly does not make it a bad idea.

Re:I have a stupid question.

[Yebyen]

> since you clearly cannot give them root access.

and yet that's what it seems to be doing here. I heard a lot of folks say that LXC was DOA, because it didn't offer any protection against the classic "escalate chrooted root user to full system access," and I am not an expert but I'd say that has changed, you _can_ give your customers root without giving them root on the host system. Check out http://docker.io/ </shameless>

(I heard there were alternatives to docker too, but I haven't found any other than RTFM and Edit The Damn Configs And Cross Your Fingers. Docker has just entered version 0.3 release and development is moving quickly.)