Last updated at Wed, 27 Dec 2023 15:05:11 GMT

While using the popular self-hosted web administration solution, CloudPanel from MGT-COMMERCE, Rapid7 researcher Tod Beardsley discovered three security concerns. The first, an issue involving the trustworthiness of the installation script provided by the vendor, was an instance of CWE-494: Download of Code Without Integrity Check, and was quickly addressed by the vendor in under a day.

The second issue was with how the installer overwrites local firewall rules to be overly permissive during setup, and appears to be an instance of CWE-183: Permissive List of Allowed Inputs. The third issue is more long-term; CloudPanel installations all share the same SSL certificate private key. This appears to be an instance of CWE-321: Use of Hard-coded Cryptographic Key.

Product Description

MGT-COMMERCE's CloudPanel is a free solution designed to ease the burden of administering self-hosted Linux servers, and is featured prominently at cloud virtual hosting providers such as AWS, Azure, GCP, Digital Ocean, and many others. More about CloudPanel can be found at the vendor's website.

Credit

These issues were discovered and reported by Tod Beardsley, a security researcher at Rapid7, and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Exploitation

While experimenting with some self-hosting solutions for personal use, Beardsley discovered three issues that appear to place new CloudPanel installations at risk of opportunistic attacks across the internet.

Pipe Curl to Bash

The first issue, an instance of CWE-494 involving the trustworthiness of the "curl to bash" installation procedure documented by the vendor was quickly addressed by publishing a cryptographically secure checksum of the installation script. The vendor's website now includes this check for a sha256 hash, as seen in the screenshot below.

This hash changes as new versions of the install script are released, of course, so it may be different by the time you read this advisory. A strategy of publishing a cryptographically secure hash and incorporating a check of that hash should alleviate any concern about the usual "pipe curl to bash" procedure for downloading and installing software over the internet. If you trust the vendor's website, and if the vendor's website is itself protected with an HTTPS certificate, then you should be confident that the installation script they provide is actually the installation script you expect to run. We urge other software providers to incorporate a similar hash check for distributing their installation scripts if they must distribute them via "pipe curl to bash" schemes.

Firewall Rule Rewrite On Installation

The instance of CWE-183 arises due to the fresh installation procedure recommended by the vendor in their documentation. During installation, the installation script preemptively discards local firewall rules for the host operating system, replacing them with much more permissive rules.

In the test case, the local firewall rules (as seen by ufw) are pre-set as:

root@debian11:~# ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] Anywhere                   ALLOW IN    1.2.3.4               
[ 2] 80:8443/tcp                DENY IN     Anywhere  

(Note, the allowed IP address has been replaced with "1.2.3.4")

The above rules state, "Allow any traffic from 1.2.3.4, deny all traffic to ports 80 through 8443 to everyone else." The ufw configuration also concludes with a general default deny rule (not seen here).

During installation, and upon completion of that one-command piping bash to curl installation procedure, these rules are changed to:

root@debian11:~# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
80/tcp                     ALLOW IN    Anywhere                  
443                        ALLOW IN    Anywhere                  
8433:8443/tcp              ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
80/tcp (v6)                ALLOW IN    Anywhere (v6)             
443 (v6)                   ALLOW IN    Anywhere (v6)             
8433:8443/tcp (v6)         ALLOW IN    Anywhere (v6) 

These rules are, of course, far more permissive, specifically because they removed the deny rules as well as the custom IP address allow rule I had set prior to installation.

Furthermore, upon completion of the initial installation, the superuser administrator account for CloudPanel is blank. This is a problem because, typically, a user would navigate to the host server web panel and set the password to their chosen value. However, once installation is complete, and if the machine is on the routable internet (as is intended), an attacker could visit the same web panel and set the administration user account to their chosen password, thus effectively administrating the machine.

Note, the opportunity for attack is limited, since the legitimate CloudPanel administrator has the opportunity to reset firewall rules once installation is complete. However, when installation is complete, there is no notification that firewall rules have been discarded and replaced, so the legitimate user is left to discover this on their own.

If an attacker does manage to seize control during the vulnerable window of opportunity, they could install the malware of their choice, replace certificates, or otherwise alter the underlying operating system as an authenticated administrator, since the whole purpose of CloudPanel is to ease the task of OS management.

The trick for the attacker, then, is to find fresh installations of CloudPanel. This seems unlikely on the open internet assuming users are quick to set their superuser administrator account password, but issue CVE-2023-0391, described next, makes the job of finding these fresh CloudPanel servers much easier, in an automated way.

CVE-2023-0391: Reused Certificates

Upon installation, CloudPanel ships with a static SSL certificate to encrypt communications to the administrative interface. Because the SSL certificate is generated once by MGT-COMMERCE and shipped with every installation of CloudPanel, this state of affairs is exploitable for two outcomes.

