0

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?

5
  • 4
    get a copy of the application and test locally? – schroeder Jan 23 '20 at 12:17
  • thanks for your answer! I'm new to Pentesting and I'm not experienced at all... is this the common way for checking for buffer overflows? – Soteri Jan 23 '20 at 12:19
  • 3
    @DennisFeldbusch My honest advice for you is to wait a bit with the OSCP until you have more experience and solidly understand the basics of pentesting. It's also cheaper for you than to pay for a certification attempt and then fail. – MechMK1 Jan 23 '20 at 14:16
  • @MechMK1 thank you for your advise. Where and how can I learn those basics and can you name me a forum or so where I can ask those basic stupid questions? – Soteri Jan 23 '20 at 14:42
  • @DennisFeldbusch You can ask your basic questions here, because just because something is basic does not mean it's stupid. Just keep in mind such questions should be answerable too. The DMZ is also a good place, especially if you are not sure how to formulate a question or if that question is a good fit. – MechMK1 Jan 23 '20 at 14:51
5

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.

2
  • Thank you so much!!! – Soteri Jan 23 '20 at 19:03
  • You're welcome. – Soutzikevich Jan 23 '20 at 20:34
0

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.

2
  • So you need privileged access to the target to find and write buffer overflows?? But exactly this I don’t get... I want to find buffer overflows so that I can execute shellcode which allows me to get that access?! If I had that access before why should I try to find the buffer overflow? – Soteri Jan 23 '20 at 16:56
  • 2
    Perhaps you should revisit your training material and see if you can understand the difference between developing an exploit and using an exploit. Only one of these requires the aforementioned privileged access – wireghoul Jan 23 '20 at 21:26

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.