Suspicious process /usr/bin/host run by users on server

[tobaniyi]

Hello,

I noticed some users running a suspicious process /usr/bin/host on a couple of our servers. In some cases, this process takes a lot of resources. When I got an automated mail from a server provider that WordPress sites were being bruteforced from our server, I got more worried. When I investigated the accounts further, I discovered the following

1. They were running either WordPress or Joomla which suggests they could have been compromised
2. The accounts has a file .sd0 uploaded in either the public_html folder or one of the folders of either Joomla or WordPress such as a themes folder
3. The accounts have a cronjob running (in some cases multiple instances of the cronjob) with a directory similar to where the .sd0 file was uploaded. A sample of such cronjob is /home/xxxxxx/public_html/wp-content/themes/twentytwelve/1.sh . Note that the file 1.sh

My guess is that the sd0 file runs an API that creates the cron. Has anyone had this issue before or heard of it? I have told the owners of the accounts to upgrade and secure their installations but I cannot trust they would attend to this quickly enough.


Hope someone can help...

 

[vanessa]

We see it all the time, and yes, it is a hack. Exploits against Wordpress and Joomla are pretty common and some of us deal with hundreds, if not thousands, of these a week. Make sure your users are running up to date versions of their software, including plugins. Check it out:

Fake WordPress Plugins

 

[tobaniyi]

We see it all the time, and yes, it is a hack. Exploits against Wordpress and Joomla are pretty common and some of us deal with hundreds, if not thousands, of these a week. Make sure your users are running up to date versions of their software, including plugins. Check it out:

Fake WordPress Plugins

Hello Vanessa,

Thank you for the quick response. I do understand these exploits are common but this particular issue is quite troubling because the hacker is trying to bruteforce other servers. While we always encourage clients to update their installations, a lot of them are usually either clueless or just plain slow at making necessary changes and sometimes we are forced to suspend troublesome accounts. I would like to know if it is possible to disable the ability to create cronjobs from a script and possibly if restricting access to /usr/bin/host would be the best solution as whenever we remove the troublesome script, it just comes back.


Thanks again

 

[cPanelMichael]

You could add the users that you do not want using cron jobs to the following file:

/etc/cron.deny

Also, as for overall security, browse to:

"WHM Home » Security Center » Security Advisor"

This is a good place to start when attempting to increase the security of your system.

Thank you.

 

[tobaniyi]

You could add the users that you do not want using cron jobs to the following file:

/etc/cron.deny

Also, as for overall security, browse to:

"WHM Home » Security Center » Security Advisor"

This is a good place to start when attempting to increase the security of your system.

Thank you.

Thanks for this Michael. I have prevented the affected users from running crons. Other accounts however get compromised and they seem to run either WordPress or Joomla. Still investigating this. Would be grateful if someone has found a permanent fix or is it possible to prevent a file, say the .sd0 file, from being uploaded or running on the server?


Thanks again

 

[cPanelPeter]

Hello,

There will never be a permanent fix. It's a cat and mouse game between you and the hackers. Once you find a way to stop them, they will simply find a new way in. The best thing you can do is install a good firewall (I personally recommend CSF), and also an exploit scanner and I again recommend CXS.

These will help you, but there is no 100% effective way of preventing hackers from gaining access except completely turning off your server.

 

[quizknows]

I investigated this particular piece of malware this week.

The base of it is indeed CMS compromise.

How /usr/bin/host is involved is a bit more advanced. Programs use libraries (.so files) for some of their functions. Users can prelink (LD_PRELOAD) some .so file(s) before launching a legitimate binary to change how it acts.

in this case, the hack uses LD_PRELOAD to load a bogus .so file, which changes how 'host' acts and lets it be used to attack other sites. Your actual /usr/bin/host file is fine, and (most likely) your server isn't rooted. It's just a very creative way to launch an attack from a hacked site.

Also from a very brief analysis of the code, it appears to have a fallback to execute directly if cron access is denied.

 

[tobaniyi]

Hello,

There will never be a permanent fix. It's a cat and mouse game between you and the hackers. Once you find a way to stop them, they will simply find a new way in. The best thing you can do is install a good firewall (I personally recommend CSF), and also an exploit scanner and I again recommend CXS.

These will help you, but there is no 100% effective way of preventing hackers from gaining access except completely turning off your server.

Thanks for your response Peter. We already run CSF and I would check out CXS. At this point however, I was asking if there is a way to stop this particular exploit as preventing the accounts from running crons does not solve the problem as more accounts may just be compromised. As I mentioned, this is a CMS compromise and except all users run updated applications (which is not possible), the hacker would just keep using other accounts.

 

[tobaniyi]

I investigated this particular piece of malware this week.

The base of it is indeed CMS compromise.

How /usr/bin/host is involved is a bit more advanced. Programs use libraries (.so files) for some of their functions. Users can prelink (LD_PRELOAD) some .so file(s) before launching a legitimate binary to change how it acts.

in this case, the hack uses LD_PRELOAD to load a bogus .so file, which changes how 'host' acts and lets it be used to attack other sites. Your actual /usr/bin/host file is fine, and (most likely) your server isn't rooted. It's just a very creative way to launch an attack from a hacked site.

Also from a very brief analysis of the code, it appears to have a fallback to execute directly if cron access is denied.

I am so glad to hear that you know about this exploit and I have noticed as you stated that the script can still run even when crons are disabled. Is there a way to prevent this particular exploit from running on a server as at this stage, it is a manual process. Isn't there a way to prevent a file from running for instance?


Thanks again.

 

[Alex Vojacek]

I too want to find how can we block this particular exploit, I have 2 servers on cpanel who have massive ammounts of this /usr/bin/host open and limiting cron is of no use.

This is some kind of brute-force script attack, i want it block for good!

 

[quizknows]

This script, while creative, has no more priveleges than any other DoS or brute force script that can be run from a hacked site.

The usernames on your server affected by this script are probably running out-of-date CMS software, or have had their admin passwords for their CMS software compromised. I would start by updating the passwords and software, removing any un-used plugins or themes, and re-installing any plugins/themes that are in use. Also look at any recently modified files in the accounts, i.e.

find /home/$username/public_html/ -ctime -10

(files changed in the last 10 days, you can try with -mtime as well or change the number of days)

 

[ThinIce]

Out of interest, does cagefs still disallow access to host by default...?

 

[lgj]

Just in the case your server slows down, because of this, to a crawl, kill the apache process that uses the /usr/bin/host

$> ps aux

[lookup the process PID]

$> kill -9 XXXX

 

[texas90]

Cagefs with cloudlinux did the trick for me. I am nolonger seeing these processes and the server load is very low now.

Edit: I wrote too early. These processes are back. Even though CageFS and Cloudlinux are running.