HTB is an excellent platform that hosts machines belonging to multiple OSes. It also has some other challenges as well. Individuals have to solve the puzzle (simple enumeration plus pentest) in order to log into the platform and download the VPN pack to connect to the machines hosted on the HTB platform.
The walkthrough
Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named Wall, is retired. Let’s start with this machine.
Download the VPN pack for the individual user and use the guidelines to log into the HTB VPN.
The “Wall” machine IP is 10.10.10.157.
We will adopt the usual methodology of performing penetration testing as we’ve used before. Let’s start with enumeration in order to learn as much about the machine as possible.
As usual, we’ll start with the nmap scan to gather more information about the services running on this machine. [CLICK IMAGES TO ENLARGE] «nmap -sC -sV -oA Wall 10.10.10.157»
As we can see, ports 22 and 80 are open. Let’s start enumeration on port 80.
Below is an Ubuntu landing page.
Let’s start to enumerate the directories on this box. We’ll use dirb. «dirb http://10.10.10.157»
One interesting directory is called “monitoring.” Let’s start enumerating the /monitoring endpoint. Below is the authentication dialog that we get for this page.
Let’s view the request on Burp and start playing with the request verbs. Changing the request from GET to POST gives us a different page.
Rendering the content gives us another URL: /centreon.
When we next visit the page, we got another login page for Centreon, as shown below. The good part is that it does show the version of the platform.
Browsing the version number for exploits reveals an RCE bug, but this is an authenticated bug.
Searching for other bugs and functionality related to Centreon reveals that the product API can be brute-forced to reveal the password, as shown below: «wfuzz -z file,/usr/share/wordlists/rockyou.txt -d “username=admin&password=FUZZ” –sc 200 http://10.10.10.157/centreon/api/index.php?action=authenticate»
From the above, we can see the password revealed to be password1.
We use that to access the GUI of Centreon.
Once we are inside, we can fall back on RCE and use the poller to get an RCE.
We will now use the existing poller and edit it. Per the bug, the field that is vulnerable is Monitoring Engine Binary and we just add ‘ls;’ to it.
We saved it and now click on “Export configuration.”
When we export it, we can see that the command executed well and we got the results.
Let’s extend our use case and see ls -l; to acquire more information about it.
Saving it results in a 403 forbidden message.
After much testing, it was found that it was the whitespace that was terminating the command, so we could use $IFS to let bash fill that for us, as shown below. We used a reverse shell and used $IFS for it.
Saving -> Exporting results in aborted stage.
We then changed the payload to base64 and filled the spaces with $IFS, as shown below.
This time it was successful, and we got a reverse shell back!
The reverse shell is then spawned back to the attacking machine.
We try to grab the user flag, but it looks like permission is denied for that.
Checking the SUID bit reveals that the screen utility has that set the version is vulnerable to local privilege escalation.
Compiling the exploit as illustrated in the bug, transferring the exploit to the machine and executing it results in successful escalation, as shown below. «bash exploit.sh»
We enumerate to grab the root.txt and user.txt flags.
This is a very interesting machine with lots of insights right from the first foothold — changing verbs followed by fuzzing, $IFS and then local enumeration to see SUID settings. Hopefully this gave you some interesting new approaches to consider for future tasks! We will continue this series with more similarly interesting HTB machines.
