Backdoor Targeting Apache Servers Spreads To Nginx, Lighttpd 136
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.
I have a stupid question. (Score:1, Interesting)
Why do the developers force us to tell the world what engine we use?
Re:I have a stupid question. (Score:5, Interesting)
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? (Score:5, Interesting)
Re:There is something wrong with EVERY browser (Score:5, Interesting)
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 [debian.org]
Re:There is something wrong with EVERY browser (Score:4, Interesting)
They attack plugins because flash/java/acrobat are still installed on over 90% of potential targets, whereas the browser market is now diversified...
Re:Why? (Score:4, Interesting)
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 [welivesecurity.com]
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? (Score:4, Interesting)
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:I have a stupid question. (Score:4, Interesting)
> 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/ [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.)