hackthebox.eu: Blunder Walkthrough

I’ve been taking a bit of a break from HTB machines for a while while the world is crazy. But it seems like I need to get some hacking for fun back in my routine. Let’s jump back in with an easy machine in Blunder. This is a Linux box so we’ll see how my processes hold up.

My initial nmap scan showed only port 80 open. Not much to work with. Time to take a look at the website and see how much information I can gather. We’ll start off with a directory discovery scan.

It seems like this machine has some timeouts or disconnects if you are being naughty, so that makes things take longer. That makes everyone’s path through the machine a bit different but generally the process is the same. This would be a pain onsite with a limited timeframe for sure. I would consider the ROI of the machine in my test and determine if exploiting it would get me closer to a goal or to showing impact before I decide to spend too much time.

I tried various directory brute forcing tools and found some directories like admin and such, but nothing seemed to be useful at this point. Doing some more research I was reminded of wfuzz and then SecLists to use for common web files. With a lot of this stuff it’s really about finding the right list.

It took quite a few tries with the “Operation timed out” error before I found this todo page. Now we need to review these results and look for useful information.

It doesn’t seem like we have a lot here, but possibly fergus is a username. And doing initial research on what is running I found a possible auth bypass exploit for Bludit which is what the webserver is running (https://rastating.github.io/bludit-brute-force-mitigation-bypass/ ). But we need some passwords to try. A lot of times for CTFs they like to push you toward Cewl which is a really neat tool by Robin Wood (@digininja).

My thought process here was that from looking around the site initially there were not a lot of layers, so I could set a depth of 5 (-d 5) and be pretty sure that I will get good coverage. Also, I set the minimum password length at 6 (-m 6), I guess I could go a bit shorter at 4 to get things like ‘admin’ as a password, but the more words the more requests and as we’ve seen this server does not like a lot of requests.

This process gave me a list of 188 words to try. Now to grab the exploit from earlier and use fergus and see what we get.

Well allrighty then. I did a quick manual login to the site to verify that we have access. Now that I have some working credentials I remembered that there are other Bludit exploits that required a valid login.

I am a big fan of doing things the easiest way possible. I heard someone once say “there are no style points in pentesting” and I’m inclined to agree MOST of the time… there are exceptions of course.

With that in mind, here is an exploit in MSF… let’s give it a shot.

It took me a bit of messing around with this to get it to work. It seems that running check made it angry in some way, so I unset everything and started over and got it to work. Not sure entirely why, but this is a good reminder that it’s worth at least two shots at using an exploit just in case you’ve misconfigured MSF.

After looking around the system and exploring I found my initial flag. I also found another username ‘hugo’ that may be useful going forward.

Eventually I found my way to user.php files under the Bludit/bl-content/databases/ directories. It looked like there were two versions of Bludit on the server and after looking through the files in each I recovered 3 password hashes. Running hashid against my recovered hashes showed they are SHA1 format. I tried some password cracking against my hashes but it didn’t work so I decided to try just searching for the hash. Lots of times with older hashing algorithms this works and is much faster than using a cracking program. One caveat here is that while I do this for a CTF, I would probably continue to work on cracking if this was a customer’s password hash and I was on a live test. The main reason I would make this decision on a live test is to err on the side of maintaining control of customer data and not submitting it to a website that I do not control.

My hunch of being able to search for the reversed SHA1 hash was correct. Let’s go back to msfconsole with hugo and this password to see if I get access.

Nope that didn’t work. But there are other ways to get to hugo. Time to log back in as fergus.

Once I logged in as fergus I just ran su to switch to hugo and then started with my basic command to see if I have any privileged access - sudo -l.

That’s an odd one on the bottom and when I tried sudo /bin/bash I got an error.

I know there is a way to run this with root privileges so to find out more I searched for the string (ALL, !root) /bin/bash to see what comes up. I found a bunch of articles, but one of the first was this one. https://www.exploit-db.com/exploits/47502 

There is a walkthrough there, so I followed it to see what results I would get.

It seems to have worked, so let’s see if we can get the root.txt

Done! This was an interesting machine that used some common techniques in an interesting way. It also took me back to some old tricks. This may seem like a kind of antiquated machine, however in my experience it is possible to encounter older software on Linux machines in large environments. Sometimes people will install an older piece of software, stop using it, and then forget that it was deployed. It’s also possible if the environment is fairly stale that this machine could be an initial foothold that could result in lateral movement into newer and higher impact devices on a live test.

Items learned or remembered:

• Practice on WFuzz. I need more of that

• More reasons to run Cewl and generating password lists

• Run MSF module, verify and run again

• Sometimes running check in MSF breaks things

• A new method of running /bin/bash as root