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.
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.
"I opened my eyes, and everything went dark again"
Why isn't there a list of infected sites? Avoiding them would seem to be a priority.
Only on
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.
Why is this hard to detect if you're monitoring the checksums on your server binaries?
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.
now we need to go OSS in diesel cars
You can download a fix here.
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 service) if not available yet.
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.
I knew this was a mistake. Secure my ass. I'm going back to Windows.
I'm a satanic clam.
There's a small number of infected sites. That clearly indicates that this is likely a case of digital burglary rather than the much lower bar of something like a viral infection. Otherwise we would be talking about thousands of sites or half the Internet.
Your screed would be more relevant if not for the fact that there are various fairly common workarounds employed on the various browsers to mitigate just this kind of nonsense.
A little paranoia goes a long way. That's far more useful than the sort of blissful ingorance that tends to be associated with non-OSS software.
A Pirate and a Puritan look the same on a balance sheet.
From what I understand, the hack doesn't affect the binaries on disk, it runs in memory only. Checksum based file checkers don't check running executable.
is this for cpanel or apache?
TFA
"We still don’t know for sure how this malicious software was deployed on the web servers," the researchers admit. "We believe the infection vector is not unique. It cannot be attributed solely to installations of cPanel because only a fraction of the infected servers are using this management software. One thing is clear, this malware does not propagate by itself and it does not exploit a vulnerability in a specific software."
Questions raise, answers kill. Raise questions to stay alive.
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.
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
It's all about advertising, to show just how many people use their webserver.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
They attack plugins because flash/java/acrobat are still installed on over 90% of potential targets, whereas the browser market is now diversified...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
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.
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.
"Little does he know, but there is no 'I' in 'Idiot'!"
What kind of developer thinks that a web server needs a GUI?
Where else are they going to put the ON and OFF buttons?
Il n'y a pas de Planet B.
They have vast botnets, once an IP gets blocked, they just continue from the next IP. I haven't seen brute forcing coming from the entire botnet by default myself, but I'm sure there are crackers that have figured this out by now. You're merely obfuscating the weakness with your solution. Sure, it's effective against quite a few types of drive-by attacks, but the only solution is to stop accepting passwords and require PKI for ssh auth.
I was promised a flying car. Where is my flying car?
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
> 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.)
Restating the obvious since nineteen aught five.
It's going to be useful if someone is trying a targeted attack directly on your server. That way they know what version you are running, and can go to the correct source code trying to find a vulnerability, and not waste time on newer versions, or older versions, or patched versions, or whatever.
Not really. Even targeted attacks are begun by an automated probe that just tries everything and sees what sticks.
It's a foolish thing to care about. The headers shouldn't be there, and if they are, it shouldn't matter. It takes literally seconds or minutes to ferret out what the tool is, and often the site says so right in a page somewhere.
Caring about it is for fools or people who want to lead those fools away from their money.