Ongoing malware attack targeting Apache hijacks 20,000 sites | Hacker News Reader

Ongoing malware attack targeting Apache hijacks 20,000 sites

arstechnica.com

60 pointshornokplease33 comments

There is more detailed information available under a few of the links in the article.

Information about what an infection looks like, the attack method, etc: http://malwaremustdie.blogspot.com/2013/03/the-evil-came-bac...

From skimming the article, it sounds like it attacks control panels (mostly Plesk?) and possibly WordPress for remote shell, then does some sort of local privilege escalation. It then adds a module to Apache or Nginx which injects malware into served web pages under certain conditions.

More information about distribution: http://nakedsecurity.sophos.com/2013/03/05/rogue-apache-modu...

It is interesting that the malware hijacks ssh as well. This make me think that RHEL's approach to confining services using SELinux is a good idea, although it is possible that this malware also exploits some weakness there.

If SElinux actually made sense to mortals it might be more widely used. It's dizzyingly complicated to configure correctly.

Sure, but I think Red Hat has done a good job of simplifying things -- the SELinux booleans are pretty straightforward (e.g. "httpd_execmem" is probably something you want to keep off), the included users/roles are fairly useful, and the labels more or less make sense. For desktops, the sandbox tool is pretty handy.

If you need something more complicated, I can see it being difficult (having sweated through the process myself).

If you say something like "httpd_execmem" you've already lost me. That is not straight-forward, that's Byzantine.

RedHat has tried to make this thing more usable, but it's still a greasy pig to wrestle. Applications just mysteriously "don't work" without explanation, and there's no obvious resolution to the problem.

Although iptables is an example of an ornery configuration format, at least it's self-contained. SELinux seems to allow applications to define their own quirky rulesets which complicates things severely.

There will always be an explanation. Anything that 'pings' selinux is logged to audit.log. It might be difficult to decipher some of the rules being hit, but it's easy enough to work around them without disabling selinux wholesale. Look into audit2allow. It makes things MUCH simpler.

