Apache ActiveMQ Remote Code Execution
The SonicWall Capture Labs Threat Research team has observed attackers targeting a critical vulnerability affecting Apache ActiveMQ allowing a remote attacker with network access to a broker to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class on the classpath. The vulnerability is categorized as an Unbounded deserialization resulting in ActiveMQ being vulnerable to a remote code execution (RCE) attack. This issue has a CVSS base score of 10.0. CVE-2023-46604 is an unauthenticated deserialization vulnerability in ActiveMQ’s OpenWire transport connector, which is enabled by default and impacts both “Classic” and Artemis clients and brokers. Vulnerable software versions include:
- Apache ActiveMQ 5.18.0 before 5.18.3
- Apache ActiveMQ 5.17.0 before 5.17.6
- Apache ActiveMQ 5.16.0 before 5.16.7
- Apache ActiveMQ before 5.15.16
- Apache ActiveMQ Legacy OpenWire Module 5.18.0 before 5.18.3
- Apache ActiveMQ Legacy OpenWire Module 5.17.0 before 5.17.6
- Apache ActiveMQ Legacy OpenWire Module 5.16.0 before 5.16.7
- Apache ActiveMQ Legacy OpenWire Module 5.8.0 before 5.15.16
Organizations still running one of the vulnerable software versions should upgrade to version 5.15.16, 5.16.7, 5.17.6 or 5.18.3, which fixes this issue.
This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2023-46604.
The overall CVSS 3.1 score is 10 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H).
Base score is 10 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H), based on the following metrics:
- Attack vector is network.
- Attack complexity is low.
- Privileges required is none.
- User interaction is none.
- Scope is changed.
- Impact of this vulnerability on data confidentiality is low.
- Impact of this vulnerability on data integrity is high.
- Impact of this vulnerability on data availability is high.
Temporal score is 9.4 (E:P/RL:O/RC:C), based on the following metrics:
- The exploit code maturity level of this vulnerability is proof of concept code.
- The remediation level of this vulnerability is official fix.
- The report confidence level of this vulnerability is confirmed.
An attacker connected to OpenWire TCP port 61616 can send an OpenWire packet to unmarshall an ExceptionResponse object instance. By supplying an arbitrary class name as well as an arbitrary string parameter to the BaseDataStreamMarshaller.createThrowable, the attacker will, have access to an arbitrary class to be instantiated with a single command string parameter.
At SonicWall Capture Labs Threat Research, we have recreated the PoC using Metasploit framework as demonstrated in Figure 1.
Before exploitation can occur, the following conditions must be true:
- The attacker must have network access.
- The attacker must send a manipulated OpenWire “command” (used to instantiate an arbitrary class on the classpath with a String parameter).
- A class must be present on the installation in the classpath which can execute arbitrary code simply by instantiating it with a String parameter.
Figure 1 below demonstrates the following steps to exploit this vulnerability:
- Create and start a vulnerable victim server.
- Uses a Metasploit module to host the poc.xml file on the attacker’s server.
- Finally, run the exploit by running Exploit.java.
- Additionally using Shodan dork we can observe over 6000 vulnerable servers exposed on the internet.
Figure 1: SonicWall Capture Labs Threat Research Exploitation
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature has been released:
- IPS:15940 - Apache ActiveMQ OpenWire Protocol Insecure Deserialization
SonicWall sensors have confirmed active exploitation of these vulnerabilities. The graphs below indicate an increasing number of exploitation attempts and we expect exploitations to continue to increase.
Figure 2: Threat Graph
Admins still running one of the vulnerable software versions should upgrade to version 5.15.16, 5.16.7, 5.17.6 or 5.18.3, which fixes this issue.
If that’s not possible, users can mitigate the issue by validating the provided throwable class type via OpenWire marshallers that takes care of OpenWire commands. Further steps to mitigate are dictated on the official link.