Wall was an easy Linux machine from HTB that focused on
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.
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.
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
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
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.
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.
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.