Why bother with Buffer Overflows and Exploit Modification?
I was having a conversation with a relatively green, aspiring, penetration tester the other day, and he asked me why he should bother to learn how to modify exploits – particularly buffer overflows. This is a fair question for somebody who has only really had exposure to the basic use of Metasploit. Don’t get me wrong, Metasploit is certainly a powerful tool, it has a lot of convenience features that make penetration testing a little easier to manage, however, like all tools - it has its limitations.
I asked him to name the first product he could think of, luckily for me, he named a product that perfectly demonstrated the point I was about to make. I had him search for a Metasploit module that would exploit the service and could result in a reverse shell. With a smug look on his face over our video call on Skype, he proudly announced that he had found one.
I had a brief look at the module to see which operating system(s) it had been tested against; it was tested against the Polish version of Windows SP2. I spun up a virtual box image of the English version of Windows XP Service Pack 3, installed the vulnerable software and a debugger, and found another proof of concept exploit for the same vulnerability on a website called Exploit-DB (Exploit-DB is usually my first point of call for exploit PoCs). I chose this operating system because it is rather common (even today!), and in a real life penetration test you don’t have the privilege of deciding that your target machine will host the exact same operating system that was pre-tested for a particular exploit – in this case, the Polish version of Windows XP SP2.
I modified the proof of concept exploit code, and proceeded to exploit the service to verify that it could be done before presenting this young man with a challenge. I asked him to exploit it using the Metasploit module he found. He loaded the VM of Windows XP SP3 I sent to him, and attempted to exploit the service. Several minutes later, he told me it failed. I asked him why it failed, and he was unable to answer that question.
It failed him because the address for the ‘JMP ESP’ command used in the exploit was the wrong address for this combination of vulnerable product and operating system. Before I was able to exploit it, I had to attach the vulnerable product to a debugger in the same operating system as the target in order to find a valid address to use.
Hopefully, you now agree that knowing how to modify an existing proof of concept exploit can mean the difference between successfully penetrating a system and feeling trapped by the limitation of your favourite tool.
If you are not sure what a ‘JMP ESP instruction’ is and feel like I have perhaps delved into some mystical black magic, rest assured that it is quite simple once you get the hang of it. I have provided a walkthrough demonstrating exactly how I accomplished this in my upcoming book, so that you can follow along at home.