FastSpy is an oooooooooooooooooooold multithreaded network scanner, circa 1999, that doesn’t really see any use nowadays. I started using Koders to dig around projects and find potential exploits, and ran across this one. It’s drop-dead simple in practice (deceptively so), and there were a few interesting parts to it so I figured I’d throw this up. At the time of writing, I don’t think the original developer is even around, and I haven’t seen this posted anywhere else.
While parsing through code for strcpy’s, I discovered FastSpy parsing input files with the following:
1 2 3 4
Where InputFileName is a 128 byte character buffer. This vulnerability exists with a couple flags used by FastSpy, though it appears they actually read the data in correctly.
I wanted this to be a Windows PoC, so I loaded up PowerShell (who knew, right) and tried it out:
I should note there’s a bit of cheating here, because I had already done this and figured out the values for overwriting the NSEH/SEH. The above will launch Immunity with the FastSpy executable and the passed arguments. That address will bring us right up to the NSEH.
One interesting bit here is that we’re overflowing a filename and we’re using Python. As of writing, os.system() does not allow us to pass addresses as arguments to applications without getting UTF encoded. Because of this, my ‘\x90’ in the above line will not properly encode. Instead, we need to do a little magic; here is a great source for finding alphanumeric equivalents. Typically you’d use this thing for obfuscating shellcode to evade IPS/IDS/AV’s, but in our case it’s different. I opted for ‘\x50\x58’, which is a POP then a PUSH, so an equivalent two-instruction NOP.
As per the typical SEH exploit, I needed a POP POP RET. From there, I needed a JMP back into shellcode. Unfortunately, the JMP opcode, \xeb, isn’t going to work because its not available in the alphanumeric set. Instead we’ll use a JE, \x74, to give us enough room to hop back into a bigger jump. Our command now looks like this:
Couple of things to note; we’ve halved our NOP count because each NOP is now two instructions. I’ve added the ABCD ASCII values to show where our JE will hop into, the JE instruction, and finally my chosen POP POP RET address. Here’s a shot of the debugger at the JE instruction:
You can see the four letters as instructions just above our JE instruction (
\x41\x42\x43\x44). Conditional jumps are restricted to +/– 127, which is why we’ve got \x80 loaded up. With this, you can see our NOP sled full of bytes waiting for your shell. The shellcode needs to be alphanumeric, so I had to run it through msfencode -e x86/mixed_alpha or using Skypher’s ALPHA3.
In actuality, it was a huge pain to get this to work properly in the environment that I was developing in, but I was curious nonetheless if it was possible. At this point I decided to switch to C so I could hack it out. Copying over most of the work I’d already done, I got this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Just a few things to note on this; calculating near jump. Once we’ve got the short jump back into controlled space, we need a near jump to further ourselves to the top of shellcode space. This can be done with the \xe9 opcode. To calculate the exact distance, we need to subtract the origin address from the destination address. This can be done with gdb:
Now that we’ve got the distance, we need the number in hexadecimal. This can be calculated by taking the negative of the number and converting it to hex:
So now we know that our near jump is going to be
Otherwise the vulnerability is a straight-forward SEH exploit. I was particularly interested in getting the alphanumeric shell to work, though.