Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

Here's the scenario, part of a wargame/CTF type exercise. There is a vulnerable program running as a service on the remote host. I have access to a copy of the binary, which has a stack overflow from an unchecked scanf.

I am able to trigger the overflow and execute code, but I'm having trouble figuring out what to use for the return address. If I run the binary on my test machine, I can successfully get a shell only if I know roughly the address of my shellcode on the stack. At the time of the overflow, none of the registers contain the location of the shellcode. My thought was that I should be able to brute force the return address, but that hasn't been working on either my test instance (ASLR disabled) or the remote service (ASLR status unknown).

share|improve this question
Are you including the shellcode as part of the buffer and jump that part of the stack? If I were to brute-force anything, it would be the location of the shellcode in the buffer, not the address. OR am I missing something? – schroeder Feb 7 '12 at 0:26
Yes, that's exactly what I meant. The problem is I can't reliably determine where in memory the buffer is. – Tyler Feb 7 '12 at 16:44
You mean on the remote machine? Your narrative seems unclear. You can get a shell on your local machine (where you know the address of the shellcode) but you can't get a shell on the remote machine because you aren't sure of the memory location? – schroeder Feb 7 '12 at 17:03
The local machine is a test instance, so I can run the service out of gdb, and can therefore look at where things land in memory. I'm still running the exploit remotely. But yes, you are correct. – Tyler Feb 8 '12 at 14:52

1 Answer

up vote 2 down vote

Try to get as much information about the remote machine as you can and match it on your test instance. The remote machine is probably running a slightly different version of the OS such as a different release or patch level or sometimes even language pack that could throw off the addresses. There could also be a difference of 32bit vs 64 bit. Using a return address thats inside the application's own code/data section can help with that as well.

If your test instance matches the target's software perfectly, then if you had to disable ASLR on the test instance manually then theres a good chance its enabled on the target.

Also, try using a large NOP sled (string of 0x90 or no-operation instructions) so that you don't have to have the exact memory address. You could be off by some number of bytes but as long as you land in the sled you'll hit the shellcode.

Good luck!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.