Broker Walkthrough

Harith Dilshan -

Greetings, fellow hackers! 👻 After a bit of a break, I'm super excited to take you on a ride through the intricacies of the Broker machine. This one's rated as "eeeeeeasy," but let me assure you, the thrill is anything but! So, buckle up, and let's dive into the adventure together! 😊🎮

Disclaimer: No flags (user/root) are explicitly shown here (keeping the mystery alive, as always in writeups). Follow the steps to unveil the hidden treasures! 🕵️‍♂️

00. Setting the Stage 🎭

Begin by firing up the machine - just hit "Spawn Machine". Once you get the machine's IP address (10.10.11.243), ping it to ensure your VPN is connected and the machine is alive. A successful ping means we're on the right track! 🪂

01. The Art of Enumeration 🕷️

Let's start our expedition with a comprehensive nmap scan. My preferred method involves delving into raw network packets, so we execute nmap with superuser (sudo) privileges.

nmap operates at a low level, requiring direct access to network sockets. Without sudo, it may not have the necessary permissions to send and receive raw packets. 🪼
sudo nmap -n -Pn -vv --open -T4 -p- -oN AllPorts.nmap 10.10.11.243

-n      : Never do DNS resolution
-vv	: Extra verbosity
--open	: Output only open ports
-p-	: Full TCP ports range (65535)
-T4	: Aggressive (4) speeds scans; assumes you are on a reasonably fast and reliable network

Now that we've identified the all open TCP ports, it's time to conduct a more in-depth nmap scan using service detection and the scripting engine for these ports. Typically, we avoid running the nmap scripting engine and service detection on all ports due to potential server crashes or the risk of being blocked by firewalls implementing rate limits. Hence, we selectively apply the nmap scan with service detection and scripting engine to ensure a smooth and efficient process. No more chit-chat; let's fire up the command!

nmap -sV -sC -Pn -oA nmap/DetailPorts -p 22,80,1883,5672,8161,39033,61613,61614,61616 10.10.11.243

The subsequent output unveils crucial information about services running on specific ports. Pay close attention to any instances of "Apache ActiveMQ."

we have identified several open ports to explore. Notably, the specific header "Apache ActiveMQ" is present in the output across multiple ports, including port 80. When encountering HTTP servers, it's a common practice to initiate reconnaissance from these ports due to the expansive attack surface associated with HTTP services.

To proceed, let's open a web browser and navigate to the following address: http://10.10.11.243.

After clicking on the URL, a login screen popped up, asking for basic authentication. Now, since we didn't have any specific credentials at the moment, I tried some easy ones like root:root or admin:admin – you know, the usual suspects.

Guess what? We hit the jackpot!

We got through using the simple admin:admin combo, and to top it off, we even found our way to the /admin endpoint. Lucky break, right? 😅 Now that we're in, it's time to explore and see what tricks this website has up its sleeves. Let the games begin!

02. Initiating the Foothold 👣

Got it! So, this webpage is rocking with Apache ActiveMQ vibes. Let's put on our detective hats and see if there are any juicy exploits waiting for us in the shadows.

Would you look at that! 🧐 Up there in the image, we spot a critical vulnerability, the notorious CVE-2023-46604, hanging out in the ActiveMQ server. Now, armed with this info, let's go on a hunt for a Proof of Concept (POC) to exploit this bad boy.

Oh, what's this? 🤔 Loads of POCs are laid out before us, like a treasure trove of possibilities. Let's kick things off with the first one. Time to bring this POC party to our local machine.

Hold on, the repo is asking for an IP address, port, and URL. Quick check of the GitHub readme for a refresher on these parameters.

Ugh, hosting the poc.xml locally is one of those messy tasks, but hey, we gotta do what we gotta do, right? 🤷‍♂️ So, according to the GitHub readme, this poc.xml file needs to be accessed through a URL.

Alright, time to tweak that poc.xml file. I'm thinking a basic ping command as our initial payload. You know, the good ol' ping test to see if our connections are vibing. If that works out, we might just elevate to the grandeur of a reverse shell. Because, hey, the ping command is a legit superhero in the hacking world!

Time to fire up that Python3 demon server to host our precious poc.xml. And oh, don't forget to set up another terminal panel for running tcpdump to catch those ICMP requests. We need to see if our exploit is getting a response from the machine at 10.10.11.243. A successful ping should give us that sweet confirmation that our exploit is doing its thing.

Would you look at that! 😱 Ping ICMP responses are popping up like fireworks, confirming our exploit's success. High-fives all around! Now, let's level up the game and switch the payload to a bash reverse shell.

Time to open up that netcat listener, eagerly awaiting the arrival of our reverse shell.

And there it is! Our grand entrance to the machine. Time to celebrate and explore the possibilities.

03. Claiming the Throne: Privilege Escalation 👑

We've landed on the machine as the activemq user—nice! Now, let's put on our detective hats 🕵️‍♂️ and dive into the realm of privilege escalation. Here's my playbook:

  • List sudo without password sudo -l
  • List all current processes ps -auxw | less -w
  • List all current processes belongs to current user ps -ef | grep $(whoami) | less -w
  • List all SUID/SGID binary files find / -perm -4000 -ls 2>/dev/null
  • and more.. visit my notes using this link

First up, let's see if we can unleash any superuser binaries with the classic sudo -l.

Aha! Luck is on our side. The output tells us we can run the nginx binary without needing a pesky sudo password. Time to capitalize on this golden opportunity to elevate our privileges.

First up, let's run the nginx binary with the help (-h) argument to unveil the array of available functions it's willing to perform for us. Let the exploration begin! 🕵️‍♂️

The output will unravel a list of options and commands at our disposal. It's like a menu of possibilities, and we get to choose what we fancy. Now that we have the liberty to modify the nginx configuration file (nginx.conf), let's craft a bespoke configuration that incorporates the ngx_http_dav_module module. This will give us the maneuverability we need.

Create a new configuration file, let's call it harith.conf, and add the following content:

user root; 
worker_processes auto;
events {}

http {
  server {
    listen 4545;
    location / {
      root /;
      autoindex on;
      dav_methods PUT;
    }
  }
}

This configuration essentially configures an nginx server to listen on port 4545 as root privileges, and the location / block enables the ngx_http_dav_module module with the PUTmethod, allowing us to upload files. let's run the nginx binary with custom configuration file.

Our custom nginx configuration is in play, and now we can surf through the machine's root (/) directory via the web browser by navigating to http://10.10.11.243:4545/

Here, we've landed in the heart of the machine's filesystem, with the ability to traverse any directory thanks to the directory listing feature. Now, let's make the most of the situation. Since we've got the ability to upload anything to the server using the PUT command, let's upload our SSH key to the /root/.ssh path.

Let's spice things up! 🌶️ Attempting to log in to the machine using our freshly uploaded SSH key.

Voila! We've successfully landed as the superuser, aka root, on this machine. It's time to celebrate. 🎉

04. Conclusion: Until Next Time! 👋

Our odyssey through the Broker machine concludes here. Until our paths cross in the next digital adventure, happy hacking! 🌐💻🔓

Ciao.🙋‍♂️🙋‍♂️

Find me on @twitter