TryHackMe – Brainstorm Walkthrough

Introduction

This was an intermediate Linux machine that involved exploiting a stack buffer overflow vulnerability to gain SYSTEM level access to the box.

Deploy Machine and Scan Network

The first thing to do is to run a TCP Nmap scan against the all ports, using the following flags:

• -p- to scan all ports
• -Pn to skip the host discovery phase, as some hosts will not respond to ping requests
• -T4 to increase the number of requests and speed up the scan

The scan has identified three open ports: 21 (FTP), 3389 (RDP) and 9999 (unknown).

Running a more specific Nmap scan on port 9999 to better understand what it might be:

Also using Netcat to interact with the service – it asks for a username and message, the message could be vulnerable to buffer overflow:

Accessing Files

Connecting to FTP through anonymous authentication:

The FTP server contains a chatserver.exe essfunc.dll file:

Access

Transferring the EXE and DLLfiles to a windows machine, and starting the EXE file:

Creating the initial python fuzzer to find out what amount of bytes will cause the application to crash:

Running the fuzzer- It appears when it reaches 2200 bytes it stops working:

Starting Immunity Debugger, attaching it to the application, and running it:

The next step required is to identify which part of the buffer that is being sent is landing in the EIP register, in order to control the execution flow. Using the msf-pattern_create tool to create a string of 2200 bytes.

Adding the pattern to a new script, instead of sending the “A” characters, adding one second of delay between the username and the message as otherwise they were both used as username:

Running the script:

The application crashed with an access violation error:

Using Mona to calculate the EIP offset, which is 2012:

The purpose of this step is to verify whether there is enough space for the shellcode immediately after EIP, which is what will be executed by the system in order to gain remote access. Adding about 400 C characters to the script for this phase:

Restarting the application, re-attaching Immunity, and running the script:

All the “C” characters that were sent by the script were received and they have successfully overwritten the ESP register. This means an ESP JMP address can be used to redirect the execution to ESP, which will contain the malicious shellcode.

Creating a byte array to test for bad characters:

Creating script to generate list of possible hex characters:

Running the script:

Adding the bad characters to the Python script:

Restarting the application, re-attaching Immunity, and running the script:

After following the ESP register to the memory dump, it looks like all the characters made it into ESP, therefore no bad characters are present, apart from x00 which is always considered a bad character. 01 has also been reported as bad as sometimes the subsequent character is mistakenly reported as bad:

The next step is to find a valid JMP ESP instruction address so that we can redirect the execution of the application to our malicious shellcode.

Restarting the application, re-attaching Immunity, and using !mona modules to find a valid DLL/module – looks like the only good one is the executable itself:

Copying the address and searching for it to ensure it is valid:

It looks like it corresponds to a valid JMP ESP instruction address

Changing the script to replace the “B” characters used for the EIP register with the newly found JMP ESP instruction address:

Restarting the application, re-attaching Immunity and adding a breakpoint on the JMP ESP instruction address, then starting the program execution:

Executing the script again:

When the application stops, it lands on the JMP ESP instruction, which is where the breakpoint was added.

The first step of this phase is to generate some shellcode using MSFvenom with the following flags:

• -p to specify the payload type, in this case, the Java reverse shell
• LHOST to specify the localhost IP address to connect to
• LPORT to specify the local port to connect to
• -f to specify the format
• -b to specify the bad characters
• -e to specify the encoder
• -v to specify the name of the variable used for the shellcode

Adding the shellcode to the script, along with 10 NOP slides at the beginning of it to avoid errors during the decoding phase 

The next step is to set up a Netcat listener, which will catch our reverse shell when it is executed by the victim host, using the following flags:

• -l to listen for incoming connections
• -v for verbose output
• -n to skip the DNS lookup
• -p to specify the port to listen on

Restarting the application without the debugger:

Executing script – this returned a shell as SYSTEM:

Conclusion

This is a really great box when practicing stack buffer overflow, especially if preparing for OSCP, since there aren’t many beginner-level buffer overflow boxes on hack the box.