46

Could one create a vulnerable website on purpose to attack a server of a hosting provider?

So in the question above which I recently asked we came to the conclusion that preventing one vulnerable website opening the doors to all other websites on the same server must be done by some way of controlling the privileges of the users.

Therefore I was wondering how this is realised in shared webhosting. Is this OS based such as UAC in Windows or how does this conceptually work?

I understand that this may differ from server to server but I would like to understand the options for defense for a hosting provider in order to understand the magnitude of this thread.

  • 1
    What I know is that there are several ways to configure shared hosting, but it's difficult to do it right. One way is to use the right permissions in files and directories to prevent users from seeing other users' files. But the web server process is in common, so it needs permissions to read all the files. PHP is also in common, but that's a problem because it allows you to run your own code, so some solutions are used to make the PHP process execute as the owner of the script itself. – reed May 30 '18 at 10:51
  • So this would mean that by using such a php process to your advantage you could possible bypass user restrictions as an attacker or did I miss something? – Just van der Veeken May 30 '18 at 11:11
  • 1
    Most web server can be configured to switch to a different/unprivileged user account to run PHP. To prevent one tenant from reading the files of other tenants, the host has to configure suEXEC or similar features. – Lie Ryan May 30 '18 at 12:25
  • 2
    Where I worked we used https://www.cloudlinux.com/all-products/product-overview/cloudlinuxos "CloudLinux" which will isolate individual webusers on a server (LAMP) from each other. None are able to access the OS directly and are thus unable to become root (su/sudo) or run exploits, and they can be throttled in many ways. Normal login users are just like users on other distributions. – P. Goetterup May 30 '18 at 13:49

3 Answers3

52

This question is a bit broad, but I think an answer that is a little bit broad will still be helpful. The answer depends on the "kind" of hosting you are talking about. There are three main kinds which I will break down below, but just FYI the names I use are not necessarily industry-standard names. The concepts however are pretty common across the board:

  1. Shared hosting (this is the kind of hosting Jeroen talks about in his answer)
  2. VPS hosting (aka virtual private servers)
  3. Dedicated hosting

Shared Hosting

