Table of contents of the article:
Introduction
In UNIX and Linux systems, security and separation of privileges are a key element to ensure data protection and correct management of file access. The heart of this system is based on user identifiers (UID) and groups (GID), accompanied by a permission system that regulates read, write and execute operations on files (rwx). Each process running on the operating system is associated with a specific UID and GID, limiting access to files and preventing potential exploits by malicious processes. This structured approach ensures that different users and processes cannot access each other's files unless they have explicit permissions, creating a critical line of defense against many security vulnerabilities.
However, despite these solid principles underlying UNIX and Linux, many commercial control panels such as cPanel, Plesk, and DirectAdmin adopt a third-level management (subdomains) that puts the security of users at risk. In this article we will explore how these panels manage subdomains, the problems related to UID/GID sharing and the potential vulnerabilities that arise from this architecture, while offering solutions and advice on how professional management can ensure greater security.
Third Level Management in Control Panels: cPanel, Plesk, DirectAdmin
Linux control panels like cPanel, Plesk e DirectAdmin are among the most used in the web hosting industry for their intuitive interface and ability to simplify complex technical operations. However, when it comes to subdomain management, these tools have significant security gaps.
When you create a third level (a subdomain) such as, for example, blog.dominio.com, these panels tend to place it as a directory nested within the main domain's home directory. For example, in cPanel a subdomain directory might be structured as follows:
/home/user_name/public_html/blog
Even in Plesk and DirectAdmin the logic is similar:
/var/www/vhosts/domain.com/blog
This organization has significant implications: the subdomain does not have a separate UID/GID, but runs with the same permissions (user and group) as the main domain. This means that all PHP processes (and other web processes) run with the same privileges as the main domain.
The Security Problem: Sharing UIDs and GIDs
One of the main issues with managing subdomains in these panels is the sharing of UIDs and GIDs between the main domain and its subdomains. Since subdomains are simply directories within the main domain and share the same execution permissions, any vulnerability discovered in a subdomain can compromise the entire main domain installation.
To better clarify the concept, let's take a practical example.
Case study: examplestore.com
Let's imagine the case of a company that manages the main domain esempiostore.com, where a modern PrestaShop 8 installation is hosted for online sales. However, for historical, accounting and tax reasons, the same company maintains an old subdomain old.esempiostore.com which hosts an outdated version of PrestaShop 1.6.
In the Control Panel, this subdomain is managed as a simple directory within the main installation, with a path similar to /home/esempiostore.com/public_html/old.
Attack scenario
An attacker discovers a vulnerability in an outdated module of the old PrestaShop 1.6 installation in the subdomain old.esempiostore.com. By exploiting this vulnerability, the attacker is able to gain administrative access to the platform and loads a PHP shell or file manager. From there, the attacker has the ability to read and modify files within the subdomain directory.
But the real problem arises from the fact that, since the subdomains share the same permissions as the main domain, the attacker can freely navigate to the parent directory and access the configuration files of the main domain. esempiostore.com. For example, the attacker could access the file parameters.php of PrestaShop 8, which contains the database access credentials.
At this point, the attacker has everything he needs to compromise the entire main domain. He could access the database, create a new administrator account, and gain full control over the new PrestaShop 8 installation, which until then was considered safe and up to date.
The importance of separation of privileges
In a UNIX/Linux operating system, separation of privileges is one of the fundamental principles of security. Each process or operation within the system is run by a user with a specific UID (User ID) and GID (Group ID), and these identifiers control access to resources such as files, directories, and processes. This model, known as Discretionary Access Control (DAC), allows you to strictly limit what a user or process can do, creating a security perimeter around critical data and applications. In multitenant environments, such as those where multiple domains and subdomains share resources, privilege separation becomes essential to ensure that a security breach in one area of the system cannot propagate to others.
How Privilege Separation Should Work in a Web Environment
In an ideal context, each domain or subdomain should have its own isolated environment, with its own separate UID and GID, so that a process started inside one domain cannot access files from other domains. This isolation is not just theoretical, but a standard practice in more secure setups, for example with the use of containers like Docker or isolated environments with tools like CageFS (CloudLinux).
Each domain, whether top-level or top-level, should be treated as a separate entity:
- Files and directories: Each domain should have its own directory structure, with separate permissions that prevent a user in domain A from accessing files in domain B.
- PHP/CGI Processes: Ideally, each domain should run its own PHP or CGI scripts under a specific user, preventing a process from one domain from interfering or intercepting processes from another domain.
- Virtual Environments and Sandboxing: Isolated environments should be integrated to ensure that a vulnerability in one domain cannot compromise the entire server.
What happens in control panels like cPanel, Plesk and DirectAdmin?
Unfortunately, cPanel, Plesk, and DirectAdmin use centralized permission management for domains and subdomains, treating the latter as simple directories nested within the main user's file system. This approach may seem convenient, but it brings serious security problems:
- Sharing UID/GID between domains and subdomains: As noted above, both the main domain and its subdomains run under the same UID and GID as the main user. This means that if a vulnerable PHP process or module is compromised on a subdomain, the attacker potentially has access to all files and directories belonging to the main domain and other subdomains.
- Running PHP processes under the same user: In these control panels, PHP scripts are executed as the domain owner user. This means that there is no differentiation between a PHP process running from the main domain and a PHP process running from a subdomain. If an attacker can exploit a vulnerability in a subdomain, they have the same ability to manipulate files or processes in the main domain as if they were the owner user.
- Obsolete architecture and nesting issues: The approach of creating nested directories for subdomains (e.g.
/home/nome_utente/public_html/sottodominio) further increases the risks, as there is no physical or logical separation between subdomain and main domain data. This makes it easy for an attacker to get from a compromised subdomain to sensitive main domain files or databases.
The real risks of this architecture
Let's consider again the case of the practical example mentioned above: the main domain esempiostore.com with a subdomain old.esempiostore.com, which contains an old version of PrestaShop 1.6. This situation is not uncommon in real environments, where for accounting or transition reasons legacy versions of software are maintained on subdomains. Even if the main domain esempiostore.com is up to date and secure, the presence of the legacy subdomain with outdated software introduces a vulnerable entry point.
An attacker could exploit a vulnerability in a PrestaShop 1.6 module on the subdomain. Once the attacker has compromised the subdomain, they can load a file manager or PHP shell to navigate the server's file system, executing commands with the same UID as the owner user. This allows them to access the configuration files of the updated PrestaShop 8 version on the main domain, compromising not only the subdomain's data, but the entire infrastructure of the main domain.
The direct consequence of this scenario is devastating:
- Data loss: Accessing the database through inadequately protected configuration files can allow an attacker to manipulate or steal sensitive data.
- Escalation of privileges: The attacker can gain full access to the system and create new administrative users in the main site database.
- Financial information compromise: If the main site handles financial transactions, these could be intercepted or manipulated, exposing the company to fraud or privacy breaches.
- Damage to reputation: Any security compromise can cause irreparable damage to the company's reputation, alienating customers and partners.
A professional solution: UID/GID separation and isolated domains
Our philosophy as Managed Server Srl has always been to ensure that each domain, whether second, third or fourth level, runs with a different UID and GID, and that privileges are completely separated. This approach ensures that no file from one domain can be read or written from another domain. A solution that should be standard in every professional hosting environment.
Directory tree structure should also reflect this separation. Instead of nesting subdomains inside the main domain directory, as cPanel, Plesk, and DirectAdmin do, we believe that each domain or subdomain should have its own dedicated and separate directory. For example, in the case of old.esempiostore.com, the directory should be something like:
/home/old.examplestore.com
With this architecture, even if a subdomain is compromised, the attacker would not have access to the main domain's files, since the two environments would be completely separated at the user and group level.
Why We Don't Recommend Commercial Control Panels
We often find ourselves advising our clients against using commercial control panels such as cPanel, Plesk or DirectAdmin for server management. This is not just a marketing approach to differentiate ourselves, but a conscious choice motivated by years of experience in the field.
These panels were created with the aim of simplifying server management for those who did not have the technical skills or financial resources to rely on a professional system administrator. However, over time, the cost of licenses for these panels has increased, while the cost for professional management by expert system administrators has decreased.
Today, with a difference of 20 or 30 euros per month – less than a coffee per day – it is possible to completely avoid the risks and limitations of these panels, relying instead on a team of professionals with decades of experience that not only optimizes performance, but implements advanced security solutions, continuous monitoring, backup and disaster recovery.
Avoid unnecessary risks, trust real experts to protect your site.
If the security of your web infrastructure is a priority, it's time to abandon the old commercial control panels and move to a professional, customized management. At Managed Server Srl, we offer an advanced hosting service, with "by design" security systems that ensure that each domain, subdomain and application are completely isolated and protected.
Don't let a subdomain vulnerability compromise your entire online business. With a small monthly investment, you can ensure that your platform is managed by experts who can prevent security issues like the ones described in this article. Contact us today to find out how we can help you protect and optimize your site with a level of security and professionalism that commercial control panels can never guarantee.
