0
Exploits And Buffer Overflows
25 January 2011
Havent been on in a while, figured it was time to get back to it. Let's talk about buffer overflows for a minute. The first thing that you as a reader needs to remember is that if you are going to try this, do it in your own lab. I do not endorse or promote hacking into any equipment that is not yours. Let's begin:
First Run your favorite fuzzer (if you do not know what a fuzzer is, i suggest you do some research and then come back), once the application crashes we know that it is most likely exploitable. Next attach you favorite debugger to the application and create your POC to try and replicate the crash. The way it works is by sending the same number of 'A's to the program and then trying to increase the amount of them until you start overwritting parts of the buffer that the program needs to execute. Once this happens back off a couple of bytes. Next divide your string in half, eg.. buffer='\x41' * 500 + '\x42' * 1000 (this is for a 1500 byte buffer). Reattach the debugger and rerun the application, next send the buffer to the program. Once it crashes look at the bytes and see what has overwritten EIP. We can do this 2 ways, the hard way through binary tree analysis or the easy way. Fire up metasploit and run the pattern create ruby script and copy this into the buffer variable, then resend the buffer to the program. Look again in your debugger and copy the numbers from the EIP address. Now start the pattern offset tools in metasploit with the EIP numbers. This will give you the exact number of bytes it takes to over write EIP. We will now adjust our buffer variable to reflect this, let's say for examples sake that the number we recieve is a hex number, open calculator and paste it into the text field, then change it to decimal. So now we have our true address lets say it is 844, our code would look like this. buffer='\x41' * 844 + '\x42\x42\x42\x42' + '\x43' * 656. Now you are probably wondering how we got these numbers let me break it down. '\x41' = A, '\x42' = B, and '\x43' = C, 844 is the number of bytes it takes to get to EIP, the 4 B's are the letters that we will use to check that EIP is only over written by our B's, and the C's are to fill out our buffer. Now we need to find a return address to introduce our shellcode, this will be achieved by using a built in address that windows uses to load core dll's through the same memory address everytime it is loaded. We will use user32.dll, and we will use the esp register since it is pointing to the beginning of our buffer. To do this we use a feature in the debugger to search for core files that are loaded with the program. Once we locate user32, we will enter into it and search for the address comtaining the jump esp command, so we search and find it at 0x77D8AF0A. Now we want our return address to be added to the buffer variable, the way to do this is a little backwards this is because of the little endian architecture. Here it is: buffer='\x41' * 844 + '\x0A\xAF\xD8\x77' + '\x90' * 656. As you can see it is completely backwards, also if you notice i filled the last part of the buffer with nops ('\x90'). Now comes the easy part. Fire up metasploit, load the msfpayload command with the payload that you want, set all the options, and then hit enter. Copy the long set of characters, and assign it to a variable called shellcode. I am not going to show the example of a shellcode variable here, if you have any questions you can PM me on here. Now adjust your buffer variable to add the shellcode variable. buffer='\x41' * 844 + '\x0A\xAF\xD8\x77' + '\x90' * 32 + shellcode. And that is all there is to it,detach your debugger, run the application, and then send you exploit. If all goes well at this point you will have a shell : )
First Run your favorite fuzzer (if you do not know what a fuzzer is, i suggest you do some research and then come back), once the application crashes we know that it is most likely exploitable. Next attach you favorite debugger to the application and create your POC to try and replicate the crash. The way it works is by sending the same number of 'A's to the program and then trying to increase the amount of them until you start overwritting parts of the buffer that the program needs to execute. Once this happens back off a couple of bytes. Next divide your string in half, eg.. buffer='\x41' * 500 + '\x42' * 1000 (this is for a 1500 byte buffer). Reattach the debugger and rerun the application, next send the buffer to the program. Once it crashes look at the bytes and see what has overwritten EIP. We can do this 2 ways, the hard way through binary tree analysis or the easy way. Fire up metasploit and run the pattern create ruby script and copy this into the buffer variable, then resend the buffer to the program. Look again in your debugger and copy the numbers from the EIP address. Now start the pattern offset tools in metasploit with the EIP numbers. This will give you the exact number of bytes it takes to over write EIP. We will now adjust our buffer variable to reflect this, let's say for examples sake that the number we recieve is a hex number, open calculator and paste it into the text field, then change it to decimal. So now we have our true address lets say it is 844, our code would look like this. buffer='\x41' * 844 + '\x42\x42\x42\x42' + '\x43' * 656. Now you are probably wondering how we got these numbers let me break it down. '\x41' = A, '\x42' = B, and '\x43' = C, 844 is the number of bytes it takes to get to EIP, the 4 B's are the letters that we will use to check that EIP is only over written by our B's, and the C's are to fill out our buffer. Now we need to find a return address to introduce our shellcode, this will be achieved by using a built in address that windows uses to load core dll's through the same memory address everytime it is loaded. We will use user32.dll, and we will use the esp register since it is pointing to the beginning of our buffer. To do this we use a feature in the debugger to search for core files that are loaded with the program. Once we locate user32, we will enter into it and search for the address comtaining the jump esp command, so we search and find it at 0x77D8AF0A. Now we want our return address to be added to the buffer variable, the way to do this is a little backwards this is because of the little endian architecture. Here it is: buffer='\x41' * 844 + '\x0A\xAF\xD8\x77' + '\x90' * 656. As you can see it is completely backwards, also if you notice i filled the last part of the buffer with nops ('\x90'). Now comes the easy part. Fire up metasploit, load the msfpayload command with the payload that you want, set all the options, and then hit enter. Copy the long set of characters, and assign it to a variable called shellcode. I am not going to show the example of a shellcode variable here, if you have any questions you can PM me on here. Now adjust your buffer variable to add the shellcode variable. buffer='\x41' * 844 + '\x0A\xAF\xD8\x77' + '\x90' * 32 + shellcode. And that is all there is to it,detach your debugger, run the application, and then send you exploit. If all goes well at this point you will have a shell : )
