My latest finding: A classic buffer overflow. And this time I’ve used the great mona.py script created by the corelan team to exploit the vulnerability. It helps to find memory addresses for all of your stack adjustment needs (beside this, the script has got a lot of other powerful functions too).
During the investigations on the vulnerability I recognized that it’s quite a long way from the current position at crash-time (0x0012E3E8) to the overwritten part of the Stack (0x0012E7E8):
So you need to jump a lot of bytes to get to the shellcode. Therefor the mona.py script has got a quite cool function:
It looks for all kinds of “stack pivots” (or easier to say “stack adjustments”) in the debbugged application and generates a log-file with all of them including possible protection mechanisms like ASLR or SafeSEH. Since you need roughly 1000 bytes to get to the shellcode, you can now have a look at the mona output and choose one, which moves the ESP to your desired position like e.g.:
This moves the ESP 1036 bytes directly into the shellcode and makes Exploit - development again a lot more easier than doing everything by hand.
Finally my exploit looks like this:
And it works:
To execute my shellcode I had to use a CALL from the shell32.dll which makes the Exploit unreliable on other systems than Windows XP SP3. The executable itself contains a lot of CALLs and JMPs to the ESP, but however for some reasons I cannot use addresses with two zeros in front for the CALL ESP function, otherwise it completely breaks my exploit. Don’t know why yet. Still investigating. There is always a way! :)