Cookie Consent by PrivacyPolicies.com

# Hack the Box - Wall

htb, walkthrough, writeup, python, waf, suid

# Introduction

Wall was an easy Linux machine from HTB that focused on RCE/WAF bypass to establish an initial foothold then a direct pivot to root using a vulnerable suid binary. Let's follow along with my walkthrough.

# Initial Recon

Per usual I start off with enumerating the machine using NMAP.

The web service index page only showed a default Apache page. Ran dirb a few times to see if we could enumerate anything further.

The monitoring was protected by basic auth. This seemed like an interesting avenue, however no amount of brute forcing was successful. After a bit of struggling tried changing the request from a GET to a POST and it worked! Managed to capture a redirect through Burp to a /centreon page.

Alright, so we have a product, and we have a version. A quick lookup at Centreon documentation tells us that the default credentials are admin/centreon. Unfortunately this wasn't the case - looks like someone did their due diligence and changed the default password! A little bit more research and managed to find that this version of Centreon should be vulnerable to CVE-2019-13024. Based on the writeup and code here I used a stripped down version of the code to bruteforce the password by looking for the csrf token being returned by the exploit. The payload portion was commented out for this phase.

Excellent, we now have the proper credentials admin/password1. CVE-2019-13024 indicates the vulnerability is in /main.get.php?p=60901. Setting up a listener and executing the exploit with payload enabled unfortunately did not work. Looking further at the exploit code payload to attempt and understand more what is happening.

I played around with different payloads and I was able to deduce that there was a WAF in place and interfering with the payload. With a little bit of trial and error the main thing I could figure out was that spaces were culprit. This was determined by modifying the exploit code to print out the result code of the POST request to /main.get.php?p=60901 - a 403 return would indicate the payload was being detected by the WAF.

Unfortunately, I was not able to get the exploit working through the script. I decided to tackle the exploit manually through the webpage. Logging in as admin/password1 then navigating to /main.get.php?p=60901 we can that the nagios_bin portion of the exploit translates to the "Monitoring Engine Binary". I tested a few different payloads without success however finally I was able to get a call to my machine to download and execute a payload.

With the following payload I was finally able to get a reverse shell established.

# Root exploitation

Unfortunately I was not able to retrieve the user flag as www-data. Popped over an enumeration script and started looking for pivot avenues. One particularly interesting result was screen-4.5.0 which had suid set.

I poked around a bit to see if there were any low-hanging fruit for this privesc and sure enough managed to find a searchsploit exploit.

Moved the script over to Wall and kicked it off to see if we can successfully privesc to root.

And with that we had access to our root.txt flag and could easily step to the user.txt flag as well.

# Extra fun

Unfortunately as a result of the privesc exploit there were a lot of remnants left on the machine. As a final act made sure to clean up after myself not to ruin anyone else's experience that happened to stumble upon these.