Honestly I think this isn't true at this point. It's pretty damn easy with 'audit2allow' (That's a console command) and your audit.log, to fix for just about any issues you have getting your applications working with selinux.

What's better still, is there are a couple selinux modules for Puppet or Chef which allow you to take your audit2allow rules and build them on the fly for any deployed machine!

I've also lost count of the number of times the solution to some problem was to disable SELinux because we can't make it work any other way.

The worst part of SELinux is that it seem to just silently prevent things from working. The entry in its cryptic little log will have almost nothing to do with what didn't work.

If the system acts weird, its either rooted or SELinux is on.

Take a look at AppArmor. It's much simpler since it's based on executable paths instead of metadata attached to executables at filesystem level. Ubuntu uses it.

It is a pain. However, it can be used, provided that one has the patience to keep tweaking and examining the logs.

For replacing ssh they need a priviledge escalation anyway, and after such escalation SELinux makes no difference.

Unless, of course, you run apache as root. Bu then, SELinux won't protect you either.

Actually, SELinux can confine the root user. That said, while kernel exploits will not be stopped by SELinux, there are various other privilege escalation attacks that might be. Brute forcing the root password, exploits in other system processes (maybe even SSH itself), bad (discretionary) permissions, and so forth. Nothing is completely secure, but it is not as simple as, "Well they're on the server now, all is lost!"

If you can log in via ssh (eg brute force) you normally get an unconfined login in normal selinux setups. But 20,000 hosts is not an ssh exploit, that would get more.

Ah I see here http://malwaremustdie.blogspot.co.uk/2013/03/the-evil-came-b... that it only works in non selinux systems...

It's interesting how malware is evolving just like real parasitic organisms. Those that drain host resources too quickly or noticably don't survive. Killing the host kills you too. Here is parasitic software that largely doesn't bother the host, and thus is able to survive and spread more effectively.

Just have a look at your server's /var/log/auth.log file. I see hundreds of intrusion attempts every day. (not running Apache)

One of my servers has Webmin on it, which I rarely use. I'm not sure if deleting it would break anything on the backend so if I were to block the port it uses with SELinux, would that pretty much alleviate the problem until I was sure that removing it would not break anything?

I've already checked the server for any rogue Apache modules and nothing appears out of place.

Never mind. There is a stop script.

Removing Webmin will not effect anything on your server, other than removing Webmin. Webmin operates directly on config files (i.e. it doesn't regenerate configs out of a database or anything wonky, like most control panels do), and doesn't tie into anything in any way that would cause other services to stop working. (Virtualmin, on the other hand, does provide a few bits that could be important...if you've used Virtualmin to configure mail, it will rely on scripts that are part of the Virtualmin install to check for spam and viruses, as well as perform autoreply functions.)

But, Webmin hasn't had a major remote exploit in years (that we know of). In terms of security risks, I consider Webmin pretty low on the list, because of its good security history (see http://webmin.com/security.html for the security history going back several years). It does provide root access, though, which makes it a very valuable target for exploits. As far as we know, Webmin is not implicated as a vector in this particular attack. Plesk has been mentioned as correlated with this attack, but I don't think that's been confirmed, and Plesk has no relation to Webmin, so it seems an odd choice.

Source and disclaimer: I am a developer on the Webmin and Virtualmin projects, and co-founder of Virtualmin, Inc.

Thanks for the info. :) The page I was reading said it was mostly Plesk, but their pastebin file lists Plesk only. I am just covering my bases until everything is known about this. Although it is pretty unfair that I made it seem as if Webmin was specifically identified as having a vulnerability.

As a beginner, I'd rather disable Webmin for now. Just in case! But you are correct; Webmin is probably not affected by this.

Does anyone have any hard facts about this? eg. Versions of Apache that are vulnerable, which extensions, CVE numbers?

I've read that it may have entered through various control panels (Webmin, cPanel, Plesk). I found more info here: http://malwaremustdie.blogspot.com/2013/03/the-evil-came-bac...

We are unaware of any current exploits in Webmin related to this, and I don't think we've had any reports of infected users, so far. That is not to say there aren't currently unknown exploits in Webmin, just that the correlation seems somewhat weak at the moment. And, of course, there have been exploitable conditions in Webmin in the past (the last major remote exploit was many years ago, however; most recent stuff has been XSS variants which would be pretty difficult to exploit, and were not seen in the wild, to my knowledge).

Given that it's supposedly also installing a trojaned version of SSH(d?), it's probably not an Apache exploit at all. It's some other sort of method which gives it root access - either an exploit or just guessing root passwords. :)

If I had to guess, it might be related to this: http://www.cloudlinux.com/blog/clnews/sshd-exploit.php

The details on that page are weak and there are all sorts of problems with the content in general (namely asking users to run a script blindly), but it seems to mimic what is described.

It's very disappointing that they didn't bother to update that news article. The actual source of that "exploit" was compromised admin machines. Everyone that kept having their servers hacked was found to have a rootkit on their local machine. I would not be surprised if this new "exploit" was the same thing.

Or maybe there are still a lot of people out there who are running Apache as root.

I guess it wouldn't be too hard to gain root access once code runs on the server: There are plenty of local privilege attacks in the Linux Kernel and not everybody updates and reboots regularly

By plenty you mean "plenty if you accumulate all the legacy kernel versions", right?

Yes, of course. But for Linux kernels, for every new release for the few maintained stable kernels, they always tell you it's better to update without giving specific details if there are vulnerabilities and who is affected. I personally don't bother to upgrade all the time with minor versions (at least on the systems where the kernel is not from the distribution). Therefore, running something not as root is good, but I should still be afraid of any exploit!

That does matter in the real world, since people routinely fail to update, or are unwilling to update because they cannot afford the minute or two of downtime required to reboot their servers. I know one guy who works with Solaris systems from the mid-90s that cannot be upgraded to anything more recent for various (non-technical) reasons.

If security did not have a human element, these problems would have been solved long ago.

The problems already have been solved long ago, it's just a matter of cost. Ksplice can update the kernel without a reboot, but has a cost. 2 minutes of downtime has a cost. As does not having a backup server and losing the one and only production server.

While I agree it's not an Apache exploit, your post makes no sense. SSH is often tainted via permission elevation due to vulnerabilities in other daemons.

There is an additional good information posted in the Cisco Blog today, the comments part explains good info's: http://blogs.cisco.com/security/apache-darkleech-compromises...

Reply on news.ycombinator.com