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.
Not an apache/nginx/lightttpd vulnerability (Score:3, Informative)
Those servers somewhat (i.e. a vulnerable web app, weak ssh passwords, local privilege escalation on a shell got in in some way, or a combo of all of those) got rooted, and instead of modifying web pages (easier, but also easier to detect and fix), replacing the entire web server (easier to detect or to roll back) or changed the configuration of i.e. mod_rewrite modules (that with a configuration manager could had been detected/roll back to the original one). got some new modules replaced/added, modules that in particular had that functionality.
Is nothing particulary new in this, more than the malware authors not being just script kiddies and actually did some serious programming for it. Somewhat I hope that they give back to the community releasing the source, not the malware backdoor itself, but with a modified, non malware version with an useful use (i.e. something that dynamically blacklists IPs/useragents/languages for actions, receiving the input from another kind of system, like a honeywords [slashdot.org] service) if not available yet.
Re:And they still don't know the initial vector (Score:4, Informative)
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 (Score:5, Informative)
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 (Score:3, Informative)
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 (Score:3, Informative)
Re:I have a stupid question. (Score:4, Informative)
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:I have a stupid question. (Score:2, Informative)
So how do you do that in Apache?
You're looking for ServerTokens and/or ServerSignature.
But as the comment says:
# Changing the following options will not really affect the security of the
# server, but might make attacks slightly more difficult in some cases.
Re:And they still don't know the initial vector (Score:4, Informative)
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
Re:There is something wrong with EVERY browser (Score:4, Informative)
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:And they still don't know the initial vector (Score:2, Informative)
Also don't use user/password ssh logins. RSA authentication only.