Running a Buffer Overflow Attack - Computerphile

so we'll talk about something very different today very different to my normal image filtering sort of videos that is buffer overflow exploits and what they are and how you do them which is kind of fun I'm you know obviously somewhat of a geek I quite like these sort of things low level memory exploits floo exploit is a situation where we're using some probably a low-level C function or something to write a string or some other variable into a piece of memory that is only a certain length but we're trying to write something in that's longer than that and it bent over rights the later memory addresses and that can cause all kinds of problems the first thing we should talk about probably is roughly what happens in memory with a program when it's run now we're talking about C programs in Linux today just because I happen to have a Linux VM running here and it's easier but this will apply to many different languages many different operating systems so when a program is run by the operating system so we're in some shell and we type in a command line to run a program the operating system will effectively call as a function the main method of your of your code but your actual process your your executable we will be held in memory in a very specific way and it's consistent between different processes so we have a big block of RAM we don't know how big our RAM is because it can be varied but we use something called virtual memory address translation to say that everything in here this is not oxo or not this is the bottom of the memory as it were and up here is oxf F F so this is the equivalent of 1 1 1 1 1 1 1 1 11 address all the way up to 32 or 64 bits and this is naught now when you use this there are certain areas of this memory that are always allocated to certain things so up here we have kernel things so this will be command-line parameters that we've passed our program and environment variables and so on down here we have something called the text that's the actual code of our program the machine instructions that we've compiled get loaded in there now that's read-only because we don't wanna be messing about down there in here we have data so the uninitialized and initialized variables get held here and then we have the heap now the heat may have been mentioned from time to time it's where you allocate large things in your memory big area of memory that you can allocate huge chunks on to do various things ok what you do with that it's a course up to your program and then up here perhaps the most important bit in some ways anyway is the stack now the stack holds the local variables for each of your functions and when you call a new function like let's say you say printf in some some parameters that gets put on the end of a stack so the heap grows in this direction as you add memory and the stack grows in this direction now that I've laid that out we won't talk about it anymore we'll just focus on the stack okay because that's where a lot of these buffer overflows happen you can have overflows in other areas but we're not going to be dealing with them today I'm going to turn this sideways because I think it's just a little bit easier to understand at least that's how I tend to look at it okay so this is our memory again nice and big this is now our stack area excuse my program is writing up here we have four high memory addresses F F dot so something up here is high and this is a X naught naught naught now of course the stack won't be taking up this whole region but it doesn't matter so high memory addresses and low memory addresses and the stack grows downwards so when we add something on to the end of the stack it gets put on this side and then this moves in this direction of course I'm talking about a stack without telling what a stack is professor Brailsford already talked about this and probably done a much better job of explaining it than I would there's a lot of computer science depends on stacks I sometimes think that stacks and trees is just about all computer science is about so we'll just save it you know house that works and then we'll move on we have some program that's calling a function a function is some area of code that does something and then returns back to where it was before so this is our calling function here when the calling function wants to make use of something it adds its parameters but it's passing on to the stack so this will be traveling to a and this will be parameter B and they will be added into the stack in reverse order and then the assembler code for this function will make them accorded call and that will jump to somewhere else in memory and work with these two things and it's the nature of this stack that causes us to have problems let's look at some code and then we'll see how it works I've got myself here a programmer isn't very good I wrote it so it's a these are C codes if we look at it it's just a very simple C code but allocate some memory on the stack and then copies a string into it from the command line okay so up here we've got the main function for C that takes the number of parameters has been given and then appointed to those variables but you've got and they'll be held in the kernel area of our memory we allocate a buffer that's 500 characters long and then we call a function called string copy we will copy our command line parameter from our V into our buffer our function puts on the return address which is for placing the code that we need to go back to once we've done the string copy so that's how main knows where to go after it's finished and then we put on a reference to our the base pointer in our previous function we won't worry about that too much because it's not relevant particularly to this video so this is just going to be our EBP base pointer this is our allocated space for our buffer and it's 500 long if we write into it something that's longer than 500 we're going to go straight past the buffer over this and crucially overall return variable and that's where we point back to something we shouldn't be doing okay so what I'm going to do is is walk through it in the code and then let's see if it works so this is my karlie Linux distribution which has all kinds of slightly dubious password cracking tools and other penetration testing tools it's meant for ethical hacking let's just make that clear I've written here a a small function that does our copy from the command line okay now I've compiled it and I can run it so I can run my vulnerable code with hello and that will copy hello into this buffer and then simply return so nothing happens it's the most boring program ever another program might do something like copy hello in there and then now it's in the buffer they can go off and process it yeah I mean maybe you've got a function that makes things all uppercase so you copy Hello off then you change this new copy to be all uppercase and then you output it to the screen and this doesn't have to be main this could be any function we're going to run something called gdb which is the Linux command line debugger I wouldn't advise using gdb unless you really like seeing a lot of assembly and really doing low-level Linux things I love text on the screen now so we don't to worry about know this text here is just warranty information so now I'm going to type in list and it shows us the code for our function so we can see it's just a compile function now it knows this because the compiler included this information along with the executable now we can also show the machine code for this so we can say disassemble main and we can see the code for main so there the instructions that would actually go to the CPU these are the actual CPU instructions will be run okay now we won't dwell on much of this because assembly is past a whole series of talks by someone other than me Steve Bagley there's a lot about assembler however a couple really important things are this line here sub of Oh X 1 f4 from ESP that's allocating a 500 for the buffer that is we're here and we go 500 in this direction and that's where our buffer goes to buffer sitting to the left on this image but lower in memory than the rest of our variables okay now we can run this program from gdb and if it crashes and we can look at the registers and find out what's happened so we can say run hello and it will start the program and say hello okay and it's exited normally now we can pass something a little bit longer than hello if we pass something that's over 500 then this buffer will go over this base pointer in this return value and break the code so they'll just crash your it should just crash it - for example can produce strings based on simple scripts on the command line so what we do is we say run and then we pass it a Python script of print 41 that's the a character 500 and let's say 6 times okay just a little bit more than 500 so it's going to call somewhat of a problem but not a catastrophe okay and then we run that and it's received a segmentation fault now a segmentation fault is what CPU will send back to you when you're trying to access something in memory you shouldn't be doing ok now that's not actually happened because we over wrote somewhere we shouldn't what's happened is that the return address was half overwritten with these 40 ones so it doesn't know what it is so yeah there is nothing in memory at B 700 for one for one and if there is it doesn't belong to this process it's not allowed so it gets a segmentation fault so if we change this to 508 we're going to bytes further along which means we work now right over writing the entire of our return address we're over writing this ret here with 40 ones now if there was some virus code at 41 41 41 that's a big problem ok so that's where we're going with this all right so we run this and you can see the return address is now 41 41 41 41 now I can actually I can show you the registers and you can see that the instruction pointer is now try pointing at 41 41 so that means that it's read this return value and tried to return to that place in the code and run it and of course it can't now we can have a little bit more fun oK we've broken our code what can do now well what we need to do is change this return value to somewhere where we've got some payload that we're trying to give we're trying to produce okay so luckily if I quit this Jew bugger I have some pre-prepared payload just for this occasion okay now in fact this payload is just a simple very short program in assembler that puts some variables on the stack and then executes a system call to tell it to run a shell okay to run a cup the new command line okay so if I show this code shell code okay this code will depend on the Linux operating system and you know on whether you're using an Intel CPU or something else okay this is just a string of different commands crucially this xcd xat is throwing a system interrupt which means that it's going to run the system call okay that's all we'll go into it about this what this will actually do is run something called zsh which is an old shell which doesn't have a lot of protections involved so let's go back to our debugger and we're going to run again but this time we're going to run and we're going to run a slightly more malicious piece of code we're going to put in our 41 times by 508 and then we're going to put in our shell code there we go okay so now we're doing all 40 ones and then a bunch of malicious code okay now that's actually now too long we've gone too far but we'll fix that in a minute okay and finally the last thing we want to add in is our return address which will customize in a moment to craft an exploit from this what we need to do is remember the fact that string copy is going to copy into our buffer okay so we're going to start here we want to overwrite the memory of this return address with somewhere pointing to our malicious code okay now we can't necessarily know for sure where our malicious code might be stored elsewhere on the disk so we don't worry about that or on memory we want to put it in this buffer so we're going to put some malicious code in here and then we're going to have a return address that points back in to it okay now men we moves around slightly when you move when you run these programs that you know things change slightly environment variables are added and removed things move around so we want to try and hedge our bets and get the rough area but we'll go in in here we put in something called a no op sled or you know there's various other words for it so this is simply /x 90 that is the machine instruction for just move to the next one so that's good anywhere we land in that no op is going to tick along to our malicious code so we have a load of X 90s here then we have our shellcode right that's all malicious payload that runs our shell and then we have the return address right in the right place we have our return address that points back right smack in the middle of these X 90s and what that means is even if he's movable it will still work so it's like having a slope almost as it is exactly like that yes anywhere we land in here it's going to cause a real problem we've got on a bomb or our huddle oh yeah pit of lava yeah it's a sigh Lac pit isn't it right and you know up said takes you in and then you get digested over 10,000 years order for this so we've got three things we need to do we need to put in some X 90 s we need to put in our shell code which I've already got and we need to put an overturn address Y about the return address last okay so if we go back to my code we change the first X for T ones that we're putting in okay we change to 90 so we're putting in a load of no op operations then we've got our shell code and then we've got what will eventually be our return address and we'll put in ten of those because it's just just to have a little bit of padding between our shell code and our stack that's moving about now this 508 here people will notice now this is too big because we're putting in extra information so if we write 508 bytes it goes exactly where we want over our return address but we've now got forty three bites of shell code and we've got 40 bytes of return address so minus 40 minus 43 is 425 we change this 508 to 425 and so now this exploit here what we're looking at is exactly what I hoped it would be here okay a sum X 90 no operation sleds the shell code and then we've got our return address which is ten times four bytes we run this and we've got a segmentation fault which is exactly what we hope we get because I returned rest hasn't been changed yet so now let's look at our memory and work out where turn address should go so in gdb it's paused the program after the segmentation fault so we can say list the registers at about let's say 200 of them at the stack pointer - 550 ok so that's going to be like the beginning of our buffer and what we're seeing here is a load of 90s in a row ok so we just need to pick a memory just right in the middle of them so let's pick this one let's say a B F F F F a BA ok and write that down so I don't forget it ok now there's a nice quirk in this which is the Intel CPUs a little endian which means I have to put it in backwards but it's yet more things we have to learn but it's fine the F F F F a put the caps lock on and can't type when people watching um and BA ok now theoretically when I run this what will happen is string copy will do its thing it will copy a string in and then when it tries to return it will load this return value and execute that instruction which will be somewhere in this buffer and then it will read off and run our shellcode so we should get a shell ok and we did ok so that's a good start right we know our program works albeit in a debugger with very little side effect ok the question now is can I take this and use it on the command line to gain access to this machine now Linux has a Linux has quite restrictive policies on what can and can't be done from certain programs but some programs such as changing your password a run using something called su ID so what that means is that for the sake of running that program you are a complete route you have root access to that machine because I've watched how could you change the password file you're not normally allowed to even read it in the shadow file so if you find a vulnerability in that kind of program and there's more than I think there should be then that's when it's a real problem now obviously these vulnerabilities are getting rarer but it's a catastrophic if you get one ok so let's leave this debugger ok and then back to our nice clear command line environment ok so if I list the files we've got this fundable program here is shown in red that shows that it's su ID boot ok which means when we run it it will be running as root which is not great security now that and my shoddy programming which means it's vulnerable to a buffer overflow okay so if i copy my exploit okay here we go this is a big moment of truth right where this whole video is going to work I've put my code in okay this is just like it wasn't the debugger okay I've tried to make it exactly the same so the memory doesn't move around let's just say Who am I on Linux so we can see I am myself okay I don't have root access so can I for example look at the password file so I can say cat so that except to a slash shadow permission denied no dice okay fair enough I'm not supposed to be looking at that now I want my exploit so MX ik my vulnerability with the right address and we've got a shell Who am I root okay so now can I look at my shadow file so root is like God for this system in Linux there's nothing you can't do it root okay so I've got my moot shell and I'm loop so I can cat slash etc slash shadow and I can see what's in the shadow file but a point is that there's nothing I can't do now I can wipe the machine or do anything like that myself and then I can quit this and then my program does gracefully exits because it's now returns to normal code and hopefully no one has any other wiser but anything's gone on now there are things that the operating system does to try and stop this from happening randomizing your address your memory layout and things like no executing of stacks and stuff there are ways around this they obviously for a different video but at least things are getting definitely better stealth and botnets usually go hand in hand because from the point of view of a C&C server it wants to ensure and some years ago it seems the NSA got a backdoor in one of these routers presumably because they got one of their people to get a job

Channel: Computerphile

Views: 1,604,327

Rating: 4.9593391 out of 5

Keywords: computers, computerphile, computer, science, computer science, mike pound, university of nottingham, buffer overflow attack, hacking, cracking, attacks, exploit

Id: 1S0aBV-Waeo

Length: 17min 30sec (1050 seconds)

Published: Wed Mar 02 2016

Reddit Comments

[u/4rr0ws]

Damnit YouTube, I'm subscribed to this channel, suggest more of this instead of prank videos Thanks for sharing it here

[u/scotty_dont]

Its all going perfect, then right at the end they hide some sensitive info from the shadow file using what looks like a gaussian blur. Given that the presenter specializes in image processing he should be tearing his hair out at how easy it would be to apply a deconvolution and read the obscured text.

Maybe the next video should be on deconvolution.

[u/killerguppy101]

Reminds me if my days reading"smashing the stack for fun and profit" and learning about printf() stack and double free() heap overflows. Some pretty innocuous stuff can provide a huge security hole...

[u/ardme]

Awesome stuff, really interesting seeing the details laid out so clearly and with a live demo even. Definitely interested to see more stuff like this if anyone knows of any.