how do hackers exploit buffers that are too small?

The best to write code that is safe is to first break code that is not safe. Today, we'll be taking the code that I wrote for my strings cybersecurity video, and breaking it. By breaking this code, I hope you all get a better understand of how dangerous string functions can lead to a hacker taking over your code and getting control of your system.

🏫 COURSES 🏫

🔥🔥🔥 SOCIALS 🔥🔥🔥

[jamestiotio]

A few additional notes for those who are interested:

- At 3:13, we use `objdump` to find the address of the `debug()` function. Note that this only works for program binaries that are compiled with no ASLR (hence, the `-no-pie` GCC flag). Enabling ASLR will randomize the base address of the executable. However, note that even when ASLR is enabled, it does not mean that the program is invulnerable. Some techniques would allow attackers to leak the base address of the executable and thus, they would still be able to find the address of the `debug()` function by using relative offsets.

- At 4:14, we determine our initial guess for the payload size by looking into the source code for the length of the `password` buffer, which is 64 bytes. This does not mean that compiled programs with no source code available to us are not vulnerable to this attack, assuming that they also use `gets()`. First off, we can reverse engineer and statically analyze the compiled code to find that `64` constant. A much easier method would be to dynamically run the program using `gdb` and inspect its memory during runtime to figure out the length of the payload needed to overwrite the return address. Alternatively, there is also a great library called `pwntools` that can also allow us to figure out the payload length by inputting a de Bruijn sequence.

- This attack can only be performed if there are no stack canaries (hence, the `-fno-stack-protector` GCC flag). However, even with stack canaries enabled, this (again!) does not mean that programs are invulnerable. Some techniques would allow attackers to leak the value of the stack canary, which would render it useless since now, attackers can simply include the stack canary in their payload.

- What if there are no functions like `debug()` in the first place? After all, a real production-grade application would surely have no such tantalizing target functions that allow attackers to drop a shell and execute arbitrary code? Well, even without the `debug()` function being present, as long as attackers are still able to overwrite the stack, they can still perform a technique called return-oriented programming or a return-to-libc attack. The basic idea would be to "return" to and jump around between snippets of code in other functions of the binary or even in library functions (such as in `libc`). These code snippets are called "gadgets". With a sufficiently large library such as `libc` (which is definitely used by many applications worldwide), return-oriented programming is Turing-complete. Hence, attackers can eventually do whatever they want, including dropping a shell and executing arbitrary code.

The lesson to learn here is that mitigations can be bypassed and they should not be considered silver bullets in production-grade applications. Buffer overflow is also generally considered the simplest class of vulnerabilities (there are more involved ones such as double-free attacks, race condition attacks, and side-channel attacks). Try to avoid having buffer overflow vulnerabilities in the first place at all costs by reviewing your code and by using tools that could analyze your code and detect such vulnerabilities (either statically or dynamically). That is the only way to make your code truly more secure!

[anisoptera]

the biggest vuln in your server is that your service says the words "welcome to" in its announcement banner, and nothing about unauthorized access being prohibited, thus ensuring that anyone who breaks in cannot be prosecuted under the precedented legal defense "It literally welcomed me in, therefore my access was not prohibited"

[ash__borne]

In the end it's not necessarily about being a genius, it is about understanding how it works..

[prxythegodofhax]

keep uploading more exploit dev / binary exp videos bro, great job

[bazoo]

OK, this was, obviously, way oversimplified, with much more info available to us than would be to a typical attacker, but still it illustrates the principle of buffer overrun exploit, the most common of them all, very nicely.

[GingerBeker]

echo "Perfect video; Amazing Content; No Waste Time; Sponsor at the end, that i see entirely for respect and becouse doesn't ruin nothing; = Great Job; More More More!!!"

[metal]

Great demonstration! In fact, there is yet another vuln in this code introduced purely by using the system() function at all. You can read why system() is discouraged in programs that run as any privileged user on the manpage for that Linux C function under the Notes section.

[kinoko_b]

Plese make more videos like this! As someone who didn't understand this kinda stuff well I was able to (kind of) understand how a buffer overflow works! I plan to to take cybersecurity as like a hobby in the future so your videos are really nice

[psychicpenguin]

This is my favourite channel about programming. Thanks a lot mate!

[victorbjorklund]

Wow :) very good desc of how a buffer exploit works. I knew the theory but great to see how it actually works in practice.

[marcusaurelius]

Another vuln is that your password check function assumes it is a character, and dosent expect anything else. This will cause a vulnerability. People write code assuming the user will do as intended. If the user writes anything else that is not intended, have a check for that, if the user writes something larger than what is allocated, expect that, and have a response for it.

[cristober]

though i knew most of what was said in the video, it was still really well made and i enjoyed it regardless, good job :D

[joltedjon]

I like how you release this video after I had a project in my computer security class on performing buffer overflow attacks

[torphedo]

Thought you were John Hammond for a little bit and I was like "wow, he looks so different cleanshaven!"

[yusinwu]

Glad that your channel got a sponsor! Thanks for the content

[sikkavilla]

I would recommend cyclic the command to find the location of where to put in the instruction pointer

[mochou_p]

"2" instead of "too" in the password would have been even cooler

[osamaaj]

Found this channel by pure chance and I'm glad I did!

[therats]

Not into C at all but very educational and well explained. Thank you

[linonator]

Well, this video just made me turn all notifications from this channel to on. Great vid