Local buffer overflows are relatively easy to understand: throw some input at an interface and see if the process fails with a core dump or similar. However, in my mind, this kind of exploit works well only when the attacker has had unlimited access to test the interfaces and see how their input affects the process.

However, for things like locked-down appliances (firewalls, proxies, etc.), high-end commercial-grade servers, or specialized software where an attacker cannot easily acquire it to play with, how does one successfully gather the feedback necessary to mount an successful attack?

(I realize if the asset is of sufficient value, a motivated attacker will purchase such a specialized device, but I'd like to know -- in theory -- how it might be done without local access.)

Edit: I'm also assuming the attacker does not have access to a generic remote shell.

  • The Blind ROP attack is one recently-revealed way that attackers could successfully gather the information needed to mount a successful attack, when they have no prior knowledge of the target, they don't have the device themselves, they don't have source code, they don't even have a copy of the binary executable running on the target device. Read the research paper for more details of how that would work. – D.W. May 28 '14 at 22:34

You mentioned the most common answer in your question - for things like firewalls, proxies, high end servers etc., attackers will acquire them. They may then lease out shells for practicing. The market in this side of things is incredibly professional and well organised, with entire trading platforms set up to manage tiers of researchers and exploiters.

The route when an attacker does not have access is educated trial and error - for example the attacker may know that an appliance is based on a particular OS, so makes some educated guesses at stack sizes etc. to build a remote shell exploit and NOP sled of a size that may work and just try it and see if their exploit code returns a shell.

  • If at first nothing happens - try again.
  • If the server fails to respond - they may be close, but causing a problem - try again
  • If the shell is created - profit!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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