First, because the SSL certificate has a unique but reused public key, searching for unmodified CloudPanel instances is trivial with modern network scanning techniques. All an attacker would need to do is target a given IP address space used by a targeted Virtual Private Server (VPS) provider, and continuously look for HTTPS services running on port 8443 (the default for this web administration portal) and certificates that match the public key fingerprint seen below:

The certificate information as seen by Google Chrome. Specifically, the public fingerprints are:

SHA-256 Fingerprint	6D 13 60 EC EF D5 01 F8 F4 91 C3 2D 41 91 48 9C E1 02 3E C8 E9 12 5D 96 AE A7 53 03 FB 62 4F 2B
SHA-1 Fingerprint	3B EC E0 7F F1 4C 84 22 E1 5E 2D 72 5E 47 F7 22 89 00 93 11

Using these search parameters, an attacker can continuously search, in real time, for new instances of CloudPanel, and then exploit the CWE-183 issue described above. Of course, other techniques exist for identifying CloudPanel instances, but the reused certificate leads to a secondary, more serious problem.

Since the private key also ships with every installation of CloudPanel, and CloudPanel is freely available to anyone who cares to download it, the encryption provided by the HTTPS connection is not trustworthy. An attacker with the private key can easily decrypted captured traffic, either in real time through a privileged position on the network between the client and the server, or later with captured network traffic. In either case, sensitive information such as an administrator password and session tokens would be immediately available to the attacker.

According to Shodan, as of January 18, 2023, there are about 5,800 servers providing a certificate issued by 'cloudpanel.clp`, the self-signed authority found on the shipping default certificate. These servers are found mostly in the United States and Germany (which is unsurprising given that the vendor is a German company), and mostly in DigitalOcean VPS environments. This figure is close to our own scanning with Project Sonar, which has spotted 6,785 running instances as of January 27, 2023.

Impact

By chaining together the firewall permissiveness and the reused certificate issues together, an attacker can target and exploit new CloudPanel instances as they are being deployed. It's important to note that CloudPanel is touted to be an easy to use interface for basic Linux administration, is targeted at relatively inexperienced users, and much of the documentation presumes an installation procedure live on the routable internet with a fresh VPS instance.

Furthermore, it would appear that CloudPanel is currently enjoying a burst of uptake among new Fediverse-aware users (this researcher included). While self-hosting is a perfectly innocent and often virtuous goal for distributing personal and professional content, it does come with some additional security responsibilities that are traditionally taken up by dedicated professional services.

Unfortunately, those dedicated professionals are absent in the DIY, roll-your-own kind of environment encouraged by Fediverse fans, and users are left to fend for themselves when it comes to secure software deployment. In light of this advisory, users interested in self-hosting solutions are urged to be aware of the special security considerations that come along with offering services on the general internet. In years past, this would go without saying, but the late 2022 turmoil around untrustworthy centralized services such as Twitter may be generating a new wave of inexperienced sysadmins on the internet, similar the the surge of general internet usage during the Eternal September of 1993.

Remediation

As of this publication, the firewall rewriting issue, the blank superuser password, and CVE-2023-0391 remain unfixed by the vendor. The issues described in the firewall rewrite issue could be fixed by the installation script taking a snapshot of the existing firewall rules, and programmatically creating a ruleset that incorporates the user's original intent with those rules. At the least, the script should identify, and warn the user, that firewall rules are about to be re-written.

The superuser administrator account should be created with a random, per-install password, and display that password on the console upon completion; once the user logs in for the first time, they could then be prompted to change the password.

Absent a patch for these issues, users should take care to install CloudPanel only on isolated networks in a way that is isolated beyond local firewall rules. Practically speaking, as long as the user is installing CloudPanel attentively, and watching for the moment the web service becomes available, attackers will only have a minute or so of exposure to take advantage of. Local, same-machine attackers aside, this should be good enough for most use cases.

For the second issue, the vendor could provide, as part of the installation script, a mechanism to create a unique self-signed SSL certificate during installation, and conclude the installation by printing the fingerprint on the console output.

Absent a patch for CVE-2023-0391, users of CloudPanel are encouraged to generate and install their own certificate for SSL use in order to avoid being so trivially fingerprintable by automated scans, and in order to ensure that the cryptographic security provided by HTTPS is actually secure against passive monitoring.

Disclosure Timeline

  • November, 2022: CWE-183 and CWE-494 issues discovered by Tod Beardsley of Rapid7
  • Wed, Nov 23, 2022: CWE-183 and CWE-494 reported to the vendor
  • Thu, Nov 24, 2022: Report acknowledged by the vendor, CWE-494 addressed
  • December, 2022: CVE-2023-0391 discovered
  • Wed, Jan 18, 2023: CVE-2023-0391 reported to the vendor
  • Tue, March 21, 2022: This public disclosure