One of the most frequent problems that we observe in website hosting environments is “cross contamination” — the lateral movement of an attacker between websites. Cross-site contamination occurs when a site is infected by neighboring sites within the same hosting environment due to poor isolation on the server or account configuration. In this post we will review what factors lead to the creation of insecure environments, how malware can move laterally between websites, and how to avoid such pitfalls when hosting multiple websites.
What is lateral movement?
Lateral movement refers to the methods and techniques hackers use to progressively move through a network, aiming to gain access to increasingly privileged or sensitive environments.
In the context of website security, lateral movement primarily involves an attacker gaining unauthorized access to one site on a server and using this as a stepping stone to infiltrate and infect other sites hosted in the same environment. An attacker may take advantage of weak security controls, misconfigurations, or vulnerabilities in websites hosted on the same account.
In essence, the initial compromise of a single poorly-secured site can act as a gateway to potentially compromise more (or all) of the sites on the server or hosting account.
What is cross-site contamination?
Let’s take a closer look at how cross-site contamination occurs. When websites are hosted together in the same environment they quite often have write access to one another. This is particularly true in cPanel environments when multiple “addon domains” are in use, or in virtual private servers (VPS) using an insecure configuration.
By default websites hosted in the same cPanel will be owned by the same owner:group as the primary website located in the main public_html directory. The underlying PHP process running on the server will run as the same user as well. For this reason, files from one website can access (and write to) the files of the other, and vice versa. Under normal circumstances this is not a problem, but when malware is introduced to the environment this can quickly turn a bad situation into a terrible one very quickly.
Why does malware move laterally between websites?
Remember, the goal of malware is to infect as many environments that it can. The more websites that attackers can infect the more potential victims they can exploit. This can be true whether the malware is designed to engage in drive-by-downloads, spread trojans or fake browser updates, or really anything else malware is designed to do. For this reason a common feature of malware is that it will automatically spread from one website to another if given the opportunity.
Some varieties of malware are more notorious for cross-contaminating than others. One such variant is the SocGholish “fake browser update” malware, which will inject itself into any JavaScript file that it has write access to in an infected web hosting environment.
This increases the likelihood that the attackers’ redirect will be effective, makes it more difficult to remove the malware from an infected website, and increases the chances of success — that is, that victims will download their fake browser updates and eventually be targets for ransomware.
We can also see in the source code for the ongoing Balada Injector website malware campaign how cross-site contamination is hard-coded into how it operates. The malware looks as far up the directory structure as possible to identify other websites to infect:
Cross contamination in cPanel environments
A frequently used feature of the standard web hosting environment cPanel are “addon domains“. These are additional domains that can be introduced into a cPanel environment without having to configure a brand new instance. It’s a quick and easy way for website administrators with multiple domains / websites under their purview to get their new project up and running.
What will often happen is that there will be one or two primary websites which garner most of the administrator’s attention and a number of others that don’t receive quite as much love. These “forgotten” websites may not receive timely plugin or theme updates and will therefore have a much higher likelihood of becoming an attack vector.
All it takes is one compromised administrator user or one missed vulnerable plugin update to cause the entire fleet of websites to start belching out malware, resulting in blocklisting by search engines like Google and antivirus vendors.
Insecure Virtual Private Servers
Similarly, we see cross contamination problems and lateral movement on VPS environments that were hastily put together by the website or server administrators. Quite often, administrators will run into “permission denied“ errors when trying to update plugins or upload images in WordPress, which of course are two crucial functions in such environments.
The quickest way to get around this problem is to ensure that the files and directories are owned by www-data:www-data, or, in other words, owned by Apache itself. When there are multiple websites in /var/www/vhosts for example, and they are all owned by Apache – you guessed it – they all have write access to one another!
Again, exactly like cPanel addon domains, all it takes is a single compromised password or vulnerable software component for every single website to get infected with the same malware. This turns what would otherwise be a modest headache into something that could potentially ruin a website development business.
How to prevent lateral movement and cross-site contamination for your website
Fortunately, issues with lateral movement and cross-site contamination can be mitigated if proper steps and precautions are taken. It’s a little less convenient than dumping all the websites into the same container, but in the long run you will thank yourself as it will potentially save you a huge amount of hassle in the event of a compromise.
Preventing cross contamination in cPanel
What you’re going to want to do for cPanel environments is set up a separate cPanel instance for each website. This can be accomplished in a couple of different ways depending on your hosting provider:
- Multiple hosting plans
- Web host manager (WHM) environment
Most hosting providers are resellers of WHM / cPanel and you can likely arrange one with your host.
This website management interface is managed by the same company that creates cPanel and they are designed to work together. Once you have got your WHM instance set up you can follow the steps from the official documentation on how to create a new account and get your website cPanel homes configured.
Important note: Since the whole point of separating your website environments into their own cPanels is to make them more secure, be sure to enable symlink protection as well! This is located in the global Apache settings. While it does create a performance decrease on your website’s speed without this enabled it is possible under certain conditions for attackers to move laterally between websites. The usage of PHP’s open_basedir is also recommended to limit unauthorized access.
Preventing cross contamination in a VPS
Tech-savvy individuals who want a more hands-on experience and control over their environments often opt to configure their own virtualized server environment. This is also true of folks who want to avoid the potentially costly licensing fees for using proprietary software like WHM / cPanel. However, it is unfortunately quite common for these to be configured in such a way as to permit cross contamination (as explained above).
Although there are different ways that this can be achieved one option to configure your server and avoid cross contamination is to utilize PHP-FPM to create separate “containers”.
To briefly sum it up:
- Each website should live in its own designated home directory
- The website files and directories should be owned by their own respective user
- The underlying php process running on the server should also be run by the website’s same user
Once these principles are followed you can host many websites on the same virtualized server while also discouraging cross-contamination, as the files from one user should not be able to write to the others. In this way, if a compromise occurs on one website it is much less likely to spread to others on the same server.
Help, my websites have been hacked!
If you’ve already found yourself with a messy situation and a bunch of infected websites, don’t fret! We can help! In fact, we have security plans tailored specifically for agencies, developers, hosting providers, and other folks who manage more than a single site. We offer competitive pricing and volume discounts for large environments and provide top-tier support for such clients (in fact, I might just clean your websites myself!).
Feel free to get in touch with our sales team if you’d like to inquire about our website security services or check out our Junior Dev plan if you only have a handful of sites. Better yet, you can put your website behind our web application firewall to help prevent vulnerability exploits and protect your websites from getting hacked in the first place.
Ben Martin
Denis Sinegubko
Rianna MacLeod
Val Vesa
Gerson Ruiz
Marc Kranat
Ashley Sand
Keir Desailly