Vulnserver is a Windows server application that deliberately includes a number of exploitable buffer overflow vulnerabilities, and was designed to act as a target application to teach and practice basic fuzzing, debugging and exploitation skills. More information on Vulnserver, including a download link, is available here: http://grey-corner.blogspot.com/2010/12/introducing-vulnserver.html or here. This tutorial covers how to confirm that a particular stack based overflow vulnerability is exploitable, as well as how to actually develop the exploit. The process of initially discovering vulnerabilities however is not covered in this tutorial. To learn one method by which such vulnerabilities can actually be discovered, you can check out a previous Vulnserver related article on fuzzing, available here:
/intro-to-fuzzing/ /fuzzer-automation-with-spike/
This tutorial will also assume that the reader has a reasonable level of skill in using the OllyDbg or Immunity Debugger debugging applications, as well as a basic knowledge of X86 assembly language. For those who are new to these debuggers, or who may feel they need a refresher in assembly, the required skills are covered in the following links:
/debugging-fundamentals-for-exploit-development/ /in-depth-seh-exploit-writing-tutorial-using-ollydbg/
Lastly, you will require a basic knowledge of how stack based buffer overflows are exploited. The particular exploit we will be covering in this article requires the use of some slightly more advanced debugger skills and exploitation techniques, and was written in order to build upon exploitation skills already taught in previous entries in this series of articles. You can read about how to exploit basic stack based overflows in the following article:
/stack-based-buffer-overflow-tutorial-part-1-%e2%80%94-introduction/ /stack-based-buffer-overflow-tutorial-part-2-%e2%80%94-exploiting-the-stack-overflow/ /stack-based-buffer-overflow-tutorial-part-3-%e2%80%94-adding-shellcode/
The remaining entry in the Vulnserver series, which ideally should also be read before continuing, is available here: /seh-exploit/ System requirements and setup The following software is required to follow along with this tutorial:
A 32 bit Windows System. I would suggest sticking to reasonably recent windows desktop systems such as Windows XP SP2 and up, Windows Vista or Windows 7, as these are the systems that I have personally tested. Windows 2000 desktop and server based systems may also work, but there are no guarantees. Vulnserver on your Windows system. You can obtain information about the program (which should be read before use) and download it from here: http://grey-corner.blogspot.com/2010/12/introducing-vulnserver.html OllyDbg 1.10 on your Windows system. You can also use Immunity Debugger if you prefer, but just keep in mind your screenshots will appear slightly different to mine, and certain steps in this tutorial regarding OllyDbg plugins may not be able to be performed. OllyDbg can be obtained here: http://www.ollydbg.de/ An instance of the Perl script interpreter. You can run this on either your Windows machine or on a Linux attacking system. Linux systems should already have Perl preinstalled, but if you want to run it on windows you can obtain a Perl install for free from here: http://www.activestate.com/activeperl A recently updated copy of Metasploit 4. You can again run this on either your Windows machine or on a Linux attacking system, although I recommend running it on a Linux system. See the following paragraphs for more detail. Metasploit can be obtained for Windows and Linux from here: http://www.metasploit.com/ A copy of netcat. Most Linux systems should already have one installed, you can grab a Windows version from here: http://joncraton.org/blog/46 If you want to assemble the shellcode that is written in this article, you will also need an installed copy of nasm from here: http://www.nasm.us/. This is only used in one small part or this tutorial however, and can be considered optional. If you intend to regularly be writing exploits however, nasm will definitely be something you should have in your toolkit.
My personal setup while writing this tutorial was to execute Metasploit commands and run my exploit Perl scripts from a Linux Host system running Ubuntu, with Vulnserver running in a Windows XP SP2 Virtual Machine. This means that command syntax provided in this document will be for Linux systems, so if you are following along on Windows you will have to modify your commands as appropriate. I have chosen to run Metasploit and Perl from Linux because components of the Metasploit framework can be broken by many of the common Anti Virus solutions commonly installed on Windows systems. If your Windows system is running a firewall or HIPS (Host Intrusion Prevention System), you may need to allow the appropriate traffic and disable certain protection features in order to follow this tutorial. We will be creating an exploit that makes Vulnserver listen for shell sessions on a newly bound TCP port, and firewalls and possibly HIPS software may prevent this from working. Certain HIPS software may also implement ASLR, which could also be problematic. Discussing firewall and HIPS bypass techniques is a little beyond the scope of this tutorial, so configure these appropriately so they don’t get in the way. I am also assuming for the purposes of this tutorial that your Windows system will not have hardware DEP enabled for all programs. The default setting for Windows XP, Windows Vista and Windows 7 is to enable hardware DEP for essential Windows programs and services only, so unless you have specifically changed your DEP settings your system should already be configured appropriately. See the following links for more information:
http://en.wikipedia.org/wiki/Data_Execution_Prevention http://support.microsoft.com/kb/875352
My Windows Vulnserver system will be listening on the address 192.168.56.101 TCP port 9999, so this is the target address that I will use when running my Perl scripts. Make sure you replace this with the appropriate values if your Vulnserver instance is running elsewhere. A note about using different Windows Operating Systems versions: Be aware that if you are using a different version of Windows to run Vulnserver than the Windows XP Service Pack 2 system I am using, some of the values you will need to use when sizing the buffers in your exploits may differ from mine. Just ensure that you are following the process I use in determining buffer sizes, rather than copying the exact values I use, and you should be fine. I have indicated in the tutorial the areas in which you need to be concerned about this. Overview of the Process We will be using the following high level exploitation process in order to take control of this program:
Get control of the EIP register which controls which code is executed by the CPU, setting it to a value of our choosing, Identify some code that will fulfil our goals for the exploit, and either find it on the target system or insert it into the program ourselves using the exploit, and Redirect EIP towards our chosen code.
As in the previous article in this series on exploiting buffer overflows (see the links in the Introduction), this list of requirements acts as both the steps required to actually write the exploit, as well as determining if the vulnerability is exploitable. We will assess the given vulnerability to determine if these particular steps are possible, and once this is confirmed we will know that exploitation is possible and be well on our way to producing a working exploit. Those who are paying attention will note that the exploitation process described above has not changed at all from the previous entries in the series. Even as the exploits themselves become more complicated, the general steps for performing them essentially remain the same. It is only the techniques used in actually taking these steps that will change. As mentioned during the Introduction, you should already be somewhat familiar with the general way in which buffer overflow exploits are written before you attempt this tutorial. The particular vulnerability we will be looking at today requires the use of a new technique in order to produce a working exploit. Implementing this new technique, and determining when using this technique might be useful will be the main focus of this tutorial. While I will still make reference to the basic exploitation techniques covered in the earlier articles in this series, I wont cover them in as much detail as I have done previously, so if you are confused by any of the initial steps in this article, please take the time to review the previous entries in this series. As previously mentioned, links are provided in the Introduction to the previous entries in this series. Assessing the vulnerability The vulnerability we will be attempting to exploit is a stack based buffer overflow in the parameter of the KSTET command of Vulnserver. We can trigger an exception in the program by sending a KSTET command with a parameter consisting of a long (~100 characters or more) string including at least one full stop (.) character. To demonstrate this, we can use the following script, which will send “KSTET .” followed by 1000 “A” characters (x41 in hex) to a specified IP address and port provided as command line parameters. As we progress through the exploit development process, we will slowly modify this basic POC script into a full blown exploit. Save the following as kstet-exploit-vs.pl. Note: You may have noticed that I mentioned that the exploitable vulnerability requires approximately 100 characters to trigger, yet I have set a buffer size of 1000 in the proof of concept exploit code above. Why did I do this? I chose a size of 1000 bytes because under normal circumstances this will provide enough slack space within the data we send to include some shellcode to take control of the system. Later on in this article however, you will see that we run into a problem with this theory. Now Open vulnerver.exe in OllyDbg and hit F9 to let it run. Then, execute the script as follows to generate the exception within the debugger. You should be greeted with the following in the debugger – an Access violation error will be shown at the bottom of the screen, and execution of the program will be paused within the debugger.
In this case we see that the EIP register contains a value of 41414141, a hex representation of the “A” characters we sent to the application in our POC exploit. The EIP register containing a value that looks like it has been taken from data we sent to the application is a good sign that this vulnerability is ripe for exploitation. Lets see if we can overwrite EIP with a value that allows us to redirect execution to code of our choosing. By looking at the register values in the register pane, we can see that ESP contains an address that sits within an area of the stack containing the “A” characters we sent. You can right click on ESP and select either Follow in Dump or Follow in Stack to confirm this, or just visually compare the value of ESP (00B6FA0C in the screenshot above) with the addresses in the stack pane where the long sequence of x41 bytes reside. Given this, if we can use our control of EIP to redirect to a JMP ESP instruction, we should be able to land execution within this area of memory, where the contents are under our control. We will then attempt to replace the contents of this section of memory with code that allows us to take control of the system, and have that code executed by the CPU. You might recall that this is the process we followed in the original stack overflow article earlier in this series. As a reminder, to have our exploit perform this “jump” we need to find out the offset within the data we send to the application where the address of EIP is overwritten, then we need to replace the four bytes starting at that offset with the address of an existing and non-changing JMP ESP instruction located within program memory. This will result in that JMP ESP instruction being executed by the CPU once the overwritten return address is loaded into EIP, which will in turn redirect execution into the area of memory whose contents we control. First lets find the overwrite offset. As before, we will do this using the pattern_create.rb tool from Metasploit. First we use the tool to create a unique pattern of the appropriate length, 1000 bytes in this case. Note: Your Metasploit install path might be different than the one I have specified in the command line below. Modify the command as needed to point to the correct location of the pattern_create.rb executable, which should sit in the tools subdirectory in the Metasploit install path. Also, be aware that I have removed some of the output below for the sake of readibility. The output you see will be a little larger.. Then we edit our exploit to send the pattern to the application. In the code below I have broken my pattern up into sub strings before adding it, to make the below more readable, however you can feel free to add it in one big string Now we restart the program in the debugger (Debug menu Restart), and allow it to run (hit F9) and then execute our modified exploit. The exception should occur again, with EIP being set to the value shown below.
In the screenshot of the register pane shown EIP has a value of 41336341. Feeding that value into pattern_offset.rb has the following result. This is telling us that EIP is overwritten at an offset of 69 bytes into our pattern. Note: Did you have a different value for EIP than the one shown in my screenshot above? Remember, its more important to follow the process I use here rather than to copy the exact results I obtained. If your value for EIP was different, feed that into the pattern_offset.rb tool instead, and use the output you receive as your offset value. Lets modify our exploit once more to confirm that this offset value is correct. We will send 69 “A” characters to the application using our $baddata variable, followed by 4 “B” characters, then some more “C” characters to follow. If this works as intended, EIP should be set to 42424242 (the hex representation of 4 “B” characters) when the exploit runs. Restart the program in the debugger and let it run, then execute the exploit again. We should see something similar to the following in our debugger:
EIP has been set to 42424242, as we predicted, and if we look at the data in our stack pane, we can see “A” characters (x41) before our overwrite address and “C” characters (x43) after it. In the screenshot above, the overwrite address of 42424242 is the entry highlighted in grey in the stack pane. Now that we know which bytes of data sent from our exploit are used to set the value of EIP, we can proceed to the next step of finding the address in memory of a “JMP ESP” instruction that we can use for the overwrite. As in the previous buffer overflow entries in this series, we will check modules included with the main program first. Please note that at the moment, we have not done anything not already covered in previous entries in the series, so I’m going through this material at a slightly faster pace than I ordinarily would for someone new to the material. If you need more detail on any of the steps at this point, please refer to the original stack overflow article. To start searching for a “JMP ESP” instruction, in the debugger use the View menu, Executable modules option, and in the window that appears double click on the essfunc module, which according to the module path should be running from the same directory as the main vulnserver executable. The essfunc module should now be shown in the CPU view of the debugger. Right click in the disassembler pane and select Search for->Command and in the “Find Command” window that appears type “JMP ESP” (without the quotes) and hit Find. The disassembler pane should now show the address of the first “JMP ESP” instruction in the essfunc module.
The address of the instruction, as you can see in the screenshot above, is 625011AF. This address has no common bad characters (e.g. �0, �A, �D) contained within, so it should provide a good overwrite address for us to attempt to use. Restart the program in the debugger, hit F9 to let it run and then hit Ctrl-G to bring up the “Enter expression to follow” window. Enter the address of the instruction we just found (625011AF) in the box and hit OK to take you back to this address, then hit F2 to set a breakpoint. The background of the address should turn red to indicate the breakpoint is set. This breakpoint will ensure that the debugger pauses when the CPU attempts to execute the instruction at that address. Now lets modify our exploit to try and redirect execution to this address – see the exploit code below. In addition to adding the newly discovered “JMP ESP” address to the appropriate location in our $baddata variable, we will also add some INT3 breakpoints (xCC) into our exploit following the overwrite address, to provide a second means of pausing execution in the debugger. Also, don’t forget that due to the little endian order of the x86 processor family, we need to order the bytes of our overwrite address from least to most significant, which we can do by feeding the appropriate value into the “pack” function. Now run the exploit. You should hit the breakpoint you set, and hit hitting F8 should step you through to the first of the INT3 breakpoint characters sent from our exploit. We have now redirected execution into a section of the programs memory where the contents are under our control.
Its at this point in the exploit writing process where we would usually aim to replace the contents of this section of program memory with some shellcode to allow us to take control of the system. If you have been paying close attention however, you may realise that we have a problem. Despite the fact that we sent close to a thousand INT3 xCC breakpoints to this program, we are only seeing 20 of them in memory (see the screenshot above). In addition, we only have 69 usable characters before the point in our sent data where we overwrite the value of EIP. Is there any shellcode that will fit within this tiny amount of space? To check, we can pipe the output of msfpayloads payload list command (msfpayload -l) into this perl one liner, which will execute msfpayload in summary mode for each windows “shell” payload, so we can check the shellcodes size. As you can see from the output above, there are no usable shell providing payloads that will fit within the limited buffer space that we have available. So what can we do? Hunting for eggs As it turns out, there is another type of shellcode that can be useful in this type of situation, where we have an exploit with extremely restricted amounts of usable space. It is referred to as egghunter shellcode, and it is essentially a very small piece of shellcode that allows you to search for a pattern within a programs memory space, and redirect execution to a location in memory immediately following that pattern. The point of this is to allow your exploit to execute shellcode (otherwise known as an “egg”) that you have secreted elsewhere in memory. To use it, you need to be able to introduce your “egg”, the shellcode that you want the egghunter to run, into program memory, and ensure that it will still be there at the time that the vulnerability you are exploiting is triggered. The particular egghunter shellcode I normally use is 32 bytes in size, which will easily fit within the 69 bytes of usable space we have available in this exploit before the EIP overwrite address. The only remaining question is, can we find another way to insert additional shellcode into this program so that it will be present when we try to redirect to it? To see if this situation applies in the case of this particular exploit, we are going to look at the various ways that we can send data to the Vulnserver program, and see if any of these allow us to effect the contents of program memory as it exists at the time of the KSTET exception. Now, there are a number of ways we can go about testing this. Depending on the complexity of the program, we might need to use fuzzers and automated memory analysis methods in order to enable testing all of the inputs in a reasonable time, or debug the program to see how it processes data before sending anything, in order to work out how to sneak additional data in. For example, the data we send might need to be in a certain format, or might need to match a certain pattern before it is appropriately stored. We might also need to take into consideration the fact that sending multiple pieces of data then causing the exception might provide different results than sending those same pieces of data individually and causing the exception. This could be caused by the program cleaning up older sections memory when a certain amount of data is sent to it, or because particular commands send to the application might trigger an action to deliberately clear other data. Complicated, right? Luckily in our case, Vulnserver is quite a simple application, so to start off with we are going to just run straight at it and see what results we get by sending data to the application in each of the most obvious ways available to us, then causing the exception, and seeing what sticks. If that doesn’t work, we can keep trying, this time paying more attention to the finer details. As a reminder of what commands are available to us for sending data to the application, we can restart the program in the debugger and query it. The output below shows me connecting to Vulnserver using netcat and sending it a “HELP” command to see what commands are supported. The commands above can be used as our means of sending data to the application. We will modify our existing exploit code to run these commands, and then cause the exception, so we can check if this approach is effective in allowing us to control the contents of memory when the exception occurs. The exploit will be modified to send 500 bytes of data to the application using each of the commands above, as well as sending that data without a command. Why 500 bytes? I picked this particular size because it is larger than the required size of the various shellcodes that we checked a moment ago, but hopefully not large enough that it will trigger off any other exceptions in this rather buggy Vulnserver application. Another thing we must consider is that since we are sending the data from each of these commands to the application at the same time, we also need some way of determining which data is associated with which command. This is so that when we find a certain set of data in memory, we can work out which command was used to put it there. Its possible that the entire command will be left intact at the time we are looking for it, for example we might see the “STAT” command before data, indicating the STAT command was responsible for that data being present, but I don’t want to rely on that. Consequently, we will aim to achieve this goal by sending different data with each command. In the code below I have placed each of the commands I wish to run in an array, which I then iterate through in order to process each item individually, adding a string of 500 unique characters, before finally sending that command to the application. I have also modified the $baddata variable, containing the data that causes the exception, to replace the “A” characters previously used with x90 NOP instructions, to free up the “A” character for use in this testing. You should also note that in the code below, these additional commands are sent to the application BEFORE we send the bad data that causes the crash, to allow the possibility that it will still be there when the crash occurs. Note: I have left one command out of the array. Can you work out why? Hint, put it in and see what happens. What do you think is happening? Now restart the program in the debugger and run the exploit. The program should pause execution in the debugger, hitting the INT3 breakpoint represented by the first of our xCC characters. Now we need to search through memory for repeating instances of the characters above, to see if any of these commands have allowed us to affect the contents of memory at the time of the exploit. For example, if we find a long string of “A” characters, then sending those characters direct to the program (e.g. NOT preceded by a command) has allowed us to set the contents of memory. If we find a long string of “B” characters, then sending data after the “HELP” command has allowed us to set the contents of memory, and so on. To search through the programs memory for these strings, start by using the View menu, Memory option to bring up the memory map.
This window essentially shows us all of the allocated pages of memory for this particular program. OllyDbg gives us the ability to search through each of them to find a variety of different types of data. To start searching, select the first entry in the memory map window, right click and select Search, and in the window that appears enter a long string of “A” characters in the ASCII box. Selecting the first entry in the list is important as the search is performed in order from the selected entry to the entry at the bottom of the list, and if you neglect to ensure that the top entry is selected when you begin the search you will not see results from any memory page above the one you selected. The exact length of the string of “A”s you enter in the ASCII text box doesn’t really matter, just make sure its long enough to exclude any shorter pattern of repeating “A” characters that might already exist in the program, but not longer than the 500 characters we actually sent to the application. Also, turn on the Case sensitive option, using the check box in the bottom left hand corner of the search window, to further reduce the chance of false positives.
Hit OK to start the search. You should not find any results for your search for repeating “A” characters. Now select the first entry in the memory map once more and repeat this process with the character “B”, and then the character “C”, and so on. When you search for repeating “C” characters, you should get a result, with a memory dump window opening up showing you where they appeared. Expand the size of the window a little so you can see what appears to either side of the pattern you have found. You should see something like what is shown in the screenshot below.
As you can see, some of the data sent to the program using the “STATS” command appears to remain in memory when our exploit is triggered, and if you expand the size of the results window large enough, you will also likely see some of the data sent using the “RTIME” , “LTIME” and “SRUN” commands. The problem though, is that there only seems to be a small number of the characters following each command remaining in memory, not the whole 500 that we sent, and there certainly isn’t enough consecutive space to fit our bindshell shellcode (341 bytes) into. (You can work out the amount of repeating characters shown by subtracting the starting memory address of the string from the ending address.) We can store this little nugget of information away for another time (perhaps it will be relevant for a future exploit…), but for the moment lets continue searching through memory to see if an uninterrupted section of memory that we can control exists. Close the dump window and hit Ctrl-L to continue the search through the rest of the processes memory space for “C” characters. You should not find any more results. Continue on with this process using each of the characters listed in the output of the kstet-exploit.pl file, making sure that you select the first entry in the memory map each time you start searching for a new character. Keep in mind that when you search for the characters “D”, “E” and “F” you will find results relating to the “RTIME”, “LTIME” and “SRUN” commands, as we have seen in the screenshot above. Just ignore these results, as already mentioned they do not provide us with enough consecutive space to insert our shellcode. When you get to the character “I” you should see something like the following pop up.
Expand the size of the window so you can see what is on either side of the string of “I” characters. OK, that looks good, we have a nice long string of “I” characters following the “GDOG” command. We will use this command to try and insert our final shellcode into program memory. (Although we can see the string “GDOG” here in the memory dump before the “I” characters, indicating that this was how they ended up in memory, you might also notice that the “I” character was also associated with the “GDOG” command in the command line output from the last run of our exploit code. This gives us more certainty that “GDOG” is the command we are after.) Note: This covered a manually intensive, and quite time consuming way of finding a particular pattern in program memory. I used this method above to give you a better understanding of what we were actually doing, as well as how to use the OllyDbg memory map to search for data. Once you understand this process however, there are easier ways to achieve this same goal. One such method involves grabbing a dump of process memory, taken at the time of the exception, using a tool such as userdump (http://support.microsoft.com/kb/241215), then processing that dump file to check for the appropriate strings. This command below runs the strings tool in a loop against the process memory dump file “/tmp/share/vulnserver.bin”, then pipes the output into grep to see if a 500 character repeating string of the given character for that iteration of the loop (A through L, the same characters used in our test script) can be found. This will quickly identify the one matching string in the programs memory space. (The output below has been wrapped for readibility.) Additional Note: There is a slight flaw that I have deliberately designed into the process described above, which might cause it to report false negative results under certain circumstances. Can you guess what the flaw might be, and more importantly, can you think of a way to fix it that will work universally for a number of different programs? Need a hint? The problem might have something to do with bad characters… So now we have an additional area in memory, big enough to hold some useful shellcode, that we can control the contents of at the time of the exception. The next step is to place the appropriate shellcode into this area of memory, in such a manner that our egghunter shellcode can find it. The Egghunter Shellcode The particular egghunter shellcode we will be using for this exploit is the syscall egghunter code written by Matt Miller (skape). The paper describing this shellcode is available here (http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf) and C code that produces a Windows application that will generate the shellcode for you is available here (http://www.hick.org/code/skape/shellcode/win32/egghunt_syscall.c). Since the C code above requires a Windows Visual Studio environment to allow you to compile it, I have reproduced the main function of the program in a perl script below so you don’t need to go to the trouble of installing or using Visual Studio. Save the following to disk as egghunt_syscall.pl. This essentially spits out the egghunter shellcode in a hex format suitable for pasting into an exploit, using the search value that you provide on the command line. This shellcode works by searching for a four byte value in memory that is repeated consecutively twice in a row, and it then passes control of execution to the code immediately following. In case you are interested here is the egghunter shellcode below in assembly format. In the code below 0x5433334c is hardcoded as the value that is searched for. The perl script above allows this search value to be specified by the user. I’m going to use the four character string “R0cX” for my search value, so I feed it into the following perl one liner to get its hex representation: Now I can run the egghunter_syscall.pl script with the preceding value as input. This will provide me with egghunter shellcode in hex format, using “R0cX” as its search string. Now we need to insert that egghunter code into our exploit. As discussed before, we will be inserting this egghunter shellcode into the 69 byte area in our $baddata variable before the EIP address overwrite, but inserting the shellcode at that location gives us one more problem we need to address. If you remember, when we run our exploit, execution ends up in the 20 byte space after the area that overwrites EIP. For our exploit to work, we will need to be able to jump execution backwards in memory from this location to the area where our egghunter code is stored. The following bit of assembly code will allow us to do this. This code takes the value from ESP (which as we saw earlier, stores the value of a memory address pointing within our buffer, just after the location of our EIP overwrite address), places it in the EAX register, subtracts 64 from it, and jumps to that address. The code (saved as jumpback.asm) can be assembled and converted to hex format for pasting into our exploit like so. If you don’t have nasm installed (this was listed as being optional in the requirements section) just feel free to skip this step and just copy the hex value from my second command below. Now we modify our exploit as follows. First we set our variable $egghuntme to “GDOG “, followed by two iterations of our search string, followed by the “egg” that we want our egghunter to find and then run. In this case, the “egg” is just a few INT3 breakpoints, just to allow us to successfully test the egghunter works. This data gets sent to the Vulnserver application BEFORE the data that triggers the exploitable vulnerability, to ensure that it is there when the exception occurs. I have also added a few x90 NOP instructions to create a NOP sled before the egghunter shellcode. The jump code that jumps back 64 bytes from the location stored in the ESP register will land on this NOP sled and execution will run through to the egghunter code. This just allows us to avoid having to precisely determine where our jump back code will land – as long as it hits the NOP sled somewhere, execution will continue smoothly from the start of our egghunter. And of course, the jump code we assembled with nasm gets added to the end of the $baddata variable, after the overwrite address. To hopefully clarify what we are doing here, the following is diagram showing the way that code execution will move within memory when this exploit runs.
And here is the updated code including the changes discussed above. Restart the program in the debugger and run the exploit once more. Now, after a short pause while the egghunter does its magic, execution should pause at the first of the four INT3 breakpoints.
This demonstrates that our egghunter is working. The only remaining thing to do is to add some proper shellcode to our egg. With version 4 of Metasploit, we have a new tool called msfvenom which can generate and encode shellcode in one step. We will generate a simple bindshell shellcode, listening on port 12345, and we will encode it to avoid use of the common bad characters “x00”, “x0A” and “x0D”. Note: If you have any issues running the command below, it could be because there isnt a link for the msfvenom executable in your path. If this is the case, simply run it directly from the Metasploit install directory. Now paste the generated shellcode into your exploit like so: Now restart the program in the debugger, and run the exploit: Give the egghunter shellcode a little bit of time to work its magic, and then attempt a connection to the shell on port 12345: We have shell! Another exploit is successful! Now have a go at exploiting the program outside of the debugger. You will notice that there is a delay between the exploit being launched and the shell becoming available, which is due to the actions of the egghunter, scouring through memory until it finds the search string and is able to pass control to the “egg” shellcode that follows.
