First Time Writing a BoF Exploit (Stuck)

[oib111]

So I have BT4 running in a Virtual Machine, and I have Windows 7 as the host computer. I'm trying to write my own Buffer Overflow exploit for an old, vulnerable, version of 3COM FTP, but I'm stuck. I figured out which bytes overwrite the EIP, but I can't figure out where to go from here. I can't find a register that points back into my buffer. I am new to this topic, so if there's another way of getting back into my buffer, please excuse my lack of knowledge.

[lupin]

Originally Posted by oib111

So I have BT4 running in a Virtual Machine, and I have Windows 7 as the host computer. I'm trying to write my own Buffer Overflow exploit for an old, vulnerable, version of 3COM FTP, but I'm stuck. I figured out which bytes overwrite the EIP, but I can't figure out where to go from here. I can't find a register that points back into my buffer. I am new to this topic, so if there's another way of getting back into my buffer, please excuse my lack of knowledge.

Some suggestions:

Do any of the registers refer to a memory location containing a pointer to your buffer? If thats the case you can use a JMP PTR [Register] opcode, e.g. JMP PTR EBX if the contents of the memory location referred to by register EBX is a memory address pointing to your buffer.

Or does the stack contain a suitable return address, even a few entries down? You can then use an opcode with the appropriate number of POP instructions followed by RET, e.g. if the third entry down on the stack points to an appropriate address use POP, POP, RET. The POP instructions can use any register, the point is just to get at the memory address that you can use for the RET instruction.

Have you looked at a already existing exploit for this vulnerability to see how someone else has done it?

[oib111]

Ah, thanks for those suggestions, I'll look into that right now.

EDIT:

Ok, couldn't find any registers that referred to an address that pointed back to my buffer, but I did find something in the stack that points back into my buffer. Not sure how to get to it though, here's a picture:



Looks like it'd take 27 POPs to get to the pointer... :S

[lupin]

The third entry down on the stack appears to contain an address (01DBFBC0) that points near the start of your buffer (at least the section of it I can see from your screenshot). Whats in that memory location and how far away is it from where memory is overwritten by characters you can control? Look at that memory in disassembler mode too so you can see what instructions would run if you redirected execution there - depending on what they are you may be able to let those instructions run and then have execution passed to the shellcode in your buffer.

Also, what is located in the first four bytes of data in the memory location referred to by register EBP (01DBF498)?

And one more thing, what happens if you make your buffer larger? Can you manage to overwrite SEH? (You can see the SEH handler address in the 7th entry down on your stack).

[oib111]

I checked the four bytes at the address pointed to by ESP and EBP and neither seem to be near or in my buffer. That address on the stack you pointed out works great (kind of). I scanned the file using msfpescan and found a POP POP RET. The only problem is the buffer points to the part of my buffer that comes right before the return address, so it would start executing commands four bytes before the return address which is fine because I can NOP out the four bytes before the return address, but then it tries to executed the return address as a command...anyway to avoid this? I was thinking I could use a short jump (0xEB if I'm not mistaken) to jump past the return address.

[lupin]

Originally Posted by oib111

The only problem is the buffer points to the part of my buffer that comes right before the return address, so it would start executing commands four bytes before the return address which is fine because I can NOP out the four bytes before the return address, but then it tries to executed the return address as a command...anyway to avoid this? I was thinking I could use a short jump (0xEB if I'm not mistaken) to jump past the return address.

Yes, a short jump past the return address is what you want to do. If you land four bytes before the return address then filling those bytes with \xeb\x06\x90\x90 will do your short jump past the return address (padding before the return address obviously using 2 NOPs) .

Do you then have adequate space in the buffer after the return address for your shellcode? Its obviously dependent on what shellcode you want to use, but the common Metasploit Windows reverse shell usually needs between 315-400 bytes, depending on encoding requirements.

[oib111]

Thanks, that's work although I did it slightly differently (put the NOPs first) and there are some extra bytes to account for. But, something isn't working. My overflow buffer is:

jmp = '\x90\x90\xEB\x0A'
ret = '\x84\x18\x41\x00'
buffer = '\x41' * 230 + jmp + ret + '\xCC' * 962

I got 0x411884 from running msfpescan -p on 3CDaemon.EXE, it contains pop esi, pop edi, ret. Anyway the problem is when I run the exploit this is what happens in olly:



Pretty obvious that something's going wrong. Even weirder, I set a BP on 0x411884 just to see if it was even being jumped to, and the BP was never hit...

[lupin]

Originally Posted by oib111

Pretty obvious that something's going wrong. Even weirder, I set a BP on 0x411884 just to see if it was even being jumped to, and the BP was never hit...

If the buffer is otherwise exactly the same but you have \x42 * 4 for the ret address you still get a crash (with eip pointing to 42424242) I assume?

You are most likely running into a problem with that \x00 in your ret address (null is a string terminator and depending on your input method it can mangle the buffer). Find a POP, POP, RET in one of the dlls called by that app that doesnt contain a zero in the address, and try that instead. Id start with checking user32.dll or shell32.dll if your vulnerable program calls them - they are usually good prospects.

[oib111]

I know I tested to see if it'd crash on 0x42424242 but I don't remember the results and I can't test right now because my network is down and can't get Virtual PC working with my neighbors network. Also, I used msfpescan to find the pop pop ret, and I don't think there was a single one that didn't start off with 00... :S

EDIT:

I tested it and if I overwrite EIP with 0x42424242 it does the same thing. But if I remove the the jump it works...?

[Gitsnik]

Originally Posted by oib111

I know I tested to see if it'd crash on 0x42424242 but I don't remember the results and I can't test right now because my network is down and can't get Virtual PC working with my neighbors network. Also, I used msfpescan to find the pop pop ret, and I don't think there was a single one that didn't start off with 00... :S

EDIT:

I tested it and if I overwrite EIP with 0x42424242 it does the same thing. But if I remove the the jump it works...?

Which exploit are you trying exactly? Can you do a quick search through metasploit or milw0rm archives to tell us what one you are trying for.

If you are trying the USER one, and my memory is serving me correctly, there you need an SEH in place.

Go manually looking through the reported DLL's that have been loaded, there should be one in ntdll for you that works just fine (it starts with 0x77 rather than 0x00). Then you should be able to construct your attack string quite simply as you have been - \x90 * howevermanytopadwith + poppopret + jmpecx + \x90 * 14 + \xCC * 500

You should land somewhere in your \xCC's if all things continue to operate.

Something to note about testing SEH exploits in Olly - you need to hit the play/run button once after the "crash" occurs, as you fall into the SEH handler and then later on fall into your EIP overwrite. Have a play around and you should get what I mean.

Finally: Doing this sort of development will be easiest for you on an XP SP 2 or earlier machine, 7, Vista and perhaps even Virtual Machine, have protections built in place. You also don't technically need Backtrack for this exercise (except for the actual shellcode generation/acceptance component)