DOC PREVIEW
GT ECE 4112 - Lab 12: Exploit Creatio

This preview shows page 1-2-23-24 out of 24 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Section 1# mount /mnt/nas4112/Password:#cd /mnt/nas4112/#/mnt/nas4112> cd Lab12#/mnt/nas4112/Lab12> cp framework-2.5.tar.gz /root/#/mnt/nas4112/Lab12> cdTo create the perl script, type#vi string.plIn the editor type the lines above without the numbers, save the file and quit.On the prompt type#touch pattern.txtThis will create a new empty text file called pattern.txt. Now type# perl string.plThis would copy the attack string to pattern.txtIn line 2 we append a string of 200 A characters. Line 3 opens a file pattern.txt. Line 4 writes the generated string to the file. Line 5 is to close the file opened in line 3.Copy the program called vuln_name.c from Lab12 folder. Lab 12 folder has to be mounted from NAS using the instructions given in the previous sections.Type the following,# mount /mnt/nas4112/Password:#cd /mnt/nas4112/#/mnt/nas4112> cd Lab12#/mnt/nas4112/Lab12> cp vuln_name.c root/#/mnt/nas4112/Lab12> cd# gcc –ggdb –o vuln_name vuln_name.cThese instructions would copy the program vuln_name.c from Lab12 on NAS to root directory. The last command compiles vuln_name.c. –ggdb is used for debugging.In order to examine the buffer overflow, we should use a debugger. A debugger can be used as follows:1. Start gdb, by typing# gdb vuln_name2. To supply the attack string to the application type,<gdb> set args `cat pattern.txt`(This enables us to supply the file contents in pattern.txt to arguments in vuln_name.c. Those are not single quotes, but backticks)3. Run the executable in gdb by typing,<gdb> run4. The attack string will overwrite the return address, which would be popped into EIP.5. When the processor will attempts to access the invalid address stored in EIP, it would throw an access violation. This violation is caught by the debugger and itstops.6. To view the contents of EIP, type<gdb> x $eipIt would display the following on the debugger window,EIP 41414141which means whenever the processor attempts to access the invalid memoryaddress, 0x41414141, it halts.In order for us to overwrite the saved return address, we have to calculate the location of the four A’s that overwrote the EIP. Unfortunately it is difficult to determine that information in a string made up of A’s. For determining this kind of information, a string needs to be created such that any four consecutive bytes are unique from any other four consecutive bytes. In that manner, whenever those unique four bytes are popped into EIP, it is possible to locate these bytes and determine how many bytes(by counting the number of bytes in the string before the four bytes) should be sent before the return address would be overwritten.This unique pattern can be created using the method PatternCreate() which is available in Pex.pm library located in ~/framework/lib.The function can be used on command line by typing,# cd framework-2.5/lib/# -e ‘use Pex::Text; print Pex::Text::PatternCreate(200)’.This function takes as argument the length in bytes of the pattern, in our case 200. Once the pattern is generated it can be copied to the string in the script.Copy the pattern and paste it in the string as shown after the ‘=’ sign in line 2 below.The script looks like,Line 2 defines a variable called pattern that contains the generated pattern. Line 3 appends the pattern to the string. Rest is the same.When we re-run the program with a debugger using this string, and look at the contents of register eip, value at eip = 0x35624134It is the ascii value for “4Ab5” .To determine this offset we can count the number of bytes before the bytes 4Ab5, which is very cumbersome.There is a script called patternOffset.pl in ~/framework-2.5/sdk.To determine the offset type the following commands,# cd framework-2.5/sdk#/framework-2.5/sdk > ./patternOffset.pl <the value in EIP> <number of bytes in the pattern>In our case,#/framework-2.5/sdk> ./patternOffset.pl 0x3562413444This gives the number of bytes (44) that should be included in the attack string before the four bytes to overwrite the return address. In this manner we can control the value of the EIP register, which would enable us to lead the process to a payload that executes arbitrary code on the target machine.Now that we have determined the offset, we have to generate a payload, append it to the string, and make the process jump to the location of the payload in memory (i.e. the return address should be the address in memory where thepayload resides).1.2.3 Determining a valid return address.There are various ways to determine a return address to supply to EIP. We do it as follows:Type the following,#gdb vuln_name(gdb)set args `cat pattern.txt`Set a breakpoint at the instruction leave and ret as(gdb) break *0x8048478(gdb) break *0x8048479Now run the program once(gdb) runTo see value of register ebp at this time, type(gdb)x $ebp0xbffff8b8: 0x62413362Now we will analyze the memory around this location, by typing(gdb) x/20x 0xbffff8b0We see our pattern 0x35624134 at location 0xbffff8bc-0xbffff8bf. We have to replace the value of memory locations 0xbffff8c0-0xbffff8c3 after these bytes with the address in memory we want to jump to.Lets say we want to jump to memory location at 0xbffff8c8. The script would now look like,The script to generate the input string looks like.3 $string .= $pattern;4 $string .= “xc8xf8xffxbf”;Line 2 appends to $pattern a pattern of first 44 bytes from the previously generated pattern. Line 3 appends this pattern to a variable $string, the four byte return address is then copied to the string. The address is written in reverse order to account for the machine being little endian. Rest of the script is the same.1.2.4.Next step is to create and append a payload which is the actual shell code containing arbitrary commands we want to execute on the system. To execute the payload correctly, the EIP should land at the first instruction of the payload. It is very difficult to predict the exact stack address of the payload. A solution to the problem is to prefix the payload with NOP or no operation sleds. This enables the EIP to slide down to where the actual payload is, wherever it falls in the NOP sled. This increases the probability of successfully exploiting the payload.The script when nops are appended looks like3 $string .= $pattern;4 $string .= “xc8xf8xffxbf”;The rest of the script is same, except line 5. This appends to the string a sled of 20 NOPs. The hex representation of NOP is the character sequence ‘0x90’.We now append the actual


View Full Document

GT ECE 4112 - Lab 12: Exploit Creatio

Documents in this Course
Firewalls

Firewalls

40 pages

Firewalls

Firewalls

126 pages

Load more
Download Lab 12: Exploit Creatio
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lab 12: Exploit Creatio and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lab 12: Exploit Creatio 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?