Table of Contents
November 6, 2023
|8m
Fixing the Apache ActiveMQ Remote Code Execution Vulnerability- CVE-2023-46604
Apache ActiveMQ is a popular open-source message broker software that enables asynchronous messaging between distributed systems and applications. It uses the OpenWire protocol to handle the communication and transmission of messages between producers and consumers.
Recently, a critical remote code execution (RCE) vulnerability CVE-2023-46604 was disclosed in certain versions of Apache ActiveMQ. This vulnerability allows an unauthenticated remote attacker to execute arbitrary code on vulnerable ActiveMQ server instances. If exploited, this vulnerability poses a severe risk as it can lead to full system compromise.
In this blog post, we will dive into the technical details of this RCE vulnerability, understand how it can be exploited, and most importantly- learn how to fix and mitigate it effectively.
What is Apache ActiveMQ?
Apache ActiveMQ is an open-source, multi-protocol messaging server written in Java together with a full Java Message Service (JMS) client. It supports advanced messaging features like message queues, publish-subscribe messaging, and temporal control over message delivery.
ActiveMQ provides asynchronous messaging services and acts as a middleware layer in distributed applications. It is commonly used for building event-driven and scalable cloud and enterprise systems by decoupling message producers from message consumers.
Popular programming language frameworks like Spring Boot integrate with ActiveMQ for adding messaging capabilities to applications. The lightweight broker is also often used in containers and microservices architectures.
Overview of CVE-2023-46604
Summary:
CVE ID – CVE-2023-46604
Description – Remote code execution in Apache ActiveMQ via malicious deserialized Java objects
CVSS Score – 10.0 (Critical severity)
CVSS Vector – CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
The RCE vulnerability arises due to improper deserialization of untrusted data in the OpenWire protocol implementation in ActiveMQ. By carefully manipulating serialized Java object data sent via OpenWire, an attacker can cause arbitrary code execution on the target system running the vulnerable ActiveMQ broker.
Specifically, the attacker can send maliciously crafted serialized data that will get deserialized by ActiveMQ and trigger the instantiation of any attacker-chosen class available in the classpath. This results in arbitrary code execution with the permissions of the user running the ActiveMQ server process.
The vulnerability announcement from Apache lists the affected versions of ActiveMQ as follows:
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
This is rated as a critical severity vulnerability with a CVSS base score of 10.0. If you are running an affected version of Apache ActiveMQ, it is recommended to urgently upgrade or apply mitigations to avoid getting compromised.
Several proof-of-concept exploits that leverage this vulnerability to achieve RCE have already been published. There are also reports of active exploitation in the wild.
Verifying Vulnerability Presence
The first step is to verify whether your Apache ActiveMQ installation is actually vulnerable to this RCE issue. Here are a few ways to check for the vulnerability:
Identify Running Version – Check the version of ActiveMQ currently running on your servers. You can log into the host system and check the version subdirectory under the ActiveMQ installation directory. Alternatively, the version is also reported on the ActiveMQ web console login page. Compare it against the list of affected versions above.
Review Broker Logs – Look for any suspicious entries in the ActiveMQ logs that may indicate exploitation attempts. In particular, look for errors or stack traces containing suspicious class names.
Scan with Vulnerability Scanner – Use a vulnerability scanner like Nexpose, Quails, Nessus to scan your ActiveMQ servers for CVE-2023-46604. This will automatically determine if they are vulnerable.
If you have any instances of Apache ActiveMQ in the vulnerable version range, you should proceed to upgrade them or apply mitigations urgently.
Updating Apache ActiveMQ to Fix This Vulnerability
Apache ActiveMQ servers running the following vulnerable versions should be updated as soon as possible to the corresponding fixed releases:
| Vulnerable Versions | Fixed Versions |
|---|---|
| 5.15.16 and lower | 5.15.16 |
| 5.16.x before 5.16.7 | 5.16.7 |
| 5.17.x before 5.17.6 | 5.17.6 |
| 5.18.x before 5.18.3 | 5.18.3 |
General Upgrade Procedure
Step 1 – Back up the Existing Broker Instance
Before upgrading, you should back up your current Apache ActiveMQ installation including:
Configuration files under the
etcfolderBroker data and persistent messages
Any custom scripts used for management
This will allow you to roll back cleanly in case any issues arise during the upgrade.
Step 2 – Install the New Apache ActiveMQ Version
Download the latest Apache ActiveMQ release archive from the official website that is greater than 5.15.16, 5.16.7, 5.17.6 or 5.18.3. Extract this archive to a fresh directory location. This new directory will act as the broker home for the upgraded instance.
Step 3 – Update the Broker Instance to Reference the New Home
The ActiveMQ instance links to the broker home via the ARTEMIS_HOME variable defined in artemis.profile. Update this variable to point to the new home directory extracted in Step 2.
Similarly, update any other scripts like artemis-service.xml on Windows to set ARTEMIS_HOME to the new home path.
Step 4 – Refresh Broker Scripts and Configuration Files
Consider using the upgrade helper tool provided by Apache to automatically refresh key scripts, config files, and properties like artemis.profile and log4j2.properties for the new version.
Review refreshed configs for any customizations that may need to be re-applied from the older backed-up files.
Step 5 – Restart the Broker
Finally, restart the Apache ActiveMQ broker service to load the new version and apply the upgrade changes. The broker home will now point to the new fixed release containing security fixes.
The bundled artemis upgradetool makes the upgrade easier by automatically refreshing instance scripts, configs, and properties to match the new version.
Customizations to older configs may need to be ported to the new refreshed files. The upgrade command itself copies older changed files to a old-config-bkp folder.
Refer to the official ActiveMQ upgrade guide for more detailed instructions on completing the upgrade process.
The developers have also provided an upgrade helper tool that can automate updates to key scripts and config files when transitioning an existing broker instance to a new ActiveMQ version. This tool can simplify the upgrade process.
Applying Additional Mitigations
If you are unable to upgrade immediately, you should apply restrictions on network access to the vulnerable ActiveMQ brokers while you plan an upgrade. Here are some steps to secure access in the interim:
Restrict external access to the ActiveMQ broker port (TCP 61616) using firewall rules. The broker should only be reachable from trusted internal sources.
Disable the broker’s external network access altogether if possible by binding it to localhost interfaces only.
Follow hardening steps outlined by Apache like enabling authentication, authorization and transport layer security.
Closely monitor the ActiveMQ server for signs of compromise and maintain frequent backups.
Verifying the Fix
Once you have upgraded your ActiveMQ instances or applied mitigations, you should retest to verify that the vulnerability is no longer present.
Rescan upgraded servers using a vulnerability scanner to confirm CVE-2023-46604 is no longer detected.
Attempt to exploit using known PoC code to verify it no longer works on upgraded versions.
Check broker logs regularly to ensure no suspicious activity that may indicate compromise.
Consider setting up regular vulnerability scans of ActiveMQ servers for early detection of any new issues.
Detecting Exploitation Attempts
It is also crucial to monitor production systems for any indicators of compromise associated with CVE-2023-46604 exploitation:
Review ActiveMQ logs for signs of access from unknown/suspicious IP addresses. Look for connection attempts to TCP port 61616.
Implement IDS rules to detect packets aimed at the broker port containing Java serialized payloads. This may indicate exploitation attempts.
Monitor processes and command-line arguments for unusual launch of binaries like
cmd.exebyJava.exewhich may indicate successful RCE.Check for connections to domains linked to ActiveMQ RCE PoC exploits and malware payloads.
Detect signs of ransomware activity like file encryption behaviors and abnormal termination of database processes.
Conclusion
This recently disclosed high-severity RCE vulnerability in Apache ActiveMQ definitely warrants urgent attention. All organizations using vulnerable ActiveMQ versions in internet-facing environments should treat this as a critical priority and upgrade or apply mitigations immediately.
While upgrading to a newer fixed release is the best solution, the additional mitigations provide defense-in-depth and reduce risks until upgrades can be completed. Remember to validate remediation steps taken to ensure the vulnerability is fully addressed across all instances.
For any assistance with assessing your exposure or fixing this ActiveMQ vulnerability, do not hesitate to contact your security services provider. Please share any suspicious activity observed with the relevant security teams immediately for rapid detection and response.
We hope this post helps you know how to fix CVE-2023-46604, a remote code execution vulnerability in Apache ActiveMQ . Please share this post and help secure the digital world.Visit our website thesecmaster.com, and our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium, and Instagram and subscribe to receive updates like this.
You may also like these articles:
How to Fix Text4shell- A Critical RCE Vulnerability in Apache Commons Text
How To Fix CVE-2022-24706- A Privilege Escalation Vulnerability In Apache CouchDB
How To Fix CVE-2021-41773 A Path Traversal And File Disclosure Vulnerability In Apache?
How To Fix Apache Cassandra RCE Vulnerability- CVE-2021-44521
Arun KL
Arun KL is a cybersecurity professional with 15+ years of experience in IT infrastructure, cloud security, vulnerability management, Penetration Testing, security operations, and incident response. He is adept at designing and implementing robust security solutions to safeguard systems and data. Arun holds multiple industry certifications including CCNA, CCNA Security, RHCE, CEH, and AWS Security.
