Improper separation of hosting accounts is putting customers at risk

If you are hosting your site at, you are currently at a higher risk of being hacked. Why? Because they do not currently perform proper separation of accounts internally, so anyone can access the pages of everyone else.

How do we know that? We were helping a friend with his site over there and when we checked their permissions, we found a big (BIG) security hole on Hostek. Every PHP script is executed with the permissions of the user “nobody” (used by Apache), and every site allows the user “nobody” to access its files.

It means that any user can access the files from everyone else. Even worse, you can add and even modify the files under some circumstances.


When we realized that the PHP scripts were being executed as the user nobody, we did a simple PHP script to verify that:

echo “verify..n”;
$myloc = `pwd`;
echo “myloc: $mylocn”;
$myid = `id`;
echo “myid: $myidn

We got this output:

verify.. myloc: /home/XXX/public_html done
myid: uid=99(nobody) gid=99(nobody) groups=99(nobody)

Uh-oh, the PHP script is being executed as nobody. We also learned that probably every user has its own home directory at /home/[user] and their public web site is stored at /home/[user]/public_html.

We tried an additional check after with this script:

<? php
$listofusers = `cat /etc/passwd`;
echo "


And yes, we got the list of all the users inside their shared server ( I won’t list the real users to protect them, but everyone had the home dir at /home/[user] and the shell /usr/local/cpanel/bin/noshell):

ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
mysql:x:100:101:MySQL server:/var/lib/mysql:/bin/bash

That’s not too bad. What else could we do? Well, we could list the files from everyone else (I won’t show how to do it):


total 1524
drwxr-x— 24 userB nobody 4096 Oct 30 01:49 .
drwx–x–x 15 userB actionin 4096 Apr 26 2009 ..
-rw——- 1 userB actionin 16 Apr 11 03:57 .ftpquota
-rw-r–r– 1 userB actionin 93 Feb 3 2009 LiveSearchSiteAuth.xml
-rw-r–r– 1 userB actionin 3240 Feb 10 2009 about.php
drwxr-xr-x 2 userB actionin 4096 Nov 30 2007 activate
drwxr-xr-x 7 userB actionin 4096 Mar 10 2009 admin
-rw-r–r– 1 userB actionin 6243 Feb 5 2009 change_password.php

As you can see, the group nobody has the permission to read and execute the public_html directory, so every user can read the files from everyone else.

If that wasn’t bad enough, we were able to cat the passwords from wp-config.php (used by WordPress), configuration.php (used by Joomla) and even .htpasswd used to protect specific directories.

Can it get worse?

What is really bad is that some CMSs (specially Worpdress), have a directory to allow the user to upload files in there via the web. With WordPress it is inside wp-content/upload.

The permissions of this directory allowed the user nobody to add and modify any file in there. So we were able to add files into other people’s site (see test.txt on the screenshot) and even modify anything they had uploaded. Really bad.

And yes, we contacted them to let them know to fix the issue.

  1. I've just spoken to Hostek and they informed me they're aware of the issue, and it only affects one of their servers.

    Sadly, they've said it's got a "special configuration" and cannot be changed (i.e. cannot be secured), so whilst they will move the sites for customers that request such, they won't do anything to close the vulnerability.

  2. Brian tried posting to the following to this blog, but it never asked him to complete the CAPTCHA, so I'm passing this along for him;

    "The server has been fully secured.

    The "Sadly" part above, was based on misinformation from one of our support techs. While the tech was correct this only affected one server, they were incorrect that we weren't going to do anything about it. We take security very seriously and got our Linux server admins working on this issue right away, which allowed us to get the server fully secured now.

    We apparently didn't set that server up correctly. That was our first Linux server we setup, many many years ago. All servers since have been configured correctly, and this one is configured correctly now too. I'm not here to make excuses. I just thought it would be helpful to know these details.

    Additionally, we are working on an email to send to all domain holders on that server letting them know of the change and that they should change any and all passwords associated with their applications and databases to be on the safe side."

  3. What happened to the reply we posted here the day after this was initially posted?

    That issue was on one of the servers, and was resolved immediately upon learning of the issue. Since then we have tightened down security on all of the servers.

    1. Brian, we’ve since moved servers, blog platforms, and commenting systems. Some of the comments didn’t make it through the various transitions.

      If you’d like to repost, please feel free to make any clarifications you’d like.

      Thank you,

      Dre Armeda
      Sucuri Security

  4. They have horrible customer service. I’ve been with them for about a year now and 1 mail server (mail11) craters once a week and takes me to call then to restart it. Brian A is always a jerk and claims there is no problem. Fix this already.

  5. This article is interesting, however it is from 2010, and it is now 3/2013. Why does the article indicate that Hostek was contacted and did not reply. The author admits that they lost comments and other information after the article was written, so they appear to have their own problems.

    I have been a Hostek customer (and a former CTO of a software technology trade association) for about three years, and have been very happy with their 24×7 customer service, the terrific stability of their Windows VPS servers (I have two of them running a combination of SQL Server, PHP, MySQL, and ColdFusion), and their pricing. Previously, I hosted with and it was very unstable and very expensive, so I am not sure why Shane reported a bad experience. He does not specify the particular hosting combination he is/was using.

    So, does the information in the article indicate anything about Hostek as a company in 2010? How about Hostek as a company in 2013? Since that was a Linux server (apparently) mentioned in the article, did the same issues apply to Windows setups?

    I would have liked to see Hostek provide a more complete response (although now it may be too late to get the facts of this 2010 incident) about how that happened on one server (and not others), and how they tightened up “all” the servers later. The article should have also done some more research, or possibly waited longer for a response from Hostek, before publishing and leaving some major questions unanswered.

  6. All of my websites through hostek have been hacked and I have a couple websites hosted with BlueHost that have not. I really don’t want to have to move all of these sites over as I don’t have time. Hope this gets fixed!

Comments are closed.

You May Also Like