With a shared hosting setup many websites are running under the same instance of the same OS, and different "websites" are typically separated out by having different user accounts on the same system. cPanel and Plesk are two common software systems that manage such setups (although Plesk can also be used to manage VPS hosting). As a result, you have to concern yourself with securing two primary aspects of your system: making sure that user accounts are properly isolated (see Jeoroen's excellent answer), and making sure that your container manager (Plesk, cPanel, etc...) doesn't have any weaknesses. Those tools do occasionally have vulnerabilities of their own, and if someone manages to break into your container management software, they typically end up with root access to the physical server, or in a worst case scenario, root access to all the servers managed by that system. Also, if you give the users command line access, you have to worry about potential privilege escalation vulnerabilities in the OS itself.

VPS Hosting

With VPS (virtual private server) hosting, the physical server itself is running some sort of virtualization software that then runs any number of "virtual machines" that run a full and separate operating system. Some examples of tools that manage these kinds of setups are the KVM hypervisor or the XEN hypervisor. The advantage of this kind of setup is that it gives the end user (aka the customer of the hosting company) full control over their own system. They can theoretically install any operating system they want, have full root/admin access, and install/manage whatever software they want. The hypervisor keeps each virtual OS separated from the rest and completely sandboxed from one another. Theoretically, it makes it impossible for one compromised host to impact the others at all. In practice of course, things are not always perfect. Although (I believe) it is more rare and harder to exploit, the hypervisors themselves occasionally have their own vulnerabilities that can allow a malicious attacker to take control over the whole system (Spectre and Meltdown were relevant for hypervisors - h/t phyrfox). Like anything else, keeping your systems up-to-date is key.

Dedicated hosting

Some hosting providers offer dedicated hosting, where they basically just manage the hardware for you and provide internet access. They install an OS of your choice on a server and basically just give you root/admin access. Obviously this isn't immediately relevant to your question because this is no longer shared-hosting - no one else to impact. However, they are still inside your network, so proper network access controls are always a must (and this is true for all other hosting instances as well).

Network Management

Edit to add: that last point about network security is worth its own mention. Regardless of whether you use shard hosting, VPS hosting, or dedicated hosting, a hosting company is inherently giving internal network access to an outside party. Without clear access controls, this means that anyone using your hosting services can potentially scan other systems on the network for OS vulnerabilities of their own. For instance, it doesn't matter if your virtualization layer can perfectly isolate the virtual servers running on it if one of the VPS instances can find other instances over the network and gain access via any network-level vulnerabilities in the OS (e.g. heartbleed/eternalblue). Many of the larger hosting companies will allow you (the person using the hosting) to setup a VPC - virtual private cloud - inside their network to isolate your systems from both the internet and other systems on their own network. Presuming that their network rules actually work as promised, this gives the end-user additional ways to protect themselves. Presumably the larger service providers also have active network security that can detect malicious network traffic from inside their own network and shut down accounts appropriately.

In short, the kinds of vulnerabilities you have to worry about depend very much on your hosting configuration. Of course these days there are a whole new slew of hosting options from the large hosting providers (aka serverless infrastructure) which have their own completely separate list of concerns, but I think the above outlines the major concerns for the kinds of hosting you have in mind.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • 1
    This was exactly what I meant! It clearly illustrates the concepts behind privilege control in web hosting. Thanks a lot. – Just van der Veeken May 30 '18 at 12:23
  • 6
    Note that, unless patched, Shared/VPS hosting can be affected by Spectre/Meltdown to bypass any virtualization, so it's important to choose a provider that keeps their software up-to-date. – phyrfox May 30 '18 at 12:45
  • @phyrfox: Yes that. Some people think that virtual machines will solve all security issues... – user21820 May 30 '18 at 13:34
  • @phyrfox I added some comments about network management that (I believe) address your points. Let me know if you feel like I missed something or misunderstood you. – Conor Mancone May 30 '18 at 13:47
  • 2
    @ConorMancone Spectre/Meltdown are the "break out of VM and kernel security model" type vulnerabilities, where, given virtual site A and B, A can deploy special code that can read B's memory, including certificates, keys, passwords, etc. But it's really just a footnote, I think your edit is just fine. – phyrfox May 30 '18 at 14:45
  • @phyrfox I was totally thinking of heartbleed. Too many of these to keep track of them all :) I'll update for clarity – Conor Mancone May 30 '18 at 14:48
  • @phyrfox now I want someone to figure out how to use rowhammer on a VM to break out of a hypervisor... *that* would be a fun vulnerability... – Conor Mancone May 30 '18 at 14:56
  • 2
    FWIW, modern VPS hosting tends to be cheaper than shared; it just requires you to know what you're doing. You can get a low-end VPS (even a real Xen/KVM one, not OpenVZ/container; still more resources than you'd have reliably available on shared) for $2-5/month. Most shared hosting is considerably more expensive. – R.. GitHub STOP HELPING ICE May 30 '18 at 16:23
  • @R.. Thanks, that particular comment (in my post) wasn't really very helpful anyway. I've gone ahead and removed it. – Conor Mancone May 30 '18 at 17:07
  • Shared Hosting is also known as [SaaS](https://en.wikipedia.org/wiki/SaaS) or [PaaS](https://en.wikipedia.org/wiki/PaaS) (depending on what you're hosting), VPS hosting is also known as [IaaS](https://en.wikipedia.org/wiki/IaaS) – Cephalopod May 31 '18 at 10:20
19

Could one create a vulnerable website on purpose to attack a server of a hosting provider?

Yes, this is definitely possible. Since I have only experienced this with Linux based hosting solutions, I can only share my experience in that scenario.

On several occasions I have managed to compromise an entire shared hosting server which was running DirectAdmin / Plesk.

This was due to insufficient file and folder permissions, any user on the system had read access for other users' home directories (world readable) and thus their domain folders and public_html / private_html sub folders.

If one of the domains on the shared server runs a vulnerable application that, for example, allows users to upload files in a non-secure manner, it is possible to upload a web shell.

Once the attacker has access to the web shell and the file / folder permissions are not properly set, the attacker can browse through the entire file system (as long as folders are world readable of course).

It is recommended to configure the file and folder permission as strictly as possible and contain the vulnerability to a specific domain only.

Michael
  • 2,391
  • 2
  • 19
  • 36
Jeroen
  • 5,783
  • 2
  • 18
  • 26
  • Yes I understand, but how are these permissions enforced? How does the hosting provider seperate the privileges of the different domains? – Just van der Veeken May 30 '18 at 10:04
  • 3
    chmod 640 /home/ would be a good start, although I am not sure how Apache would like this if serving a domain from /home//domains//public_html – Jeroen May 30 '18 at 10:09
  • 3
    So actually you are dealing with acces control on the operating system level right? In this case Linux. – Just van der Veeken May 30 '18 at 10:13
  • Correct indeed! – Jeroen May 30 '18 at 10:15
  • 1
    @Jeroen-ITNerdbox: Easy, give group ownership to `www-data` or something to the same extent to everything between `/home/` and `/home//domains//public_html` as well as all children of the latter, then run the HTTP server with the same owner group. Alternatively use ACLs for more fine-grained control. You may also want to include directory traversal permissions, i. e. `chmod 0750`; `0640` locks everybody including the owner out of a directory. – David Foerster May 30 '18 at 16:11
  • @DavidFoerster Thanks for the additional information, makes perfect sense! – Jeroen May 30 '18 at 18:02
  • @DavidFoerster If userA's and userB's website run both as www-data, they will be able to interfere with each other without additional protection. It would be much easier to just run each user's processes as that user. – Dennis May 31 '18 at 19:19
  • @Dennis: If you have stuff in `public_html` that other people shouldn't read I have bad news for you. – David Foerster May 31 '18 at 21:26
  • This isn't at all about `public_html`. If userA's server-side scripts run as `www-data`, a simple `killall -9 apache2` would disrupt the sites of *all* users. userA might provide their own SSL certificates, which apache has to be able to read. Running one instance of apache per user also means that only that's users apache has to be restarted when configuration files are changed. – Dennis May 31 '18 at 21:50
5

This is a rather broad question and it assumes that webhosts actually DO suffiently protect you against this problem.

The typical shared web hosting uses:

  • Apache mod_suexec
  • PHP safe mode, open_basedir and similar measures built in php. This is one of the reasons why almost every shared hosting offer includes php, but rarely perl, python, ruby and so on.
  • Possibly running several php-fpm instances using fastcgi. These can even run on another host than the webserver as long as they can read (and write) the files of the corresponding user..
  • Restrictive permissions for the user homes.

This still has a lot of room for improvements, which are made by the better offers and neglected by the worse ones.

allo
  • 3,173
  • 11
  • 24
  • This question addresses ways of protecting agaings this problem. No assumption is made that webhosts do this sufficiently. Nice to read about some in dept methods though. :) – Just van der Veeken May 30 '18 at 15:13