CVE-2022-41678 in ActiveMQ
Summary
by MITRE • 11/28/2023
Once an user is authenticated on Jolokia, he can potentially trigger arbitrary code execution.
In details, in ActiveMQ configurations, jetty allows org.jolokia.http.AgentServlet to handler request to /api/jolokia
org.jolokia.http.HttpRequestHandler#handlePostRequest is able to create JmxRequest through JSONObject. And calls to org.jolokia.http.HttpRequestHandler#executeRequest.
Into deeper calling stacks, org.jolokia.handler.ExecHandler#doHandleRequest is able to invoke through refection.
And then, RCE is able to be achieved via jdk.management.jfr.FlightRecorderMXBeanImpl which exists on Java version above 11.
1 Call newRecording.
2 Call setConfiguration. And a webshell data hides in it.
3 Call startRecording.
4 Call copyTo method. The webshell will be written to a .jsp file.
The mitigation is to restrict (by default) the actions authorized on Jolokia, or disable Jolokia. A more restrictive Jolokia configuration has been defined in default ActiveMQ distribution. We encourage users to upgrade to ActiveMQ distributions version including updated Jolokia configuration: 5.16.6, 5.17.4, 5.18.0, 6.0.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2024
The vulnerability identified as CVE-2022-41678 represents a critical remote code execution flaw within Apache ActiveMQ systems that leverage Jolokia for JMX access. This vulnerability specifically affects configurations where Jetty serves the Jolokia agent servlet at the /api/jolokia endpoint, creating a pathway for authenticated attackers to execute arbitrary code on the target system. The flaw stems from insufficient input validation and overly permissive access controls within the Jolokia HTTP request handling mechanism, allowing maliciously crafted JSON payloads to traverse the system's security boundaries.
The technical exploitation chain begins with the Jolokia HTTP request handler's ability to parse incoming JSON objects through the JSONObject class, which then gets processed by the HttpRequestHandler.executeRequest method. This processing flow ultimately leads to the ExecHandler.doHandleRequest method, which employs Java reflection capabilities to execute arbitrary methods on the target system. The vulnerability leverages the jdk.management.jfr.FlightRecorderMXBeanImpl class available in Java versions 11 and above, utilizing a four-step execution pattern that includes creating a new recording, setting configuration parameters containing malicious webshell data, starting the recording, and finally copying the data to a file system location. This method of exploitation demonstrates a sophisticated approach that bypasses traditional security controls by utilizing legitimate Java management interfaces.
The operational impact of this vulnerability extends beyond simple code execution, as it provides attackers with complete control over the affected ActiveMQ system, potentially leading to data breaches, service disruption, and lateral movement within network environments. The vulnerability affects multiple ActiveMQ versions and has been classified under CWE-77: "Improper Neutralization of Special Elements used in a Command" and CWE-94: "Improper Control of Generation of Code ('Code Injection')", highlighting the fundamental flaws in command and code injection handling within the application's JMX interface. Security practitioners should note that this vulnerability aligns with ATT&CK technique T1059.007 for Command and Scripting Interpreter: Python, and T1566.001 for Initial Access: Phishing, as attackers could potentially use this vulnerability to establish persistent access through webshell deployment.
Organizations should implement immediate mitigations including restricting Jolokia actions through configuration changes that limit the operations authorized through the Jolokia interface, or completely disabling Jolokia in environments where it is not essential for operations. The recommended approach involves upgrading to ActiveMQ versions 5.16.6, 5.17.4, 5.18.0, or 6.0.0, which include updated Jolokia configurations that significantly reduce the attack surface. Additional protective measures include network segmentation to limit access to the Jolokia endpoint, implementing strict authentication controls, and monitoring for unusual JMX activity patterns that might indicate exploitation attempts. Security teams should also consider implementing runtime application self-protection mechanisms and regular vulnerability assessments to identify similar flaws in other JMX-enabled applications within their infrastructure.