10 ms·

Ongoing malware attack targeting Apache hijacks 20,000 sites

60 points by hornokplease 14y ago

rwmj 14y ago
Does anyone have any hard facts about this? eg. Versions of Apache that are vulnerable, which extensions, CVE numbers?
- duskwuff 14y ago
  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. :)
  - betterunix 14y ago
    Or maybe there are still a lot of people out there who are running Apache as root.
    - atesti 14y ago
      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
      - antihero 14y ago
        By plenty you mean "plenty if you accumulate all the legacy kernel versions", right?
        betterunix 14y ago
        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.
        brokenparser 14y 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.
        atesti 14y ago
        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!
  - afreak 14y ago
    If I had to guess, it might be related to this: http://www.cloudlinux.com/blog/clnews/sshd-exploit.php 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 14y ago
      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.
  - alekseyk 14y ago
    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.
- vxxzy 14y ago
  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-back-darkleechs-apache.html http://malwaremustdie.blogspot.com/2013/03/the-evil-came-bac...
  - SwellJoe 14y ago
    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).
betterunix 14y ago
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 14y ago
  If SElinux actually made sense to mortals it might be more widely used. It's dizzyingly complicated to configure correctly.
  - TallGuyShort 14y ago
    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.
    - noonespecial 14y ago
      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.
  - betterunix 14y ago
    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 14y ago
      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.
D9u 14y ago
Just have a look at your server's /var/log/auth.log file. I see hundreds of intrusion attempts every day. (not running Apache)
danielparks 14y ago
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-back-darkleechs-apache.html 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-modules-iframe-blackhole-exploit-kit/ http://nakedsecurity.sophos.com/2013/03/05/rogue-apache-modu...
lovehashbrowns 14y ago
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 14y ago
  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 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 14y ago
    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.
ams6110 14y ago
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.
MalwareMustDie 14y ago
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...

60 points by hornokplease 14y ago

rwmj 14y ago

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

duskwuff 14y ago
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. :)
- betterunix 14y ago
  Or maybe there are still a lot of people out there who are running Apache as root.
  - atesti 14y ago
    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
    - antihero 14y ago
      By plenty you mean "plenty if you accumulate all the legacy kernel versions", right?
      - betterunix 14y ago
        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.
        brokenparser 14y 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.
      - atesti 14y ago
        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!
- afreak 14y ago
  If I had to guess, it might be related to this: http://www.cloudlinux.com/blog/clnews/sshd-exploit.php 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 14y ago
    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.
- alekseyk 14y ago
  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.
vxxzy 14y ago
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-back-darkleechs-apache.html http://malwaremustdie.blogspot.com/2013/03/the-evil-came-bac...
- SwellJoe 14y ago
  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).

betterunix 14y ago

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 14y ago
If SElinux actually made sense to mortals it might be more widely used. It's dizzyingly complicated to configure correctly.
- TallGuyShort 14y ago
  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.
  - noonespecial 14y ago
    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.
- betterunix 14y ago
  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 14y ago
    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.

D9u 14y ago

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

danielparks 14y ago

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-back-darkleechs-apache.html 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-modules-iframe-blackhole-exploit-kit/ http://nakedsecurity.sophos.com/2013/03/05/rogue-apache-modu...

lovehashbrowns 14y ago

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 14y ago
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 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 14y ago
  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.

ams6110 14y ago

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.

MalwareMustDie 14y ago

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