CVE 2022–24082, RCE in the PEGA Platform — Discovery, Remediation & Technical Details (Long Live JMX!!!)
“Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (such as printers) and service-oriented networks. Those resources are represented by objects called MBeans (for Managed Bean). In the API, classes can be dynamically loaded and instantiated.” (https://en.wikipedia.org/wiki/Java_Management_Extensions). Dynamic loading and instantiation of the Java classes opens to the adversaries possible RCE (Remote Code Execution) opportunity when the interface is exposed to the targeted network and not fully protected. This issue is not really new (metasploit exploitation module dates from 2013) but exploitable setups are still identified by researchers in various popular software products. One of the red teaming operations executed by me and the (red) team of my colleagues resulted in identification of this kind of critical vulnerability (with its maximal, critical CVSS score 9.8) in the on-premises Pega platform (https://www.pega.com) deployment. Rating of this vulnerability for other types of deployments (e.g. cloud based) might be lower due to the presence of various compensatory factors (e.g. network filtering). The version of the platform exploited by me was 8.1.2 but the vulnerable ones include versions up to 8.7.3, see Figure 1 and the report https://cve.report/CVE-2022–24082
PEGA Platform (https://www.pega.com/)
PEGA Platform is the company’s core software product, their flagship and part of its PEGA Infinity suite of applications for customer engagement and digital process automation, which are designed to connect customer interfaces with back-end process automation. The product is offered in a number of deployment setups, including on-premises installations but also in all the most popular cloud environments (Azure, AWS and Google) with wide support to various Kubernetes environments and with use of Artificial Intelligence (AI) for marketing campaigns, customer interfaces, and robotic automation.
Addressing the vulnerability in cooperation with PEGA
Despite of having already second half of 2022 and more than 30 years of extensive experience in cybersecurity, it is still hard for many companies to professionally deal with vulnerabilities identified in their software products. Researchers have to deal with many “non-technical” challenges to ensure that their discoveries are properly registered, processed and addressed by the affected vendors. The truth about identified vulnerabilities is still way too inconvenient for so many of them and the fear of the bad publicity simply terrifying and paralyzing. This may seem
unimaginable, but temptation to sweep everything under the rug, to downplay the whole problem or even to “negotiate” (downgrade) the CVSS rating with the researcher is basically hard to resist.
Taking all above into account the way PEGA addressed discovered issue was all the more (positively) surprising. From the first contact attempts, it was crystal clear that security of their customers’ assets is the absolute top priority. Severity of the issue, criticality of the vulnerability as well as the need to act fast were fully recognized from the very beginning. The same pertains necessity to be 100% transparent in communication with the clients, which is crucial in helping them to fully understand associated risk and install the issued patch asap.
Technical details — (Black Box) identification of the vulnerability
As it was mentioned in the Introduction to this article, discovered vulnerability pertained misconfigured JMX interface which was exposed by the JVM running kafka component being part of the whole platform. Its identification using nmap network scanner is shown on the Figure 2.
Important Note:
Although all the technical identification and exploitation details of the vulnerability presented in the subsequent sections were just reproduced using a random Java applet (see Figure 8) in my own private lab, it is the exact copy of the CVE 2022–24082 misconfiguration condition discovered by me in the Kafka component deployment used by the Pega platform.
The next logical step in such case is dumping JVM RMI (Remote Method Invocation) registry. There is a dedicated nmap script for this purpose called rmi-dumpregistry (please refer to https://nmap.org/nsedoc/scripts/rmi-dumpregistry.html). Its usage is shown in Figure 3.
As we can see, the exposed IP endpoint is the local loopback with the TCP port 43379. However, an attempt to scan this port over the network gives a surprising result presented in Figure 4.
So, the port TCP 43379 (Java RMI) is exposed not only on the local loopback (127.0.0.1) but also just over the network!
Exploitation
A quick google search led me to the Mogwai Labs JMX exploitation toolkit available at https://github.com/mogwailabs/mjet. Figure 5 explains how to exploit described above condition using –localhost_bypass option.
This option basically starts a local TCP proxy and forwards all the traffic to the targeted host over the network. Full, successful exploitation is shown in Figure 6.
Invocation of the mjet.py exploit targeting vulnerable server and loading attackers mbean (MbeanRtt) which is further used to execute commands on the exploited server is shown in Figure 7.
Root cause of the vulnerability
JVM on the vulnerable Kafka server being part of the PEGA Platform was setup with the following JMX options:
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote.port=9999
First two options disable password-based authentication and the use of SSL to authenticate connecting endpoints (please refer to https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html). The third option (java.rmi.server.hostname=127.0.0.1) was apparently an attempt to
limit RMI interface exposure to the local loopback only and prevent possible exploitation over the network. This option however only instructs connecting clients to use IP 127.0.0.1 but without preventing JVM from listening also on the actual network interface. This vulnerable condition can be easy reproduced using a random Java applet as presented in Figure 8. In fact, the whole exploitation chain from Figures 1–7 was performed using such applet instead of a real Kafka component belonging to the PEGA platform.
Remediation & Conclusions
As the remediation to the discovered RCE, PEGA Systems implemented ID/Password based authentication for the JVM JMX enabled for Kafka. The aforementioned password is randomly generated upon every application (JVM) (re)start. Additionally, network exposure of this interface has been limited to the local loopback only (this time effectively). Looking back at the whole discovery I would like to share one more remarkable thing. I already mentioned earlier that PEGA Software is very serious about security of their products. They are always subject to a rigorous, multi-level security testing. On top of that PEGA has an astonishing portfolio of customers from various industries (Financial, Healthcare, Government, Telecom, Manufacturing, High-Tech and way more) and those customers perform regularly their own penetration tests on the PEGA platform. I know it from my own experience — a number of them known to me personally, pentest this software on a yearly basis using services of practically all cybersecurity vendors available on the market. And yet … . I’m writing all this just to emphasize how tricky and challenging is implementation of effective security controls for complex software products.
