Reading ActiveMQ

Last time (I tried to scan some ports and) I followed the Rabbit. This time we will try to be the last in the line... to get some info from ActiveMQ server. Here we go...
I tried 3 versions of ActiveMQ (5.9.1, 5.14.3 and 5.15.8). You can find them here:

Continuing the story of 'what shoud I do if I'll find that port during my pentest' we will start from the part when I was preparing my VM(s).

First of all I decided to look at Bitnami's resources to find some new machines. I found that there is ActiveMQ prepared to download. I was wondering what can I do with that if I will find it during 'normal pentest project'. Some ideas you will find described below.

Let's start from the point when ActiveMQ is installed (on my Windows7 VM (because again Bitnami's release was useless (because of their FW settings... ;S) anyway...;)))

We should be somewhere here:

According to (few) 'default' configurations/installations-schema we can assume that (if found ActiveMQ-open-port(s)) our attack scenario can look like this:

- find open MQ-service
- grab the password (if needed/other than 'default')
- connect to the queue (to grab or inject messages)

We will try to do it in our 'example environment' (below).

Starting from the scan (remember that this is Windows 7) we can see some (ActiveMQ-related) open ports:

First stage is done. We found open port(s) related to ActiveMQ installation.

(btw, I installed nmap on ActiveMQ VM from Bitnami just to scan it. Results are pretty similar:

Ok.)

Now:  TL;DR: we can get 'guest/default' access to ActiveMQ or 'authenticated' one. Below I'll describe both ways.We'll start from 'guest mode'.

(Depends of the version of ActiveMQ you'll find during your pentest, as 'one of the attack vectors') you can always try to 'ask' ;] your-admin to visit your special link (based on one of the CVEs described here).

But if there is noauth/default_guest, you can just connect to the server and observe (or you can call it sniff) messages available there.

(There are probably more interesting and better 'tools' to do it but I decided to do it by myself, so...)

I found this python module. After reading few more links[1, 2, 3, 4] you should be able to 'reproduce' a 'simple receiver' to check your ActiveMQ installation.

 

 
My example - below:

Still can not 'subscribe' to the queue... Checking again and modifying source-client from the manual:

 

If (ActiveMQ is configured to use 'passwords' and) you're able to connect to the queue you should see (as the output of your 'client' based on the docs) results similar to the one presented on the screen above.

Admin('s console) point-of-view (if password is not valid):

Let's move to the next step.






We can start the attack from simple bruteforce (afaik there is no bf-protection so the only one problem should be the admin who's watching the logs...):

Source of this 313317 t00l you can find here. ;)

So, starting from port 8161/tcp we can grab the password (if the password policy is weak 'enough' to break it fast).

Now when we got the password we can use it to re-write our STOMP-client  (and be able to connect via 61613/tcp port as well as 8161).

Cool. If you know the queue name you should be able now to grab some messages:

As you can see creating bruteforce script for STOMP protocol should not be difficult but I will leave it for you as an exercise. ;)

By the way, sometimes you can also grab some stacktrace messages (could contain some additional info):

During my tests with ActiveMQ, in the end I also decided to send some garbage messages to the server box. My first choice was obviously /dev/urandom ;) Below results from the 'client machine':

Then I saw that Windows machine is unstable; means:

So - I understand it like: 'java consumed memory resources' (because:
* I tried to kill java.exe - it will restart when you'll click on cmd.exe with ActiveMQ server started;
* killing cmd.exe - still no luck.

The only way to stop ActiveMQ server was to restart the whole machine/OS). So - DoS. :)

Let me know in comments/twitter if your server will act like that when receiving /dev/urandom garbage. Version I tried (for this so-called DoS only) was 5.14.3.

Small sender.py for testing purposes below:

If there are no messages when you will 'log in' (for example during the night) - don't worry, your 'python sniffer' can still get some info to use it later during pentest:

I strongly suggest you to read available docs related to this python module if you want to play a little bit with your own MQ servers. ;)

See you next time.

Cheers