Walkthrough of exploiting a buffer overflow vulnerability on a Windows machine, privilege escalation via Firefox.

Initial scanning

Let us start with our usual Nmap scan which shows a couple of interesting ports which we could start with.

Altough 31337 is the most enthralling one, let’s have a quick look at an SMB-specific scan. It shows that not only signing is not required, but also brings up our target file in the shares.

Let’s get the file real quick.

Buffer Overflow

After downloading the file as we did earlier in similar rooms a proper investigation should be carried out on a Windows machine. We can use another THM box for this purpose. Due to the fact that this room is about buffer overflow exploitation, the best to transfer it to a BOF-related Windows machine like the BufferOverFlowPrep one on which we already have the necessary tools to play with them. Let’s start our usual HTTP server and download the files from Windows Explorer.

Let us attach the gatekeeper.exe to Immunity and then running it in order to do some fuzzing with it.

First of all we need to figure out at what location the memory stack is overflown causing the program to crash. Let’s generate a random string of 500 characters with the pattern_create module of Metasploit to single out the part which goes to the EIP (Extended Instruction Pointer) address.

Let us add the string as a payload to a general fuzzer script of our choice and run it against the executable running on our test machine.

Before running the script against the gatekeeper executable attached to Immunity, we must make sure that the working directory of the Mona plugin in the debugger is configured.

After running the scripts from our attacker machine it crashes the immunity-attached process with an access violation error.

After this we have to calculate the EIP entry point using a Mona script using the length of the payload embedded in the fuzzer script. This comes back with the offset value of 146.

As consequence let us change the offset from 0 to 146 in our fuzzer script. Also let’s delete the payload for now and change the padding variable to BBBB to check the available space needed by the shellcode later on.

We can see our B’s as 42424242 as the value of the EIP register which shows the border of our offset and such having fully identified the memory space required.

Now we need to tailor a bit further our script and filter out the potential bad characters which would ruin the execution. This is to be achieved by using a Mona script generating a byte array of bad characters and a list of ours using a script. Subsequently placing the result into our fuzzing script and running it against the gatekeeper process on our test machine. So let’s generate a bad character string with the script below.

And our bad characters as a result..

Placing them into our fuzzer script as payload.

Also creating a collection of bad characters in the debugger with the exemption of null-byte as it is always bad anyways.

Ok, now let’s run our fuzzer loaded with a collection of bad characters after re-attaching the gatekeeper exe to Immunity. It crashes as usual and due to the fact that we need to make sure that all bad characters strained out which would render our final exploit later on comparison is needed between the list of bad characters and the state of memory at the present of crash. This is to be achieved with another Mona script. We can see that only the null-byte and it’s neighbor is present running the bytearray at our ESP register which is normal.

Now we need to find a legit JMP ESP instruction address to redirect the execution flow to the reverse shell code of ours. This is to be done using another Mona script. In this command all the bad characters which were listed during the comparison should be present. Two pointers discovered as per the logs.

Ok, so we are going to use the second address for now which is 0x080416bf. This address is to be placed into our fuzzer python code as a return address but in Little-Endian format as described in another post. Also, we now have to generate our reverse-shell code using msfvenom to actually get the Buffer OverFlow vulnerability exploited. In the command the identified bad characters should be specified amongst the payload type, format, encoder type and the name of the shellcode.

Let’s upgrade our fuzzer script with all our final modifications to a proper exploit code.

After running our exploit against the test machine the gatekeeper.exe should NOT crash but we should get back a reverse-shell.

Remember, this is just testing, let us run it against our actual victim machine changing the IP-address in our expoit code.

Locate and find the User Flag.

Privilege Escalation

There is an interesting shortcut on the desktop which cannot be there by accident, let’s have a closer look and try to get some credentials using Metasploit. First we need to generate a Meterpreter payload which is exactly the same than the previous one but instead of catching the backconnect with Netcat we would use a Metasploit multihandler.

After running our exploit code with the modified msfvenom payload we receive our reverse-shell on our Metasploit listener.

Now let us gather the Firefox credentials with a specialized module of Meterpreter.

After this we shall download a Firefox credential decrypter script from GitHub in order to get the data in cleartext.

Now, let’s rename all the downloaded credentials as per the instructions of the decrypter to cert9.db, cookies.sqlite, key4.db and logins.json respectively.

Dumping the credentials..

So, now, with the credentials, we are free to login to the victim computer and lookup the root flag.

Locate and find the Root Flag.

Thanks for reading and as always, any feedback is most welcome.