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.
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.
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!
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.
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.
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.
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.
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.
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. :)
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.
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
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.
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...