hackthebox.eu: Wall Walkthrough

Back to hackthebox with the machine called Wall. This is a Linux box with some useful web application tricks to get started and then a specific exploit to get initial access. After that there is some SUID and exploit usage to move up to a privileged shell. I spent a lot of time troubleshooting my exploits using the web UI to see what was coming out the other end and tweaking from there. It was a fun and of course frustrating box at times. On to the walkthrough!

Starting with the usual nmap scanning and dirb I found that port 22 and 80 are open. Not much to work with at this point. Also I found a few pages that could be useful but not a lot to go on in the source or on the page. I’m pretty sure that this will involve a web exploit just based on experience from past HTB boxes, so I started looking there.

I needed to go to the forums and get a hint at this point but I found references to VERBS and monitoring. This led me back to SANS SEC542 learning where we covered HTTP verb tampering and how to test that. I started off trying to check all of the HTTP methods for http://10.10.10.157 and had no luck, but then I tried the same techniques against http://10.10.10.157/monitoring. My successful nmap command looked like this: nmap -sV -p80 -vvv --script http-method-tamper --script-args 'http-method-tamper.paths=' 10.10.10.157 and resulted in the following.

So this means that the POST method may change things in how this page works. I decided to start with the most simple, using a proxy (burpsuite in this case) to modify my request to the site and see what happens.

Initial request

Modified request

So all we changed was GET to POST after using a browser to navigate to http://10.10.10.157/monitoring

And we get a different response. Looks like the monitoring page moved to /centreon at some point. Now we can navigate directly there.

Let’s dig into this.

I tried both Hydra and BurpSuite Intruder against this with the rockyou.txt password list but didn’t have much success. I saw some mentions of API in the forums and decided to run another dirb against Centreon - this is another important technique in testing, returning to earlier techniques when you discover new things to expand your testing scope.

Now back to Hydra to see if I can get some success against this new area. I tried hydra for a while but eventually found that I was not able to deal with the security features of the site with Hydra and needed to try something else.

https://packetstormsecurity.com/files/153504/Centreon-19.04-Remote-Code-Execution.html
https://shells.systems/centreon-v19-04-remote-code-execution-cve-2019-13024/

It turns out that this is a bit of a guessing game. Several people in the forums indicated as much. Every now and then people say something is very CTF… having credentials of admin:password1 is considered to be this by some. However that’s a different result than I usually got. I see that I retrieve a login token and try to get a poller token, but it fails after that. I need to play with this exploit some more to see if I can get a good result.

After a LOT of experimenting I found that you can use a bash reverse shell (https://highon.coffee/blog/reverse-shell-cheat-sheet/), but you do have to base64 encode the payload so that it gets by the disallowed characters within the application. You could find more information on illegal characters by looking at the Admin tab on the poller configuration as shown below.

Look at the “Illegal ** Characters” fields to get some more information

Base64 encoded doesn’t have illegal characters… nice

I used BurpSuite Encoder to encode a version of my command and ran it via the exploit code, not really expecting anything to be different but then… success!

Finally a shell

This user doesn’t have rights to anything so back we go to enumeration to see what I can find.

Doing some more research I saw that screen-4.5.0 is a SUID binary which seemed a bit out of place so I googled for more information and found this exploit - https://www.exploit-db.com/exploits/41154 .

I created a file on my attack machine for the code and then moved it over to the /tmp directory on the target machine via wget. 

Then I ran this code, which resulted in a LOT of errors.

At first I was bummed figuring that I would need to go back to the drawing board… but then I noticed that my prompt had changed from www-data@Wall to #. Weird. So I ran ID out of habit.

Time to see if I can get some flags!

Thanks to Askar for a fun box and for the neat exploit!

Part of me really wants persistence on this box and one of the best methods I know of that is to have cleartext passwords. So I grabbed both /etc/passwd and /etc/shadow to feed into password cracking programs to see if I could get something using rockyou. We will see if something drops out.

Narrator: it didn't

Oh well, I’m starting to try more things after finishing these machines to attempt to learn more and maybe even explore different methods and tools to perform the exploit. 

• Changing GET requests to POST requests via proxy (BurpSuite)

• Reviewing exploit code to step through the process and using each individual step to troubleshoot issues and get each part of the exploit script working

• SUID binary searching and analysis

• Moving exploits to target machine

• Taking things slow after an assumed failure and noticing that there was a possibility of success even with a less than 100% exploit