Find Buffer Overflows at a target you want to gain access

Question

I want to pass my OSCP exam and I am learning with the material I got. I watched the videos and read the pdf but I have a question about buffer overflows.

In the example in the videos, the guy has access to the target system and can so control, debug and restart the application. So he can see what length he should send to cause the buffer overflow and where the EIP register is in the sent string and so on.

But my intention of a buffer overflow is to get access to a system I have not accessed before, isn't it?

So how do I get to know all the relevant data without having access like debug functions before?

Answer 1

As schroeder has already pointed out, to identify buffer overflow vulnerabilities, you'd need to test the application locally with a debugger. It seems to me that you haven't actually gone through the process of learning to identify and debugging possibly vulnerable applications to buffer overflow.

Instead of walking you through the basics of the process here, I will attach what I believe to be excellent starting points, so that you can study and get the 'gist' of buffer overflows on your own.

1. Understanding what you're working with (ASM)

   • x86 Assembly Wikibook: Excellent and thorough resource for getting into assembly. If you don't already know how to detect interesting parts of the code, then you should start from this. It might seem daunting at first, but once you get into it, it will seem much clearer.

   • Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software: Chapter 4 is a brief "Crash-Course" in disassembly, which I consider an absolute must!

   • Modern C: This is an excellent book (and free) for the C programming language. The author also provides the code examples used in the book.

   • Pointers in C - A Hands on Approach: This is a great book to understand pointers and memory management in a program.

2. Getting the right tools

   • The tools that you'll need are almost always going to be included in VMs used for memory debugging/reverse engineering, but you can always download the ones you prefer. My approach for learning something and understanding it for the first time, is to go "full manual". A good debugger for this is the GNU debugger (GDB). There are other debuggers which are more automated/advanced, but I do not recommend those for beginners, because you learn better by doing it the hard way.

   • GDB PEDA is an awesome extension for GDB, to make your life easier.

   • GDB Guide/Cheat sheet

3. Taking Action

   • Do stack buffer overflow is really good for a beginner, because it gives you a vulnerable application and there is also a PDF that guides you through the process. Highly recommended.

   • Security Exercises: It is another great repository to get you started with buffer overflows, shell-code injection, etc.. It also includes a walk-through.

   • Vulnhub: This website has all sorts of vulnerable VMs (including ones designed specifically for Buffer Overflows), which you can download and experiment at your own pace.

---

There is an abundance of tools, guides, VMs and other resources to get you started, and others that can challenge even experienced people. You have to put a lot of effort into this and if something seems a bit unclear, just look for more resources to help you.

If you had access to the source code of an application, then you could just read the source code and see which parts would be vulnerable to a buffer overflow. We usually don't have that and production applications are not compiled with debug symbols (unfortunately). This is where debugging comes in (and reverse-engineering).

You run your executable in a debugger and try to figure things out. Do check the resources I've posted and get ready for a lot of work! And don't give up when things get tough.

Answer 2

To find and write exploits for vulnerabilities such as a buffer overflow require privileged access to attach debugger, restart the crashed process, etc.

Once the exploit is written, it can often be used reliably against remote targets where you do not have any access.

Most bug hunters/exploit writers I know maintain a library of virtual (and or physical) machines setup for bug hunting. They will then install the target application and take full advantage of administrative access including logs and enabling application trace logging as needes. When I run my bug hunting training course I hand out virtual machines with vulnerable software already installed so people can focus all their time on the bug hunting and exploit writing process.