## https://sploitus.com/exploit?id=0FA867AE-4E88-505B-8B9B-F9D89301565D
# Active MQ CVE-2023-46604 exploit
This repository is a guide with examples on how to exploit the [CVE-2023-46604](https://activemq.apache.org/news/cve-2023-46604)
The exploit takes advantage of the usage of reflection for instantiating Exception classes through a malicious command
that instead of being a valid command, it sends as the exception class a Spring class to load beans and as the
string constructor parameter an URL from where to download an XML file with the Spring Bean definitions.
This Spring Bean is in fact a `java.lang.ProcessBuilder` which will run any bash command with the same user permissions as the
one that is running the Java Active MQ client or server.
## Running the exploit
### Client exploit
_I wish I could make the HTTP connection in Python code, but as far as I've seen, the Spring Bean loader for some reason makes two HTTP calls and I'm more familiar with multithreaded programming in Java than in Python_
This exploit is for an ActiveMQ client making a connection to a broker server, which in turn is a malicious server that will make this client vulnerable to remote code execution.
The exploit is split into two processes:
- Python script: this script handles the connection of the ActiveMQ client to return the Spring Bean definition
- Java process: the Java process contains two Threads: the client connection and an HTTP server that returns the Spring XML Bean definition.
This has been tested with Python 3.6 and Java 17
Compile the Java project:
1. `cd activemq-exploit`
2. `mvn clean package`
3. Go back to the root project with `cd ..`, and run `python scripts/client_exploit.py`
On another terminal, run the Java code:
4. `cd activemq-exploit`
5. `java -jar target/activemq-exploit-1.0-SNAPSHOT.jar`
### Server exploit
The server exploit connects to an ActiveMQ server broker and sends the malicious commands.
This was only used with ActiveMQ Artemis 2.18 and unable to exploit the vulnerability
because Artemis is not packaged with Spring, and the only known exploit
_for remote code execution_ is through a Spring class to load Spring Beans.
However, the Python script in `scripts/server_exploit.py` does the same as the client exploit, only connecting to a server.
It lacks authentication, so maybe adaptation of the Open Wire handshake is needed.