

Ongoing malware attack targeting Apache hijacks 20,000 sites - hornokplease
http://arstechnica.com/security/2013/04/exclusive-ongoing-malware-attack-targeting-apache-hijacks-20000-sites/

======
danielparks
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...](http://malwaremustdie.blogspot.com/2013/03/the-evil-came-back-
darkleechs-apache.html)

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...](http://nakedsecurity.sophos.com/2013/03/05/rogue-apache-modules-
iframe-blackhole-exploit-kit/)

------
betterunix
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.

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

~~~
betterunix
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).

~~~
astrodust
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.

~~~
druiid
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.

------
ams6110
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.

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

------
lovehashbrowns
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.

~~~
SwellJoe
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.

~~~
lovehashbrowns
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.

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

~~~
duskwuff
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. :)

~~~
afreak
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.

~~~
devicenull
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.

------
MalwareMustDie
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...](http://blogs.cisco.com/security/apache-darkleech-
compromises/)

