Guide to Basic Exploit Writing
Part 2 - Controlling the EIP
==================================================
5. Finding the Offset
In Part 1 of the guide, we fuzzed the FreeFloat FTP Server and found that if we send a string of 1000 'A's as the USER, we can overwrite the EIP with 41414141. Now the question is - how do we find out which particular 4 bytes out of the 1000 bytes had overwritten the EIP?
In this case, one convenient way of working this out is to make use of two scripts that come together with the Metasploit Framework: pattern_create.rb and pattern_offset.rb. First, create a string of alphanumeric characters using pattern_create.rb. Note that the location of the script in your system may differ.
Now create the following exploit.py file and use the 1000-byte string generated above instead of the 1000 'A's.
Now, make the file executable and run it i.e. # ./exploit.py
This should 'hang' the FTP server running in ollydbg. Take a look at the EIP register. On my system, instead of 41414141, it now shows 37684136. Plug this string into pattern_offset.rb, as shown below. Remember to replace the 37684136 with the string you see in the EIP register on your own system.
Now replace the "evil" line in exploit.py with the following:
Now, make the file executable and run it i.e. # ./exploit.py
This should 'hang' the FTP server running in ollydbg. Take a look at the EIP register. On my system, instead of 41414141, it now shows 37684136. Plug this string into pattern_offset.rb, as shown below. Remember to replace the 37684136 with the string you see in the EIP register on your own system.
Now replace the "evil" line in exploit.py with the following:
Run exploit.py again. You should see that EIP has now been overwritten with 42424242,
or 'BBBB'.
==================================================
6. Finding a Home for our Shellcode
Before we work further on the EIP, let's take a look at the bottom right window in ollydbg - the stack. If you scroll up the window slightly, you will see a long string of 41414141s. That's our 230 'A's. Immediately after that, you will see 42424242, followed by a long string of 43434343s.
Looking back at the register window in ollydbg, observe that the ESP register seems to be pointing to a long string of 'C's, or 43434343.... Choose the ESP register value and right-click on it, then choose the "Follow in Stack" option. In the stack window of ollydbg, you will be directed to the 3rd row of 43434343. On my system, the address of this row is 0x013CFC18. Now scroll down the stack window to the last row of 43434343. On my system, the address of this last row is 0x013CFF08. This means we have about 0x2F0, or 752 bytes to work with.
For a straightforward exploit (as is the case here), this is more than sufficient space for a tcp bind shell or reverse shell. Seems like a good place to house our shellcode in!
==================================================
7. The Plan of Attack
Let's summarise the key things we found out thus far:
1. We can insert any value, or memory address, we want into EIP. The program will then execute any valid instruction found at the memory address.
2. The ESP points to the 3rd row of 43434343. We can control the values in this row, as well as the 752 bytes there after. Instead of 'C's, we can place our shellcode here.
Based on the above, we can work out the following plan of attack:
1. We need to first find a "JMP ESP" instruction and get its address.
2. We will place this address into EIP, so that the JMP ESP instruction will be executed.
3. We will place our shellcode just after the 3rd row of 43434343, for e.g. in the 4th row.
4. After filling in our shellcode, we will replace all the remaining 'A's and 'C's with x90 (NOPs).
5. When the JMP ESP is executed in point #2 above, the program will first execute the 3rd row, now filled with NOPs, followed by the 4th row and so on, which is now filled with our shellcode. (Sometimes, you may need to adjust the number of NOPs you put in.)
==================================================
8. The JMP ESP Instruction
In ollydbg, press Alt-E to bring up a window showing the list of executable modules of the FTP program. We can try to find a JMP ESP instruction from one of these modules, while bearing the following in mind:
1. We need to avoid using a JMP ESP instruction with an address which contains a x00, x0a or x0d. These are the null byte, line feed and carriage return respectively. They tend to break exploits.
2. We should try to use modules that come together with the program, instead of the modules supplied by the operating system. The addresses within the former are less likely to change with different Service Packs, languages, etc and should be more portable.
3. Windows Vista uses ASLR to randomise the memory addresses of most modules, especially the ones supplied by the operating system. I think Win7 uses ASLR for all modules. The use of ASLR reduces the portability of the exploit, and in most cases, prevents the exploit from working again after the Victim computer reboots.
Now take a look at the list of executable modules. Unfortunately, all of them are modules supplied by the OS. Looks like we have to pick an OS supplied module. If you are following this tutorial using Vista or a newer Windows OS, this means that it will be difficult for you to pwn Vista machines you don't own... well I meant it when I said this was for educational purposes only ;) There are ways to bypass ASLR under certain circumstances, but that's another story.
Anyway double-click on USER32.dll. Then, in the main window (top-left) of ollydbg, right-click and select the option 'Search for -> Command'. Do a search for 'JMP ESP'. You can try using other modules if you like. On my system, I found a JMP ESP instruction at 0x76b8fae1. Don't reboot your machine if you are using >= Vista, or you will have to repeat this step. Remember not to use addresses with x00, x0a and x0d in them.
Next, replace the "evil" lines in exploit.py, with the following:
Now run exploit.py again. The FTP program running under ollydbg should now pause at the 3rd row of 'xcc'. You can verify this by looking at the stack window and the main window of ollydbg.
All that is left now is to replace the 'xcc' with our shellcode. Stay tuned for the 3rd and last part!
Part 2 - Controlling the EIP
==================================================
5. Finding the Offset
In Part 1 of the guide, we fuzzed the FreeFloat FTP Server and found that if we send a string of 1000 'A's as the USER, we can overwrite the EIP with 41414141. Now the question is - how do we find out which particular 4 bytes out of the 1000 bytes had overwritten the EIP?
In this case, one convenient way of working this out is to make use of two scripts that come together with the Metasploit Framework: pattern_create.rb and pattern_offset.rb. First, create a string of alphanumeric characters using pattern_create.rb. Note that the location of the script in your system may differ.
Code
Now create the following exploit.py file and use the 1000-byte string generated above instead of the 1000 'A's.
Code
Now, make the file executable and run it i.e. # ./exploit.py
This should 'hang' the FTP server running in ollydbg. Take a look at the EIP register. On my system, instead of 41414141, it now shows 37684136. Plug this string into pattern_offset.rb, as shown below. Remember to replace the 37684136 with the string you see in the EIP register on your own system.
Code
Now replace the "evil" line in exploit.py with the following:
Code
Now, make the file executable and run it i.e. # ./exploit.py
This should 'hang' the FTP server running in ollydbg. Take a look at the EIP register. On my system, instead of 41414141, it now shows 37684136. Plug this string into pattern_offset.rb, as shown below. Remember to replace the 37684136 with the string you see in the EIP register on your own system.
Code
Now replace the "evil" line in exploit.py with the following:
Code
Run exploit.py again. You should see that EIP has now been overwritten with 42424242,
or 'BBBB'.
==================================================
6. Finding a Home for our Shellcode
Before we work further on the EIP, let's take a look at the bottom right window in ollydbg - the stack. If you scroll up the window slightly, you will see a long string of 41414141s. That's our 230 'A's. Immediately after that, you will see 42424242, followed by a long string of 43434343s.
Looking back at the register window in ollydbg, observe that the ESP register seems to be pointing to a long string of 'C's, or 43434343.... Choose the ESP register value and right-click on it, then choose the "Follow in Stack" option. In the stack window of ollydbg, you will be directed to the 3rd row of 43434343. On my system, the address of this row is 0x013CFC18. Now scroll down the stack window to the last row of 43434343. On my system, the address of this last row is 0x013CFF08. This means we have about 0x2F0, or 752 bytes to work with.
For a straightforward exploit (as is the case here), this is more than sufficient space for a tcp bind shell or reverse shell. Seems like a good place to house our shellcode in!
==================================================
7. The Plan of Attack
Let's summarise the key things we found out thus far:
1. We can insert any value, or memory address, we want into EIP. The program will then execute any valid instruction found at the memory address.
2. The ESP points to the 3rd row of 43434343. We can control the values in this row, as well as the 752 bytes there after. Instead of 'C's, we can place our shellcode here.
Based on the above, we can work out the following plan of attack:
1. We need to first find a "JMP ESP" instruction and get its address.
2. We will place this address into EIP, so that the JMP ESP instruction will be executed.
3. We will place our shellcode just after the 3rd row of 43434343, for e.g. in the 4th row.
4. After filling in our shellcode, we will replace all the remaining 'A's and 'C's with x90 (NOPs).
5. When the JMP ESP is executed in point #2 above, the program will first execute the 3rd row, now filled with NOPs, followed by the 4th row and so on, which is now filled with our shellcode. (Sometimes, you may need to adjust the number of NOPs you put in.)
==================================================
8. The JMP ESP Instruction
In ollydbg, press Alt-E to bring up a window showing the list of executable modules of the FTP program. We can try to find a JMP ESP instruction from one of these modules, while bearing the following in mind:
1. We need to avoid using a JMP ESP instruction with an address which contains a x00, x0a or x0d. These are the null byte, line feed and carriage return respectively. They tend to break exploits.
2. We should try to use modules that come together with the program, instead of the modules supplied by the operating system. The addresses within the former are less likely to change with different Service Packs, languages, etc and should be more portable.
3. Windows Vista uses ASLR to randomise the memory addresses of most modules, especially the ones supplied by the operating system. I think Win7 uses ASLR for all modules. The use of ASLR reduces the portability of the exploit, and in most cases, prevents the exploit from working again after the Victim computer reboots.
Now take a look at the list of executable modules. Unfortunately, all of them are modules supplied by the OS. Looks like we have to pick an OS supplied module. If you are following this tutorial using Vista or a newer Windows OS, this means that it will be difficult for you to pwn Vista machines you don't own... well I meant it when I said this was for educational purposes only ;) There are ways to bypass ASLR under certain circumstances, but that's another story.
Anyway double-click on USER32.dll. Then, in the main window (top-left) of ollydbg, right-click and select the option 'Search for -> Command'. Do a search for 'JMP ESP'. You can try using other modules if you like. On my system, I found a JMP ESP instruction at 0x76b8fae1. Don't reboot your machine if you are using >= Vista, or you will have to repeat this step. Remember not to use addresses with x00, x0a and x0d in them.
Next, replace the "evil" lines in exploit.py, with the following:
Code
Now run exploit.py again. The FTP program running under ollydbg should now pause at the 3rd row of 'xcc'. You can verify this by looking at the stack window and the main window of ollydbg.
All that is left now is to replace the 'xcc' with our shellcode. Stay tuned for the 3rd and last part!
No comments:
Post a Comment