x64 Linux Binary Exploitation Training

so welcome everybody to the session on linux binary exploitation so this is the plan for today we will begin by discussing some simple buffer overflow on 64-bit architecture we will begin by disabling all exploit mitigation protections like nx stack canary aslr pie and all that if you are hearing these terms for the first time there is no problem i will explain all of this what nx is how it uh prevents buffer overflows and what canaries are how they prevent buffer overflows uh how what aslr is and what pies and all that so once we are done with a simple stack based buffer overflow we will get into return to libsy and return oriented programming so that's to bypass nx or non-executable stack and once that is done we are going to see another technique called return to plt which is going to bypass both nx as well as aslr but we will still have to disable pie position independent executable for this particular case and once that is done we are going to get into format string vulnerabilities you you might have probably read about format string vulnerabilities in general on the on different blogs or in videos and all that but in this particular training specifically we are going to make use of format string vulnerabilities to bypass some restrictions like nx aslr and all that uh and exploit buffer overflow so essentially what that means to us is we are going to chain format string vulnerabilities and buffer overflow vulnerabilities together and we are going to uh write our writers write some exploits so so specifically we are going to use format string vulnerabilities to bypass stack canaries that's one exercise and once that is done we are going to enable all the protections i mean we just compile the program just like a standard developer we won't be using uh any additional flags to disable any protections and then we will write and exploit from scratch so that's the end of that's going to be the end of the training now obviously as you can already sense it's going to be very very complex and it's going to be too long i'm i'm re i really want to cover all of these topics within four hours but obviously you will have to pay a lot of attention as well because if you miss something i think it will just go above your head now this is the plan in terms of the time we will try to finish we will try to take a break about like after two hours and before the first break before the break i mean there could be only one break uh if you want we can take some short breaks like 10 minute breaks in between as well but but the original plan is to have one break after completing simple buffer overflows return to libsy and return return oriented programming and return to plt once these concepts are completed we will take a short break like 15 to 20 minutes and after that we will begin with format string vulnerabilities and leaking memory addresses and then some other things like chaining formatting vulnerabilities and buffer overflows so that's uh so that's the plan i think we can get started so before we uh get into writing simple buffer overflows buffer overflow exploits i have about two slides to cover the registers because if you are from 32-bit background you may have probably seen these registers here like eax ebx ecx edx there as you can see they are 32-bit registers now in 64-bit in 64-bit processors we have more registers than what you might have seen in 32-bit registers rx rbx rcx rdx rsi rdi rbp and rsp these are the general purpose registers that you can it that you can easily compare with the 32-bit registers that you might that you might have already seen but in 64-bit there is there are few more additional registers that you can use here they are these registers were not available in 32-bit processes so uh r82 r15 are the new registers that were introduced in 64-bit intel processors right so if you go back to the previous slide if you take rx register it can hold uh 64 bits of data and you can still access the 32 bit register using eax and within eax just like your 32-bit processor you can further access the 16 bits using the ax register and you can also use these eight bits these eight bit registers as well like ah and al now there are few registers where you can't access these higher eight bits if you see this rsi you can't access that similarly rdi rbp and rsp now if you are from 32 bit background you might have probably i mean if you have written some simple buffer of exploits you might have probably seen eip register and esp register eip is the extended instruction pointer which is always going to point to the next instruction to be executed in 64-bit processors that register is rip so we always want to get control on rip register whenever we write exploits now the stack pointer here is rsp so typically when we write exploits these are the two registers we are going to deal with remember we also need this rbp register the base pointer which is going to act as a trim pole in because there are few reasons you need to know about this rbp register as well i mean you don't need to know a lot of details about rbp register at this point of time but when we get when we try to get control on this rip register in 64-bit exploit development we will usually get control on rbp first and then we will try to achieve control on rap it it kind of uh doesn't make sense at this point of time but when we write uh buffer overflow exploits you will understand this yeah uh apart from that i think uh that's all you probably need to know before we write 64-bit exploit 64-bit exploits buffer of like exploits yeah so as in when uh we come across any new topics that are not covered in 32-bit exploit development i will try to cover them but otherwise i think we can get started with the exploit development concepts i don't want to spend time on how to write simple assembly programs and all that so i would like to simply get into the stack based buffer overflow exploits so this is the vm that you all have i hope you have it um guys can you please say yes if you are able to see my vm all right okay cool do you also have the vm with you now okay okay so if you see if you see the current working directory after getting a terminal you should see something like this i have changed all the settings for you to have better font size and all that so you probably not you may not have all these files i i think i have just deleted all of them when i'm giving when i was giving this vm to you but this is my original copy of the vm so within this we have a directory called backup and within this you will have all these binaries and exploits that we are going to use today so obviously if i'm just using the same directory i will be just uh running the exploits and i'll be just showing them to you rather i will go with a new directory and i will recreate everything there so let's call it x64 training and let me also navigate to this simple buffer overflow and let's just copy the vulnerable binary vulnerable program from here okay so this is going to be my this is going to be my current working directory throughout this uh simple buffer overflow demo now if you have already completed the challenge that we have given before the training that the pre-training challenge uh this this particular exploit is going to be the same but for 64-bit architecture surely there are some differences that you will notice shortly but but the concept is same i think it's the same vulnerable binary that i have given to you if you notice this but we are going to recreate the exploit on a 64-bit machine now we this is the vulnerable vulnerable c program now we also have a make file i'll just copy that you don't have to do all of this i think it's going to take a lot of time if you do this so i'm just going to do this for use and you can just concentrate on the demos okay so if you notice the make file we are disabling the stack canary by using this flag if no stack protector and we are also disabling the nx bit by using dash z exec stack and i think you can ignore this for now because uh we're not going to deal with that now if you want to compile this program we can just type make and if you type ls you should see a new binary here and this is the binary we are going to deal with now there is an additional step that we have to do before we get started with writing this exploit so we if you notice we have disabled exec stack which is stack that means the stack becomes executable um and then um i mean we have enabled extract flag which which means the flat the stack becomes executable and there is one more protection here which is stack canary we have disabled that so we have disabled two protections so far and we are also going to disable aslr for aslr i have instead of disabling aslr manually every time i have written some helper scripts so what we are going to do is we will navigate to aslr directory here and here you can actually run these scripts to verify or disable or enable aslr to get started let's verify aslr if the value is 2 it's enabled so let's disable it let's verify it once again and there you go you can actually take a look at the contents of these files to see what what's actually being done inside we are just writing the value into this particular file okay so we have also disabled aslr right so we have disabled all the exploit mitigation protections uh nx stack canary and aslr we will enable them one by one later but for now i think we should just get started with this now just like how you have done earlier in the 32-bit challenge we are going to crash this program by using some large buffer and then we are going to try to identify uh the offset that is required to overwrite rip register because rip is something like eip in 32-bit okay so once again i will just copy the template from here instead of writing that i'll just copy the template and i'll build on that okay so this is the template that we are going to use here okay i think i'll also disable the pie which is by using the flag dash no pie you have to d you have to bear with me for now i mean with all these flags later in the last demo of the training we are just going to compile the program using this particular command so that means we are not going to use any of these flags later for now to understand the concepts better i think we should disable them now let's start crashing the application if you notice the vulnerable binary has an strcpy function which is taking input and this input is actually coming from here and this is the argument to the program so what that means is we can execute the program like this and this is going to be the buffer that is going to crash the program so instead of manually typing these a's we are just going to use this perl script there is a reason why i'm using perl here because uh earlier i was using python for most of my templates and exploit scripts but when they switched to python 3 i think some of the concepts were i was not so comfortable with python 3 and some of the concepts were not so clear so my exploits were requiring some modifications so i thought it's a good idea to move to python 3. move to perl but later i had to use something called pawn tools which we are going to discuss today at the end of the session and when i when i was using pawn tools i still have to use python 3 so it was not leaving me so today most of the exploits that we are writing are going to be in perl but at the end of the session we are going to use python 3 when we specifically use spawn tools okay so as you can see this is a simple perl script this is the shebang and we have this line this is just to i think this is just to process the buffer something like that let me just explain that i'll get back to that i think that forces are flush after every write or print so that's the reason we are using this uh i think it just saves some time and we are using a variable called junk which is having 300 300 s so if you notice the buffer that we have here in the vulnerable program it's uh it's just 256 characters so we are we are just trying to write 300 days so it's going to cause a crash so there is uh let's produce the payload using this exploit one dot pm let me just change the permissions i'm i'm assuming that you're understanding uh whatever i'm discussing here but if you don't understand why i'm doing a specific step i think you can stop me and you can ask me in the chat feel free to post your questions in the chat if you if you don't understand a specific step that i'm doing here okay so we have made it executable and let's produce a file called payload one so all the 300 s should be available in this file you can quickly check that by using the hex editor xxt space payload 1 and if you see all the 300 s are available here okay now let's try vulnerable cat payload one so basically we are just passing those 300 a's to this vulnerable program as its first argument as you have seen this is going to be copied using strcpy function into a buffer of 256 bytes so this is going to cause a crash let's hit enter look at that there is a segmentation fault now if you type ls even though there is a segmentation fault there are no core files generated in the current directory so you can do you limit dash c unlimited and if you try to cause the crash once again and if you check the available files in the current directory there should be a core file so core file is uh something like your black box when when there is a flight crash you want to know what happened at the time of the crash so typically people go and look for these black box right so similarly if you have the core file you can understand what happened at the time of the crash so i'm going to use gdb dash core we are going to debug the actual binary in a in a moment but let me just quickly show you how to use the core file dash core and the actual name of the file which is core and hit that hit enter and if you notice uh if you have never seen this jeff shell and if you are seeing it for the first time jeff is a plug-in for gdb it is going to make our life very very easy i'm not going to use plain gdb i'm going to use jeff for almost not almost i think pretty much everything in this co in this training so we are going to use jeff jeff i think it stands for gdp enhanced framework or something like that you can search for it online now all a lot of commands that you typically type within gdb can be i mean without without typing them you can basically see those outputs using jeff for instance uh if you want to see the stack if you want to examine the stack you can you can just run the binary and you will be able to see the stack on the screen it's like ui you will have a lot of details in front of you if you are using jeff so as you continue with the training you will understand how and why i use jeff okay so if you notice there there seems to be a crash here at this address so when this address was triggered the application was unable to understand where to go and the crash happened typically if you are on a 32-bit machine you you would be seeing 41 41 4141 which are which are the a's that that have caused the crash right but this is what happens on a 64-bit machine you won't be seeing that by default so i'll i'll explain in a moment why that is now let's try to examine the registers we can use info registers to do that there is a typo there okay look at that if you notice rip register is containing this value which is what exactly we have seen here which is causing the crash but if you see this rbp register it has our 41 4141 which is uh some text from the 300 s so this is what is uh so this is a confirmation that our buffer has caused the crash but this is still unclear why rip doesn't contain uh these 41s or a's right we will solve that mystery in a moment but but for now uh our buffer of 300 is has caused the crash all right so basically this is what you can do with the core file you can you can do much more than this obviously but i won't be i won't be using the core file but i just wanted to give you a basic introduction to core files so let me just quit here and let's directly run the binary using gdb i am using gdb dot slash vulnerable that's the binary dash queue so that it will run in quite mode it doesn't show a lot of information on the screen for me and yep i think that's pretty much it there it is now the binary is loaded using gdb now if you see this binary the vulnerable program it has a main function and within which we have all the other code so typically when we debug using gdb we want to set up a breakpoint at main and we can proceed from there now if you notice this program requires as you have seen earlier this program requires an argument which is going to be the large payload that we are supplying so when you run this program using gdp you can actually pass the payload like this so the payload one is from your local system which is containing the 300 s and we are just passing this as an argument to the binary and we are just running it using gdb so let's hit enter and let's quickly examine the registers once again so far nothing happened because there is a breakpoint at main it it hasn't executed the strcpy function yet but but the idea here is to see the ui or the output of jeff shell output of jeff if you notice currently we are seeing registers if you are just using plain jdb i think every time you want to see the registers you will have to run these commands otherwise you will have to do some sort of basic gdb scripting now if i am using jeff you can basically see the registers every time and you can also see the flags if you see this these are the flags so you can see which flag is set and which flag is not and you can see the stack here this is the stack and these are the instructions being executed in the binary if you see we are currently at main plus 0 and rip should be pointing to this address let's check that here it is the rip register is pointing to the address ending with 5149 address ending with 5149 so that's basically jeff we are going to use jeff a lot and i think it will be clear by the time we end this training now let's uh disassemble main by using the command disas main and we can see there is a strcpy function i think there is a one function within which we have strcpy so we can probably run disassemble one function and this is what is going to be causing the buffer overflow right so once this buffer overflow happens what happens is this return address uh is going to be overwritten i mean so once the strcpy function is called it is going to uh it is it is going to cause the buffer overflow and this one function has to return to the main function but because of the buffer overflow this return address will be overwritten and you will get control on the rap register so that's what is the buffer overflow here now what i'll do is i'll probably set up a break point here at the red instruction by using b space the address notice the star here and let's continue with the execution and see what happens i'm typing c to continue with the execution just in case if you didn't notice so if you notice the stack has now our buffer the buffer is placed on the stack and if you see there are few registers which are holding the value of these s r 9 r b p r c x and r rip still doesn't contain what we are expecting if you want to know the offset to rip obviously you should be able to overwrite the rip register right so but unfortunately we are unable to overwrite our ap register so any idea how we can get there how do we get the offset to rip register you can post your answers in the chat so the question is we have supplied 300 s clearly we are able to overwrite rbp register but we don't have control on rip register and if you don't have control on rip register obviously you can't exploit the buffer overflow sachin grover says increase the number of s actually sachin it's not needed because we have already enough is but i can i can do that i can show you but we already have enough s we are already overwriting rbp register here but let me show you since you asked for it let's copy exploit one to which memory location the rip [Music] i mean your idea of exploiting the buffer overflow is correct but currently we don't have control on rap to jump to a specific address first you have to be on the rip register you need to have control and rip register so currently if you notice if you remember what i was showing you earlier our a's are overwriting a rbp register but our a's are not overwriting our ip register so to come to the point of what you are explaining i think we first need to overwrite our ip register but we don't have that control so yes yeah so you're saying 300 a's are not enough probably we can increase the number of a's so this is the first problem with 64-bit exploitation okay so let's probably make it 350 will that be sufficient do you think i think it's 300 is good enough but uh just to uh follow what just what you're trying to say i'm just closing increasing this to 350 payload 2 and gdb um the reason the reason why i am also asking you not to do all these things because i'm going to do it multiple times for example if you currently don't know how to load a binary probably you will see it 100 times today so by the time you finish the training you will know how to load the binary how to set up breakpoints and all that so let's uh once again go to disas volume function because we want to have a breakpoint at the red address which is this there is a small typo in the make file i'll fix that later but for now i think we can set up a breakpoint at main first and let's run the binary using the payload 2 which is having 350 ace and run the binary we are done and let's set up a breakpoint at the red address which is this and if you want to execute system commands from the gdp shell you can use the shebang or shell so for instance for instance if you want to clear the screen shell space clear that will clear the screen or you can also use like this the exclamation mark and clear this will also execute system commands okay now let's continue with the execution and we should have 350 a's and you still have control on rbp register but there is no control on rip register any other guesses or any other ideas how we can why or how anything is fine just your thoughts or ideas doesn't need to be correct i don't mind that's why we are here it's you know it's very hard to teach to my screen if you're not responding okay um okay so that's a limitation of 64-bit uh processors there is a reason which i'll explain now let's type via map it shows you the watch it it shows the virtual memory map of this process you can see vulnerable and you have lipsy loaded here once again don't get confused don't worry if you don't understand these outputs and all that we are going to deal with all these things multiple times so you will understand them and this is the dynamic linker and we have stack here now if you notice the starting addresses of all these entries in the memory map except for the last one which is associated with the kernel all of them are having only 48 bits out of 64 bits the remaining higher eight sixty format 64-48 let me so if you see this there are first uh first four uh zeros in every address here in almost all the addresses not almost it's it's in all the addresses we have four zeros at the higher addresses and the only the rest of the 48 bits are used so this is a 64-bit processors so basically in 64-bit processors the memory addresses are like this let me go back to my slides so they call it canonical address they call it canonical addressing and what it means is when you're addressing a memory when you are addressing memory you can use only these addresses if you notice starting from this address until this address but when we are trying to overwrite rip we are basically using 41 here 41 here and uh six more 41 so basically we are using 8 41s that's the reason why we are and it's not able to uh it's not able to show what rap contains so what what it what it actually means is you cannot have eight bytes of addresses i mean you cannot have all the 64-bit all the 64 bits on the addressing so when you are addressing a memory address you only can have these lower 48 bits you can't have eight s you can only have six a's so that's what it means so the non-canonical and the non-canonical addresses i think are only used by kernel but for the user space these are the this is the address range we can use and that's the reason why the memory map shows only these addresses so if you go back give me a moment please so yeah uh here we are so so basically what that means is we cannot override rap register with eight eight bytes we can only use six bytes and that should give us the control because we need to uh use proper memory addresses that's what i mean so let's try uh updating the exploit two with something uh that that over uh with some buffer that overrides only six bytes of rap but even for that we need to know the offset right so if you want to overwrite only six a's into the rip register you need to know exactly how many bytes of junkies required to reach the rap register for that we can use rbp register as our intermediate register and so that basically we will find out the offset to rbp register and from there we can add 6 bytes to reach our ap register so what that means is let's try to once again load gdp vulnerable and let's set up a breakpoint at main and let's run the program instead without before running this let's probably use some offset this time because i i assume all of you know pattern offset pattern create and all that so i'm just going to use some random pattern instead of using 300 ace this time so for that what we can do is we can use uh instead of using metasploit we that's what we are habituated to do when we learn when we learn buffer overflows in oscp and all that in jeff you have this feature called pattern create we can use pattern create to create 300 uh a pattern of 300 bytes so we have just i'm just copying this and let's go back to x86 training okay let's update the exploit two dot pl so instead of 350 s we are just going to pass the pattern that we have just produced okay so that's the pattern let's save yep uh you mean this pattern we don't know yet if there is any bad character usually it won't be copied typically it won't contain bad characters i guess but but but if you but uh but to answer your question if it contains any bad characters obviously the full buffer won't be copied um uh through the payload yeah so let's assume that it doesn't contain any bad characters in this case it doesn't contain any bad characters because for str cpy null bytes are the bad characters so the moment it encounters null bytes the pat the exploit will be the payload will be terminated there um typically it depends on the vulnerable program for instance in our case the vulnerable program is using strcpy so null byte is one of the bad character similarly if it has more more checks for the incoming data probably that becomes a bad character if you take gets vulnerable function as a as an example uh it zero zero or null byte is not a bad character for gets it it can still uh take the input even if you have a bad even if you have a null byte but if your input has a new line character the the exploit will terminate there because uh gets uh will stop reading the input the moment it encounters a new line so depending on the vulnerable program you you will have to find out the bad characters by passing all the hex values onto the target vulnerable program i think in this particular training we have very less amount of time to cover how to identify the bad characters the assumption is that you know how to identify the bad characters anyway we are not going to deal with too many bad characters in this training we are for us it's only null byte in this particular program in the i'll move on to another binary later in that only a new line character is a vulnerable i mean bad character yeah so to answer your question directly this this buffer doesn't have any bad characters so yeah so let's produce the payload exploit 2.pl and let's call it payload 2 once again now let's run the binary using the new payload so this payload contains uh this particular pattern that we have just produced we run the program now let's once again go to one underscore function and let's set up a breakpoint at the red address okay so once that is done we can continue with the execution you can either type continue or you can just type c so if you notice we have continued with the execution and we are about to execute the red instruction under wall underscore func now if you notice the rbp register it's overwritten with some pattern but still rip register is not overwritten because after rbp you can only pass six characters you can't you can't pass eight characters because that's an invalid address in 64-bit because that's what i was trying to explain if you see this the four uh the first four characters are zeros right so the first two bytes are zeros here you can't have uh forty ones there now you need to find out the offset to this rbp address because rap gets overwritten immediately after rbp so if we know the offset to rbp we can actually calculate manually to rip now let's go back to the previous terminal once again or let's probably use clear pattern such this is uh this is the command to find out the offset so i'm just searching for this particular pattern and if you notice 256 is the offset to overwrite rbp now let's update the exploit so the moment we update the expert you will get get a picture of what we are trying to do here so let's just open exploit three dot pl and let's remove this variable junk and let's give it 256 is which is which is uh sorry it's uh it should be a here and since i'm talking and typing i'm making some weird mistakes please excuse me for that okay so we have 256 this is the offset to rbp register and we have next we have rbp register remember the six bytes condition is applicable only for memory addresses rbp is just a register we are not using it as a memory address so we can still use eight bytes here so i'm just using eight b's and next is what is going to be our rip register if you remember rap register has to be it cannot be eight bits it cannot be eight bytes it can only be six bytes so we are going to use six c's and that should give us control on rap with these six c's so 256 is the offset to reach rbp register so using these eight base we are overwriting rbp register and after that these six c's should contain uh i mean should be used to overwrite our rip register so let's copy let's save this file and let's produce exploit three dot pl and let's save it as payload three i mean we are producing the payload from exploit three dot pl and we are saving it as payload three and let's uh probably run this once again using payload three so whatever the break points that you have set earlier will still be relevant we are just rerunning the program using a different payload so we don't have to load the binary once again i am just hitting enter and if you notice this time we are still at the main so let's continue with the execution to see if the to see if we got control on our ip register look at that we have rip i mean the six c's uh on the top of the stack and the next instruction to be executed is read when you execute read instruction behind the scenes pop rip will be executed what that means is the top the value on the top of the stack will be popped into rip so currently if you see we have eight base in rbp that is expected and six c's on the top of the stack that is also expected so if you do a single step we should have these 6 c's in rip register let's check that so i'm just typing si which is a single step to execute one instruction so that is going to execute this red red instruction so i am hitting enter there it is if you notice we now have control on rip register is that clear so the reason why we are doing this way is in 64-bit architecture the usable address space is limited which is called as canonical address space now attempting to use non at non canonical addresses will cause a segmentation fault because they are only used by the kernel and we have been noticing segmentation falls earlier because of the fact that we were overwriting rip with a non-canonical address right and uh yeah that's pretty much it so we we managed to use a canonical address i mean an address which is in canonical address range and we managed to overwrite our ap register if this is clear i think we can now we we now have control and rip now all we have to do is we will just have to place some shell code in the buffer and then redirect the execution just like your 32-bit exploit let's do that i'm just quitting it here and let's say exploit three dot pl as exploit 4 dot pl the numbers that i am using here like exploit 1 exploit 2 could be different in your vm i mean in the exploits that have earlier written because i'm not checking the file names of the older exploits i'm just rewriting them here so what's wrong here okay so let's move exploit for dot pl to exploit for dot pl there is a typo there okay and let's use this exploit for 4.4.pl to place some shell code in the beginning and we can also redirect the address of this we can uh override this six c's with the address of the shell code so that's the next step i'm just going to quickly do that uh try to try to try to pay some attention here how i find out the address of shell code and how i overwrite uh the address of the rip register and all that okay so let's create a new variable here called shellcode and we can actually get shellcode from the internet or we can write our own shell code in the vm that i have provided i have written some custom shell code let me just navigate to that directory there is a directory called shellcode there is exit shell code that is execution code and there is a reverse dissipation code um we are not going to cover how to write shell code in this training but yeah if you if you understand how shell code can be written i think you can just you can just take a look at these files and you will have a custom shell code written from scratch now what i am interested in is the execute shell code which is exec v2 here this is the shell code that i have written but if you want to use the shell code from the internet you can feel free to do that now one thing that we need to do is extract shell code from object dump so i'm just going to use a one liner from the internet to extract the shell code so i'm just copying this command here because the binary it's a binary which is compiled and linked and we need to extract the actual shell code from this binary so i'm just using this one liner from here and i'll just use these uh as i said this is this is in your vm as well you can basically follow the same steps to extract the shell code so i'm just using uh object dump and some linux linux kung fu like cut do echo and all that and hitting enter and we got the shell code we can basically use this shell code if you want to use chain code from the internet you can feel free to do that but sometimes they may contain bad characters and it may fail so it's suggest i have already tested the shell code that i have written so i think it's it's recommended to use this particular shell code but wait actually this shell code has some bad character here which is a null byte let me check why that is i think we can use this one this doesn't have null byte yeah i think we can use this yeah let's copy this if it doesn't work i'll probably use something from the internet just in case but i'm hoping that it will work i have tested it earlier but i can't recall which one is the exact file all right so we can now also place some knobsled at the beginning i'll show you the pictorial representation of the exploit in a moment don't worry you will understand that so let's use slash x 90 and we can probably use about 30 knobs obviously we will have to uh sub subtract that length from this a's so we are going to use 256 minus length of shell code minus length of knobsled okay so this should produce the payload properly and we will finally have to replace these 6cs with the address of this knob slide okay so let's save the file i hope everything is correct if you see any there seems to be a typo here the length if you see any mistakes please let me know because usually silly mistakes are hard to troubleshoot like this okay so hopefully this should work i'm just producing exploit 4 dot pl i mean i'm producing payload for using the exploit four dot pl file and let's quickly check if it has everything okay so that's the that's that's the reason why i usually check using this hex editor if you notice there is no knob sled and there is no shell code because we did not print them so let's use exploit four dot here if you notice we have all the variables set in the exploit but we are not printing them so we will have to first print the knob sled and we will have to append the shell code and finally junk okay so that should fix the problem let's save the file and let's produce the payload once again and let's use hex editor and this time hopefully it's all good let's clean the screen and let's use gdb dash queue dot vulnerable so dash cube basically doesn't put a lot of information here that's why i use dash queue and let's use breakpoint main and let's run the binary using payload for if you notice i'm first setting a breakpoint at main and then i'm running the binary using the payload after that i'm setting up a breakpoint at the red instruction of one function there is a reason for that because this binary has pie you can't directly set up a breakpoint on addresses within the functions before starting the binary if you want to do that you need to disable pi i'm not sure if it is clear but uh follow the process for now uh for this but for this particular binary just set up a breakpoint at main run the binary using the payload after the binary is run set up set up a breakpoint at red instruction of one function okay so let's run the binary now let's find out the address of red instruction here now set up a breakpoint the binary is already started now we are setting up a breakpoint okay so let's continue with the execution and if you see we still have 40 to 40 to 42 in rbp and we have uh these c's to be executed i mean these two these uh six c is to be popped into our ap now let's type si and this is what is going to be the condition when we when we redirect the control onto the shell code right now we want to we want to find out the address of the shell code let's quickly examine the stack i'm using x slash gx 50 gx usually in 32-bit exploit development you probably use x slash 50x right let's let's let me show you what happens if you do that and rsp is the top of the stack and if you remember we placed about 300 a's on the stack so i want to use rsp minus somewhere around 280 or 290 so if you do this you are still seeing uh 32-bit format so to see it in 64-bit format we will have to use 50 gx look at this look at that you are seeing it in a 64-bit format now if you notice this is where our knob slide is so we have used 280 here let's reduce slightly let's probably use 276 270 yeah i think we can use i think we can use this address because this particular address is currently pointing to the knobsled so if you can replace the address of if you can if you can overwrite rap with this address the control will be redirected to this knob sled followed by the shell code and the shell code gets executed there are some questions i think oh is anybody in the waiting room oh yeah yeah i have found him it's arunaya right yep okay i accepted it all right so hi welcome aaron okay so if you see this this is uh this is where the knob sled is so we can we can basically use this address we can copy this address and let me open sublime text and can you please go on mute if you are not speaking i am hearing myself yeah thanks so we can probably leave this terminal here and let's use exploit four and let's save it as exploit five dot pl actually it already took one and a half hours to cover this simple one i highly suspect that we can cover all that all the topics but i'll try my best okay so we will have to replace this junk uh with this address right so let's copy this and you will have to convert this into little indian format uh so basically you will like you do in um x uh i mean 32-bit uh explore development you will have to write the address in this format slash 12 slash x12 slash xdd basically you will have to reverse these bytes instead i'm just going to use a pearl function called struct dot pack i'm just going it's not struck.back i'm just going to use pack i think it's in python we'll have to use the struct module and we will have to use uppercase q for bit addresses and we will just pass this address so this function will automatically convert this address into little indian format for us you will you don't have to do anything so this is going to be the address of rap okay so that should uh redirect the execution to the shell code hopefully so let's try this i'm just saving the file exploit five dot pl and let's i mean i'm just producing the payload and saving it as payload.payload5 and there it is let's quickly check payload5 seems fine now let's run the binary outside gdb vulnerable cat payload 5 let's hit enter looks like there is a segmentation fault the exploit did not work let's remove the core file and let's try it once again just to make sure that we have a fresh core file um there is no code file produced here let's try ulimate dash c unlimited yep there is a core file so now now let's examine why the exploit failed i'm using gdb dash core and i'm loading the code file and if you notice this address is same as what we have copied earlier so i'm just copying this address just to compare seems like it's a different address not sure why let's check so i'm just going to use the 50 gx rsp minus 276 the same thing that we have used earlier 270. yeah if you notice the addresses outside gdb are slightly different than the the knobsled earlier was actually here at this address but outside gdb it's slightly different so this is the reason why this is also another reason why core files are very useful so we can just try to copy this address now and let's try to update the exploit let's use a different address this time okay hopefully it should work let's produce the payload i think instead of pressing the arrow button i think it's easier to type it but let's execute it look at that the shell got we got a execuv bin shell and you can execute commands so that's uh how we can exploit simple stack based buffer or flow vulnerabilities in 64-bit systems let me just quickly show you some slides so here we have some junk and our goal is to overwrite our ap register i'm just giving a quick recap with a pictorial representation and we we kept some padding here and we placed some shell code in the beginning and we overwrote the rip register with some address that points to the shell code but just to give some room for error we placed some knob slid in the beginning instead of directly placing the shell code and we managed to redirect the execution to this knobsled and once the execution lands on the knobsled it it slowly uh redirects to shell code and shell code gets executed right so that's what we have seen so far there are some more things that we can do you can actually find out if there are any registers that are pointing to the knob slit and so this is the this is that let's assume that rx register is pointing to the knobsled you can actually see that rax register in this case will be pointing to knobsled i'll show it uh in a moment yeah so if rx register is pointing to your knob sled what you can do is instead of hard coding the address that we have gotten uh if you if you noticed the address was working uh the address was different within gdb and outside gdb right to avoid such problems this technique actually helps you can find out the address of jump rax instruction i think this is pretty popular technique uh if you when you learn windows explorer development they show you how to do jump rsp uh you usually search for jump rsp in mona dot pi or i mean the the mona plugin use in the immunity debugger and you will place the shell code immediately after eip that's i think the next slide if you see this you usually find out jump rsp in this case and you just place the jump rsp address here here and place the shell code on the top of the stack which is immediately after the rip address and then you just point your execution to the shell code by just i mean the moment you use jump rsp address here it obviously points to the top of the stack where your shell code is there so that's the jump rsp technique but in jump rax technique the rx register must be pointing to your shell code or the knob sled so when you overwrite rip register you will place an address that's uh the address of i mean you will place an address that is having the instruction jump rax so the moment rip gets executed it will basically execute jump rx so it will the control will be jumped to this knob sled now where can you find these addresses like that contains the instructions jump rax jump rsp and all that if you are from win32 explorer development background i think you can find them in dlls or within the binary right same same goes here you can find these addresses within the binary itself or you can use libsy library here libsy library gets loaded into almost every binary that use in linux so you can use libsy library so you will find these addresses there i'm going to show you return oriented programming shortly where i'm going to show how you can search for these addresses within libc library so that's pretty much it for the with the simple stack based buffer overflow exploit if you have any questions uh please let me know otherwise i will move on to the next topic where we are going to bypass nx can you please show the poc again okay sure this is a pocket now the question is if i use jump rsp technique will that work so currently we are having the shell code in the beginning of a buffer and we are just redirecting the execution to the beginning of the buffer will this technique i mean if you use jump rsp technique will that work so what it means is if you are using jump rsp technique you will have to place the shell code immediately after this rip register any idea look at the payload that we have used payload five if you see this we have knobsled and we have shell code and we have a bunch of a's and we have a bunch of b's and finally we have the address if you notice one two three four five six six bytes and then we have two null bytes so the moment uh you attempt to place a shell code after this the shell code won't be copied onto the stack that's the reason why i'm placing the shell code in the beginning so in this case if you try to attempt an exploit technique like jump rsp it's going to fail yeah so dazzy says possible only if there is enough space for the shell code after the rap override let's assume that there is enough space and we are using strcpy yeah that's right the i think dharmendra says i think it's not possible since the rap address will be overwritten with some junk in that case yeah if you remember we have that problem right we were unable to overwrite more than six bytes after rbp so if you try to place a shell code after that i think it's going to fail now that's where i'm going to stop using this binary we are just going to cheat here a bit i want to use a binary that allows us to place a shell code after rip i'm not going to show you this simple buffer overflow again but for the rest of the examples i will simply replace strcpy with gets function that's the only difference the rest uh the buffer the length everything is going to be the same in fact even if you change the binaries uh function from str cpy to gets the same exploit is still going to work so let me just go back here and let's go to simple buffer overflow so i have jump rx jump rsp exploits also available here but i'm not going to discuss them in this training because i think it's not it's not required here because we don't have enough time as well okay if you notice i just replaced strcpy with gets function that's the only difference rest is basically the same so i'm just copying this file and i will exit here and i'll create a new directory called gets navigate there vulnerable.c and let's save it save this here and let's copy the make file from the directory above this into the current directory and let's quickly edit the make file because it has some typo if you remember there are two dashes here let's remove one of them hopefully this should work i'm just using make yep there it is if you notice the compiler is actually warning us hey the gets function is dangerous and it should not be used who cares so let's clear the screen and let's use this function now within this current directory we have a vulnerable binary right so let's copy the exploit from the directory above this and let's paste it here that's the exploit that we have just created now let's produce so to uh to exploit the gets function obviously we will have to pass the input to this right so gets actually reads the input from std in so to exploit this we can't just pass something like this i mean the the previous command that we have used to pass the input to the strcpy binary is like this but in this case we can't do that because uh gets expected expects the input from the stdn so i'm just going to use exploit 5 and i'll just cat and i'll pass it to the vulnerable binary looks like there is a segmentation fault but i i don't think i will go ahead and find it out if you have if you are trying the same thing you can probably find it probably there is some address mismatch but it should work all right so yeah so that's pretty much it for the simple buffer overflow but for the for the rest of the uh training we are going to use other binaries i mean the the binary with the gets function all right i'm just going to move on to the next topic which is return to lipsy so next uh the plan is i think we will have to fix the exploit let me just get the exploit from here and let's test it it's the same exploit i think the address is different slightly that's why it's failing but let's try to fix it can you confirm if you are able to hear me okay thanks okay if you see the explorer that i have just copied it's pretty much the same so let's try executing this okay there is a segmentation fault i think i'll have to fix it let's try again most likely it's the problem with the address so i'm just loading it using gdb um i am just leaving my earphones aside for now if you have any questions please put them in the chat i i won't be able to hear what you're saying so please put them in the chat it's causing a bit of discomfort here so i'm just loading the core file using jdb and let's examine the stack 50 gx rsp minus 280 probably let's make it 270. okay so let's copy this address and let's quit and let's use getsexploit.pl and let's simply replace this address with the new address likely this is the problem because all of this is tested earlier okay so let's execute it hopefully it gets a shell yeah there it is so most of the most of the times uh if the exploits given to you are not working as expected the reason is either aslr is disabled when it is supposed to be disabled or your addresses are slightly changed because you rebooted the system or something happened you will have to use the code file to actually understand why the exploit is failing okay so that's pretty much it now we have a working exploit for gets function as well so we will be using this gets exploit from here to build our other exploits let me just remove the one that was not working okay now let's go back and let's create a new directory called nx and let's navigate there so we are now going to deal with nx i'll explain what nx is and how it stops us from executing the shell code and all that so let's first copy the binary from here i hope you understood why i'm using gets function the only reason is we can't place things beyond the rap value because null byte will terminate the entire payload after the rip register so we are using gets function so we can place the stuff even after overwriting our ip register so gets exploit and i think we can probably copy everything into the current directory because we need all of them so let's just put a star here all right and let's remove the code file we don't need it and there it is now now let me quickly explain what uh nx is first let's load the binary using gdb and let's type checksick if you notice uh the checkset utility currently shows that cannery is not enabled nx is not enabled pi is not enabled and 45 is not enabled and railroad is uh partial the relocation read only i'm not going to discuss all of these but the first three options are going to be bypassed by the end of the training if we can cover everything hopefully okay so let me just uh sorry i exit i forgot to show something else so i just exited let me just reload that check sake so it shows nx is not enabled what that means to us is if you run vm map command which is part of jeff it will show you uh it will it will actually show you the memory map of the process obviously the process is currently not running so let's put a break point at main and let's run the program and let's run vm map once i'm clearing the screen let's type vm map and if you see there is an entry for stack as well and the stack currently have has the flags rwx what that means is the stack is executable anything that you place on the stack can be executed as code and that's exactly the reason why our shell code was being executed when we redirect the execution from the rip register to the shell code now when you enable nx let's come back and examine what happens to this entry i'm just changing the make file here a bit let's remove this dash z exec stack option okay and let's remove the vulnerable binary from the current directory there it is let's type make and the binary should have been created there it is let's type gdb dash queue vulnerable okay let's type let's set up a breakpoint at main once again and let's type checksick if you see nx this time is enabled now let's run the binary like we did earlier and let's type vm map and this time if you notice the stack the x flag is not there anymore what it means is stack is not executable so even if you place shell code on the stack it's not going to be executed if you try to execute from a non-executable space it is going to throw a segmentation fault so even if you can place the shell code when you try to execute that it's going to cause a segmentation segmentation fault so it's going to be useless so what are the options do we what options do we have now we have two options one either don't use the stack for your execution or make the stack executable again and then execute your shell code so let me show you both the options let me let me demonstrate how we can achieve both of these things the first one is to execute something without making use of shell code on the stack the second option we want to execute the stack we want to execute the shell code that is available on the stack for that obviously we will have to change these flags from rw to rwx using our exploit right so let's first discuss the first one which is return to lipsy so return to lipsy is a technique which can be used to return the control to some functions that are available inside the libsy library so we are not going to execute the shell code that is available on the stack instead we are going to execute some functions that are available on libsy library inside the libsy library so for instance when you type when you write a simple c program like system when you write a simple c program with system function that gets executed from the lib c library so from within our exploit we want to achieve that let's see some examples here i do have slides as well in case if something is not clear i can actually show you the slides i'm trying to skip the slides a bit so that we can cover more concepts so so what i'll do is i will quickly write a c program or rather we can copy it from here we don't need to write it okay let me just copy this system.c file it's a very simple c program we are just writing this here system dot c so basically what this program does is it just execute this bin sh shell using this system function that's it let's compile this using gdb sorry gcc and if you try to execute this it should give a shell that's it that's a very simple c program let's load it using jdb and see how it works gdb if i'm going too fast if you don't understand something please ask your questions in the chat feel free sorry it should be system okay now let's set up a breakpoint at main and let's uh sorry i'm just executing disassemble main but i said breakpoint at main so it may be confusing let's just view the disassembly of main it's not breakpoint so if you see this we have a call to system at plt so basically this is a call to system function and this and this just before this call you have something happening here if you notice there is an address which is being used and it's just loading it's just executing a lea instruction which is load effective address into rdi register so we have a call instruction which is calling system function and just before that there is something that's being loaded into rdi register in 64-bit systems when you make a function call the first argument gets loaded into rdi register this is this is different from 32-bit systems in 32-bit systems i think you place everything on the stack right in 64-bit systems you will be using few registers to place the first few arguments i think i think the first six arguments will be placed in registers i will explain what their what those registers are if you have more than six arguments to a function call then the remaining arguments will be placed on the stack so in this case the system function is taking only one argument right which is bin sh so that particular argument is being placed in rdi register now let's quickly examine what uh this particular entry here 0x2004 is being shown by jeff or jdb for us just to make things simple so let's just examine what we have x slash s so we're just going to see if there is any string here 2 0 0 4 address i'm just checking what we have at this address because this is being loaded into rdi look at that that's the argument we provided to system function so bin sh address is being loaded into rdi register and once that is done the system function is being invoked when the system function gets invoked it takes the argument from rdi register that's the first argument because it's an rdi register i think the second argument goes to rdx or rbx i'll show them when we get into that the first argument but goes to rdx rdi register okay now there is another way you can check this info registers rdi i think this is because the program is not being run we can actually step through let's set up a breakpoint at main and run it and we can actually do a single step until we reach the call instruction now we can actually check what we have inside our di register so so ir command is info registers rdi register if you don't specify the register it will show all the registers if you specify a register it is going to show only that register so currently it is not sure why this is not okay let me okay this is the address that is being placed there now let's run the binary once again s i s i and one more gdb shortcut i'm not sure if it is a gdb shortcut or jeff shortcut you typed si earlier now you want to type it again you don't need to type sa once more you can just hit enter so the previously typed si will be automatically executed so i'm just hitting enter here now we are about to execute the function call and if you look at the rdi register here this is the same address that we were seeing earlier using the info registers command and if you notice it is basically pointing to this bin sh string so all i'm trying to show here is how function calls are made in 64-bit systems the calling conventions so rdi register is going to be used in the for the first argument now this is essential to understand the return to lib c technique because we are going to do the same thing using our exploit we will have to call the system function and we will have to provide a pointer to bin sh to that system function within our exploit so obviously we will have to place that pointer in rdi register right so let me just uh show you this show you some slides here before we get into that so this is going to be the return to lipsy technique so this is this is the plan for our this is the plan for our return to lipsy technique so the plan is we will place some junk in the beginning and then when we reach rip register we will place the pointer to bin asset string into rdi register i hope i'm making i hope it makes sense i hope it is clear see we need to call the system function using our exploit and the system function requires bin sh as its argument so we will have to place that bin sh point pointer to that pointer to that b message into rdi register using the exploit how can we do that we will have to pop that address which is pointing to bin sh into rdi register because system function takes it from rdi register so to place it in rdi register we will have to use some gadget in this case i am going to use pop rdi red gadget uh if it is confusing when we do it it will be clear and when you execute this pop rdi instruction whatever the value that is on the top of the stack is going to be popped into rdi register so on the top of the stack we are going to place the address of binash right so when the pop rdi gets executed whatever the value that we place on the top of the stack is going to be popped into rdi register so obviously in this case we will place the address of bin sh so that part is done each gadget must end with a red instruction when we write any return oriented programming when we create any rock chains each gadget that we use should end with a red instruction because if you remember when red instruction gets executed whatever the value that is on the top of the stack will be loaded into rip register here after the pop rdi instruction gets executed after rsp is popped i mean the value being popped up pointed by rsp is popped into rdi the rsp goes here so this becomes uh so i mean all of these will both of them will go down so rip and rsp will go down and rap will be pointing to the system function so basically once this pop rdi red gets executed rip will be pointing to this system function so the system function gets executed using the value that we have placed earlier into rdi as an argument now i will try to show this practically using by write by constructing this exploit from what we have earlier so i'll just quit the screen gdp and let's copy gets exploit it's going to be pretty simple if you understand and let's save it as exploit one dot pl we are going to use a bit of return oriented programming in this example and after this return to libsy example we are going to do a lot of written oriented programming when we try to execute shell code on a non-executable stack okay for now i will probably comment it out i will comment out the shell code and knob because we don't need it we are not going to execute shell code on the stack rather we are going to use the functions which are already available in libsy so we need uh let me also comment data commented out and we need junk i'm just rewriting that with 256 is so we have 256 a's and we have eight b's to read to overwrite rbp and the next one that we are going to write is the address of pop rdi comma red instruction how do we find it out let me just uh so if you notice this is the libsy location we can find out these addresses within libsy so i'm just copying the libsy library into this nx directory so we do have lipsy library within our current directory here if you notice libsy-2.31 and within this libsy library we are going to search for those instructions so for that i am going to use another tool called ropper ropper is a tool that can find gadgets for us typically when we write return oriented programming when we create rock chains we use ropper a lot so i'm going to make use of ropper a lot in this training so i'm just hitting enter this will load dropper for us now the file in which we want to search gadgets is libsy so i'm just typing file space the libsy library which is in the current directory hit enter it's going to take a bit of time because it contains a lot of it's it's huge it contains many gadgets okay as you can see the lipsy library has been loaded now there are the easiest way to where to search for the easiest way to search for gadgets is to type search and you can actually specify the depth so i typically prefer to specify the depth as one i'll show you what happens if you don't specify and i'll use the instruction that i want so in this case what we are interested in is pop rdi because we want to pop the address of bin sh into rdi register which is required by system function so if you hit enter look at that it has given us few gadgets and i'm interested in this gadget because it is looking simple it doesn't have any complexity typically i i prefer to ch i prefer to pick gadgets that are simple and the gadgets that do my work so in this case it will do pop rdi which is going to pop the value into rdi register so that is what i want and it has to end with red instruction so that it will it will it will transfer the control to the next available gadget in this case the address of system function so what i'm going to do is i will just copy it here and actually we overwrote the exploit in a different directory that's fine so let's copy gets exploit dot pl and let's call it exploit one dot pl and let's open this using wim and this is the address that we have gotten from libsy i'm just pasting it here here it is now if you notice uh i'm not sure if you noticed or not this is just an offset so that means this particular gadget is at this much of distance from the base address of libsy what that means is it's not an absolute address it's just a relative address to libsy so to get the actual address to this particular gadget we will have to add this particular value to the base address of libsy let me just go to this directory here and let's create a new variable called libsy underscore base and this is where we are going to specify the lipsy base address any ideas how can we how can we get the base address of libsy any ideas from anyone meanwhile let me just fix this we need 256s okay seems like there are some answers okay dazzy says led and dharmendra says vm map okay we can actually use both i'm just going to use vm map okay so we are done with this we have libsy base variable and we have 256 junk 8 base and here as i mentioned we will have to add this to libsy base otherwise it's not going to work because it's just a relative address it's not the absolute address so we will have to add it to the base and then we will have to do it so let's also remove this knobs and shell code the exploit is not complete we will have to first identify the libsy base and then we will have to place it here so let's do one thing let's quickly go to one of let's navigate to nx let's load the vulnerable binary using gdb let's set up a breakpoint at main and let's run the binary so the breakpoint will hit now we can use vm map command to get the libsy base address so if you see this this is uh the lipsy base here this is going to be the lipsy base so i'm just copying it here 7d c6000 i will also try to close uh unnecessary terminals just to avoid confusion okay so let's place the value here at libsy so perl will automatically do the calculations for us we don't have to do the additions for all the addresses that's why i'm just using a variable here and it let it do the heavy lifting for us okay so that part is done now the next step is to find out the address of bin asset string and the address of system function because we are we have just gotten a gadget that can load the address into rdi register but we don't have the address the actual address so let's find out the address of binasec so to find out the address of b message and the address of system function we can actually do uh there are few ways we can do that for the bin sh we can we can actually use a strings command on the library on this libc library for the system function we can where is my vm map output heights here so so here i'm just going to use x info system so this command should give us the address of system function if you notice this is the actual address of system function so i'm just copying it i'm just copying it here this is the absolute address you don't have to add it to the libsy base okay so i'm just going back to my exploit and i'm just placing it here remember the immediately after rip we need to have the address of bin sh so we will fix that part in a moment but just remember that don't get confused because i am just placing the address of system here system and the rap contains pop rdi red now pop rdi instruction should pop the address of bin asset string but immediately after this we have system so here we should place the address of binassee string so i'm just adding that here okay so let's find out the address of bin sh now so i'm just going back to the ropper shell here just in case if you're wondering there are multiple tools available for finding gadgets uh i have been using this dropper for a while so i like to use this so instead of i mean we can use dropper or instead we can also use something like strings strings binary and all that so i'm just going to use strings i'll i'll just take a look at the help options if you see dash a is to scan the entire file so i'll just use that option and we want to print the location of the string in base 16 so i'll be using dash d x so that i'll get the address in basic string format and yeah i think that's pretty much it so let's just use strings command strings scan the entire file dash dx so that we will get the offset in hex uh basic string format and let's use grep b message hit enter look at that this is the offset to be message from libsy within the libc library so once again we will have to add it to the base address of libsy so that's the reason why i have already created this entry here where i'm just going to use libsy underscore base plus this value i think we are pretty much done we can we can actually use this to exploit the binary already we can get a shell but uh we can make some cosmetic changes as well but for now let's quickly test the exploit to see if you're getting getting a shell or not so let's use oh for this we'll have to disable aslr just remember that we have already disabled it so it's not a problem cat vulnerable there is a segmentation fault and there is a reason for that let me open up my slides um i'm i think i don't need to open up the slides there is a reason for that let's probably produce the payload from this exploit so i'm just creating a new payload called payload one within this la within this directory and let's use gdb dot slash vulnerable dash q and let's set up a break breakpoint at main and we can actually run the binary using we if you remember we were using a different way earlier because we were taking the command argument as the input but in this case uh once again it has to read from the stdn so that's why i'm passing it like this so um we can just run here and let's set up a breakpoint at one function like we did earlier we'll just set it up by direct instruction and let's continue with the execution so we are about to execute the red instruction and if you if you notice after this we are about to execute pop rdi which is what is expected because we we placed this address in to override the rip register and it is basically redirecting to pop rdi gadget and if you remember i was telling you that okay let's probably put let's probably do an si first so you will better understand this okay now we are about to execute pop rdi right what does it do it basically pops the value on the top of the stack into this rdi register what is there on the top of the stack at this point of time if you notice there is some address which is pointing to bin sh and that's what exactly we wanted in rdi register so if you execute si rdi basically contains this address which contains which is going to point to binage and once that is done it is executing the red instruction if you remember our gadget contains pop rdi comma red so when the red instruction gets executed it is going to land on the next instruction to be executed which is in our exploit the address of system function so we are about to execute system function and we have the required value in rdi register what it means is we have everything properly set up but still the exploit is failing uh is it clear we have everything we need we require right any anything we are missing any idea why we are because we are we are able to land on system function properly and we have managed to set up the rdi register as well so any guesses why it's failing while you're thinking i'll just have a sip of cold ring return from system is causing failure actually no let's continue the execution and see what happens will that give you a hint of what's happening let me just type continue if you notice we don't have any other breakpoints but there is a segmentation fault if you see this sig sig v and we are still inside the system function we are not see there are few more instructions to be executed within system function so there is some problem within system function itself and if you notice this is exactly the instruction that is causing the issue i'm i'm not really uh an expert in terms of identifying these low level issues so i was just using google to help me with this so i'm just i'll just copy this and if you notice there are few links here there was one blog which has explained this very well so i'm just trying to look for that it's not this yeah so i think it's not this is this is not the block but if you see this this particular instruction uh causes an error when there are stack alignment issues so to fix this uh basically there are a few ways the ins instead of using the pop rdi red at the top of the i mean without overwriting the rap immediately using pop rdi we can rather execute a red instruction first so that the stack alignment issues will be solved there is a very good block which talks about what stack alignment issues are and what this instruction does and why it causes these problems i'll i'll share that link during the break time i couldn't find it here but yeah but the problem the the solution to fix this problem is to use a red instruction in our exploit where do we use it let me just quit i also have it in the powerpoint let me show that so this is what we have done so far right so this is all good i did not add this exit address but i leave that as an exercise for you i'll let you know what exit is and why we need to use that but even without using exit function we can still get the shell so if you see this this is what we have earlier and we are now going to you add one more gadget here which is red at the top so after filling up the junk after filling up with the junk after overwriting rbp register instead of immediately writing with this address we are just going to use this gadget so that the stack alignment issues will be fixed okay so what i'm going to do is i'll once again load wrapper i should not have exited so i'll just use a ropper probably on a different shell you don't need to load the entire binary you can also use the command line flags to search for a specific instruction but i prefer this way because you will have control on the depth you want to search for and all that if you remember i was telling you about the depth which is one uh one is what i have used right so let's say i don't use one let's just look for the red instruction directly look how many instructions you have how many gadgets you have gotten the reason is we are not limiting the depth it's it's it's showing us as many instructions as possible so this this particular depth is basically a kind of filter so that you don't want to have longer gadgets so i'm just specifying depth this time and look the longer instruction the longer gadgets are i mean the gadgets with more number of instructions are not there anymore now this is the gadget that looks pretty simple all we need is red instruction so i'll just copy this so this is the this is the address i'm going to use let me just go back to nx let's open up our exploit which is exploit one dot pl and just before this pop rdi we are going to place this pack once again it's an offset so we'll have to add it to the lipsy base red okay so let's save the file hopefully this time it should work seems to be some problem with the exploit let me check what it is base is fine junk seems to be okay oh okay there is a comment missing here that's the problem okay so let's run it once again and let's type id and look at that the exploit worked now if you try if you type exit once again look when the when we type exit there is a segmentation fault because after the system function is executed the the the program doesn't know where to return to so it's not able to gracefully exit so for that we will have to provide the address of exit function in the next line here here if you notice here if you notice immediately after the system address we are presenting the exit address so that when you exit from the shell it will gracefully exit without throwing any segmentation fault at this particular point of time after the system function is executed when it finishes it doesn't know where to return so it is just causing a segmentation fault if you specify exit's address it is going to gracefully exit so all you have to do is you will have to use gdb or jeff to find out the address of exit function and add it to the exploit at the end that's it i will leave that as an exercise for you but i'll i mean i won't modify the exploit but i'll show you how to find out the exit address so that you can just use that in your exploit sachin grover says comment rate i have just seen that i have already fixed that thanks now let me just go back to this and just like how we did earlier we can just use x info exit there it is if you see this is the address of exit function and you can simply add that at the end of the exploit so that should fix us that should fix the segmentation fault when we return from system function all right so that is uh return to libsy and uh we are done with that as well so we managed to bypass nx if you remember this binary has nx bit enabled the stack is not executable but instead of executing shell code on the stack we try to execute system function from the libsy library since there is no aslr enabled we managed to get we managed to get the base address by using gdb because the base address never changes since aslr is disabled right so that's these are the conditions for this exploit to work number one stack is disabled but we still manage to execute some code aslr sorry stack execution is disabled but still we managed to execute some functions by not touching the stack right we instead used some functions from libsy but there is a disadvantage here right if you if you think of it you can only use whatever the functions that are available on libsy because you are completely relying on the addresses that are available on lipsy now what if it doesn't have been asset string or what if it doesn't have something that you need so in such cases once again we will still have to rely on executing the shell code i mean if you want to have granular control on the exploit i think you still need to execute shell code on the stack let's say the the let's say the requirement is to execute shell code on the stack and you don't want to execute system function then in such cases we will have to purely use return oriented programming and we will have to enable this executable bit on the stack so that's how we can execute stack uh execute shellcode even when the nx bit is enabled so that's our next demo since we are having a very short amount of time i think i will skip this return to plt i'll skip the return to plt for now but if we have time at the end i will try to cover that the reason is the reason is we this one the format string vulnerabilities and the other two concepts are slightly complicated so i'll try to cover them in this training so the next one is return oriented programming so what i will do now is i will write another exploit that will still execute shell code on the stack even when the stack execution is disabled and we are going to develop this rock chain from scratch so let's get started let me open up my vm let's create a new directory called rob so we are going to basically create a rob chain which will enable the x bit if you remember we have rw and dash on the stack entry when we when we tried using vm map command that means stack is this stack execution is disabled so we are going to enable that through an exploit and then we will run the exploit uh to execute the shell code okay so let's navigate to rob directory and let's once again copy everything from the directory about this into the current directory okay we are all good now within this we are basically using the same binary vulnerable and this vulnerable binary has stack execution disabled okay now before we start writing our drop chain i think i will try to use about 20 minutes to this to do this because we want to use at least at least one hour for the remaining concepts if i can't finish i'll try to extend it by 30 minutes so if you are comfortable staying back you can stay back until we finish all the exploits okay so the next one is return oriented programming as i mentioned earlier return to libsy bypasses nx but it limits our ability to execute custom code we can't execute the shell code of our choice and what if we want to execute shell code on the stack even when nx is turned on that's where we we need to somehow uh make the stack executable again i think this is the trump statement and we for that we are going to use return oriented programming now we are going to create a manual rock chain to enable execution on the stack and then we will execute the shell code using that now there are few things that we need to understand before we before we start before we start writing the drop chains first we are going to use a tool called ropper which i have already introduced to you when we discussed return to lipsy and we will have to construct the stack by strictly following these conditions so when i when i build the drop chain i am going to follow these conditions strictly number one place the gadget chain to disable nx and jump to shell code so that's the high level idea right we want to change some gadgets when i say gadget it's basically some few instructions together is one gadget is one gadget we have already seen that right pop rdi comma red is one gadget similarly we will need to find out some instructions which will do the job for you and the next step each gadget must transfer control to the next gadget if you remember return to libsy return to libc attack we have used this particular concept already the gadget that we were using was actually making use of red instruction at the end so whenever we select a gadget we will have to ensure that the gadget has red instruction at the end number three consider the gadgets ending with red instruction so that's that's the same thing and number four all required parameters are available on the stack or the relevant registers so this is the most important part just like the system function when we crafted the return to libsy payload we try to arrange the stack in a way that the system function has everything ready by the time it gets executed for instance we have placed the address of bin sh string in rdi register right so similarly um we can we can basically use we should basically set up everything before we invoke any functions so that the function can actually pick up the required arguments from those registers and then we will we will need us we will place a lot of bytes on the stack actually there is a typo on the fifth point it's not space it's place we will we will place a lot of bytes on the stack so space is definitely a requirement so when you are writing your exploit make sure that uh you are doing it where you have enough space and then the last one if there are any instructions in the gadget that we do not need we will have to carefully handle them by filling with by filling with the right amount of data before reaching the next instruction so this is important because when we search for gadgets it's not guaranteed that you will find what you're looking for sometimes let's assume that let me take an example let's assume that you are searching for this gadget pop rdx comma red but unfortunately you did not find this gadget instead you found this gadget pop rdx comma pop r12 comma red if you notice we don't need this pop r12 instruction in this gadget we are we don't need it however we will still have to live with it because the gadget the the address that we had that we found contains this instruction we can't remove that from there so in our exploit we will have to carefully manage such unnecessary instructions as well right so when we get into this kind of gadgets i will show you how we can manage such gadgets okay and that's pretty much it now the next question we want to turn the stack into an executable one how can we do how can we do that so there is a function called mprotect in linux we can use this m protect function to actually change the permissions of a memory space so let me quickly show you the man page of m protect man 2 and protect basically 2 is used for system calls so m product is a syscall so i'm just using man to m protect and if you notice here just trying to highlight this if you notice this is the m protect function and it requires three arguments so if you want to turn the stack into an executable stack we will have to invoke this function m protect with appropriate arguments and if you need if you notice it has it requires three arguments the first one is the address the second one is size and the third one is an integer value which says the protection how to say that it's a it basically decides whether your memory space has to be readable writable or executable so that's an integer value that decides that that's the third argument and the first argument is the address at which you want to change the memory protections and the second one is the length so how much of your how much of your memory should be changed i mean how much of your memory should be affected by this protection so essentially we are basically trying to execute this particular function to change the stacks permissions to an executable one right we don't need to change the entire memory region we can basically change only the space where we are going to place the shell code so the first one is going to be the base address of the stack in this case because uh the address that we are going to change the protections on is stack right so basically we are going to place the base address of stack here as the first argument the second argument is the length how much of uh how much memory space is going to be affected by this change we are going to uh pick some some number uh that i'm comfortable with you it doesn't have to be that uh it doesn't have to be the case in all the cases but when i was doing 32-bit exploit development i i came up with some value which is pretty good in 32-bit uh exploit development so i'm just going to use the same value here but as i said you can change it to a different value you can basically use your own length um and the third one is the actual protection if you see this protnun the memory cannot be accessed at all if you see plot read if you basically use this the memory can be read and prod write is used to say that the memory can be modified and prot exec is memory can be executed now if you see this a bitwise or of other values can be used to specify what protection mechanisms you want to enforce on the stack what that means is if you want to have read write execute all together basically you can just use an exclusive bitwise r of these three which turns out to be the value seven here so basically if you if you place seven as the third argument your stack will become executable so to summarize we are going to execute this m protect function with three arguments the first argument is going to be the base address of the stack the second argument is going to be the length and the third argument is going to be the value 7 so that the stack becomes read write execute so the stack will have those flags rewrite execute right so let's go back okay so if you remember i was talking about the calling conventions when you call a function how do you specify the arguments rdi register contains the first argument we have already discussed that when we discussed about return to lipsy and the second argument goes into rsi register the third argument goes into rdx register that's it once that is done we can simply call m protect function now we can manually go ahead and examine uh the examine i mean we can manually go ahead and understand this m protect function using gdb but since we are running out of time i will try to directly write the exploit so let's try to follow this instructions let's try to follow this concept and let's try to build and exploit using this it's pretty easy don't get i mean try to play pay some attention here while i'm writing this exploit and it's pretty easy to understand okay so the first one we are just going to copy exploit one right so here we are we can just use the same exploit i will do everything step by step i won't copy anything from anywhere so so that you will be able to easily understand everything the first step we are writing 256 is and we are writing rbp here and after that we need to have some gadget that prepares our registers so what are the registers that we are currently interested in rdi rsi and rdx so obviously if you want to pop something into rdi register you're going to use pop sorry you're going to use a gadget which contains the instruction pop rdi comma red so this is what you're interested in similarly when you want to place some value into rsi register pop rsi comma red don't get confused with the instruction pop rdi what it means is the value that is on the top of the stack is going to be popped into rdi register i think there is some confusion a lot of people get confused about these instructions like because when we talk about push and pop we we only think about uh the stack we push something onto the stack and we pop from thing from we pop something off the stack right but when we are using this pop rdi instruction what that means is whatever that is available on the top of the stack is going to be popped into this rdi register so what you place there on the top of the stack is going to be popped into this similarly when you want to place something in rsi register you can basically use pop rsi similarly when you want to use pop when you want to place some value in rdx register you can use this gadget now obviously the next immediate goal is to identify the addresses of these gadgets right so let's go there and search for these addresses using ropper once again i'm just going to use ropper and libsy library because aslr is currently i mean asl another thing to know another thing to note is aslr is currently enabled so let's start searching for pop rdi so that's the first and if you notice we already got one is one gadget here so i'm just copying it there and let's place it here so we got one address we are done with that next address pop rsi so we will just search for pop rsi interesting pretty easy we got a neat gadget nothing complex just one instruction pop rsi which is going to pop something into rsi and a red instruction so that the control will be transferred to the next gadget okay so when this gadget gets executed it is going to transfer the control to the next gadget based on the value on the top of the stack when the red instruction gets executed that's the reason why we are looking for gadgets with the red instruction at the end similarly um we want pop rdx let's search for that there is a typo i'm just typing it again look at that we did not find what we wanted so let's increase the depth to 2. this is where i increase the depth i mean only if i don't find the gadgets with depth one i typically increase the depth if you notice the instruction the gadget is not ending with red so i don't want to use this instruction so let's increase the depth to 2 and hit enter and there it is there is one instruction that we found here i'm just going to use this pop rdx pop r12 red if you notice we only want this gadget pop rdx red but unfortunately we found a gadget with some additional instruction which is having pop r12 so we will have to handle this as well even though we don't need that we will have to handle it otherwise the exploit will fail so the first three steps are already done we have we can start building our exploit now now once you place appropriate values into rdi rsi and rdx we need to have the value of the address of m protect function so we can directly call that so what the next step we need to do is find out the address of m protect function that's one step the number the number two is we need to find out what values we want to place into these registers we already explored that using the man file of mprotect so rdi should have base address of the stack the second register the rsi should have the length which is i'm going to use 0x01010101 in 32-bit exploit development this is the maximum value that you can use when you call this m protect function this maximum value is basically the value that doesn't cause any null bytes you can use any other value of your choice as long as your shell code is being placed in that region you will not have any problem so in 32-bit uh exploit development this is the maximum value that you can use without causing null bytes so i'm just going to go with the same value but you can actually increase the value if you wish to do that and the last one as i told you is going to be 7 because this will turn the stack into read write executable okay so let's find out the base address of the stack and the address of mprotect and once we are done we are pretty much done with the exploit we will be able to bypass nx so uh let's go back to gdb so how can we find out the address of the base address of the stack any answers i need answers to both of these how can we find out the base address of the stack and how can we find out the address of mprotect please via map yes we can use vm map to find out the base address of the stack that's right what is this rbp and x info for m protect that's correct okay so we can do that so that means you are able to understand what i am doing here thanks okay so let's go back to the virtual machine and let's use gdb for finding out both i'm just navigating to nx drop yep gdb dot slash vulnerable breakpoint main let's run it and let's use via map see i'm just uh setting up a breakpoint at main and then starting the binary to be able to get the memory maps so let's also clear the screen so you will be able to see everything at the top of the screen via map and this is the stack entry and currently it's not executable and this is the base address of the stack so i'm just copying this and i'm going to paste it here so one part is done next step is to find out the address of mprotect so let's try x info and protect if you notice this is the address of m protect so once again we can copy it and we can place it here that's pretty much it we are pretty much ready to write the exploit once that is once we are done with the once we are done with crafting these things into our exploit i think we are pretty much done okay let me just quickly confirm that i have done everything right yep everything looks fine so let's just go here to our exploit okay the first one let's replace this red width um i think i'll just call and just comment it out okay and we will just start from here which is pop rdi comma red because i think we have taken the same address yeah we have taken the same address that we already have 2 6 b 7 2 and we already have that 2 6 b 7 2 so i'm just going to use that that's fine and immediately after that we will need to place the base address of the stack so that will be popped into rdi register so what i'll do is i will use the base address of the stack which is here okay anyway i'm just here so let me just change it to this i'm just changing the comment first and then let's change this address so this is base address of the stack itself we don't need to add it to libsy base because we are not getting this address from the lipsy it is just the base address of the stack if you notice these addresses have multiple null bytes so that's why we are not using sdrcpy if you are using strcpy we will have to also deal with null bytes in this case i have a 32-bit exploit development course in which i have shown the same exploit but using strcpy in which i was also handling these null bytes and all that okay so the next one is okay we are done with base address of the stack so what's the next step we will have to place this gadget so let's copy this so this will place the length in rsi register so let's use junk pack and libsy underscore base plus this one so this is pop rsi comma red so what do we want to place in rsa register that's the length so let's add another line here which is going to contain the length so the length is 0x 0 1 0 1 0 1 0 1 as i mentioned earlier this is just a value that i am comfortable with and if you come up with some other values that work for you you can just still go ahead i don't want to experiment during the training so i'm just not using a different value since i have tested everything using this value and the next one is this so i'm just going to use this gadget so that we will have rdx value set as well so let's use junk pack remember once again this value is from libsy so we will have to add libsy base to the address okay so this is let's also make sure that we are properly putting uh semicolons and all that otherwise it's going to be very hard to troubleshoot things please please let me know if you find any mistakes so this is pop rdx okay looks fine the next step is simply to pop the value 7 into this rdx register libsy underscore base plus sorry there is no lipsy bass required it's just the value 0x7 okay so this is rwx and finally we don't want system address instead we want m protect address i'm just copying this and let's replace this with this we are pretty much done the next step is to redirect the execution to our shell code right how do we do that so let's first put some junk here we can actually pick some address that we have used earlier let's say let's go to simple buffer overflow let's go to gets let's get the address from here so i'm just going to use the same address that we have used earlier so look how different the exploit now is when we want to bypass nx earlier it was just this line we directly had this now before executing the same line we are executing multiple other instructions okay so this is going to be the address of shellcode obviously we will have to uncomment the shellcode in knobsled so i'm just uncommenting this and let's comment out these 256 s okay so if you notice we have knobsled shell code and we have some ace minus the length of the shell code and knobs and then and then we have rbp and then we have our complete rock chain now once m protect returns it does all the job for us by enabling executable flag on the stack okay so let's copy this address okay we already have it here so we can use that when we debug the exploit now next we need to print knobs shellcode and junk all right let's save the file hopefully everything is correct now let's produce the payload and just to ensure i will i will show you the debugging part but just to check if the exploit is working fine or not i'll directly run it without gdb shell code spilling okay let me check oh thanks it's a terrible mistake okay okay basically someone in the chat told me that the shell code has a spelling mistake so i just corrected it it's uh shruti let's save it now let's try to execute it exploit one dot pl cat vulnerable there is a segmentation fault any guesses why any guesses if you remember we have this instruction where we managed rdx but not r12 that's what i was trying to explain earlier so when we have gadgets like this your exploits will fail if you don't handle this if you remember after this address we simply added uh 7 which is going to be popped into rdx but we didn't specify anything that gets popped into r12 so let's go ahead and fix that let's exploit one dot pl and here after this line so when this line gets executed what happens is pop rdx is going to be executed and this value 0x7 is going to be popped into rdx but next there is another instruction within the same gadget which is pop r12 so we can actually place some dummy value immediately after this so that value will be popped into r12 if you don't do that this value of m m protect will be popped into that so that's going to cause an issue that's why the shell code is not being executed so let's add some junk here so i'll just use 6a's remember the canonical addressing we can't use a ts here and let's save the file let's try to execute it still there is a segmentation fault let's check oh generate no we we don't need to generate payload because we are directly passing the exploit itself what we can do is we can remove the core file and we can actually try to check if it is or we can simply debug let's check exploit1.pl payload1 let's use gdb dot slash vulnerable dash q break point at main and let's run the exploit i mean let's let's run the binary with the payload and let's set up a break point at the red instruction of the one function like we did earlier so that we will land on the m protect function and let's continue okay if you see this we are about to execute our first gadget which is pop rdi let's type si and rdi now contains the base address of the stack hopefully is it correct is it the base address of the stack 44 d0 looks like it's different have we already executed pop rdi or we are about to execute so that should be okay okay so if you see the rdi register uh has the base address of the stack which is fine the next instruction we are executing is pop rsi so let's type si okay so that looks okay it is going to be having this value 0 1 0 1 0 1 0 1 which is what is expected so let's type pop rsi so rsi register now contains the value that we were expecting which is fine and the next instruction to be executed is red and pop rdx so pop rdx when gets executed the value 07 is going to be placed in rdx let's type si so let's quickly check rdx and it has the value seven so all the arguments for m protect are properly set up the everything looks fine until now now let's type pop r12 and let's check what r12 has seems like r12 doesn't contain our ace so that's where the problem is for now i'll just keep it here and i'll try to make changes to the exploit in a different tab i'm not sure why it's not coming there because we updated the exploit right yeah artwell should contain these a's let me quickly check if my i have an existing exploit which i have done earlier let me check if we have done everything as is i just want to save time because we have very less amount of time now cat drop one dot pl up two dot pl yeah looks fine probably we will use 40 ones in hex format let's let's check if it helps so i'm just going to update the exploit here with 641s 0x 41 41 41 41 41 41 so there are six forty ones it's essentially the same six is probably passing it as a string is causing the issue i'm not sure let's check so let's once again execute it exploit one dot pl cat and vulnerable so segmentation fault which is a good news actually it's not a bad news because we have placed an incorrect address if you remember to the shell code so let's try to execute it once again and let's try to get a segmentation fault and let's examine the core file 50 gx oh sorry gdb dash core core x slash 50 gx rsp minus probably 280 looks like 290 maybe 300 because i'm just looking for my knob sled i couldn't find it maybe 320 yeah so we can probably use this address if you notice this is pointing to the knob slit so actually we can even try further 324 or 322 320 probably will go with this address which is looking okay i'll copy this and i'll update the exploit there it is so that was the problem earlier we were we were having a different we intentionally gave a different address just to get the segmentation fault so that we can use the core file to understand uh what's causing the issue right now if you i'll just quickly i hope you understood this i'll quickly run the exploit once again just to confirm that it's working fine hit enter hit enter once again and type any commands and there it is okay so the exploit is working fine let me quickly use gdb to show what happened to the stack e okay pack expects hex all right yeah that's what i have done in my exploit but i think i forgotten that nice now let's use gdb vulnerable dash q set up a breakpoint at main before this let's also set up exploit one dot pl payload one i think i'm just going to quickly go through gdb and i'll show you what happened in the background so we have set up a breakpoint at main let's uh run the payload but let's run the binary with the payload and we are currently at main let's set up a breakpoint at red instruction once again which is here all right so let's continue and if you notice we are about to execute pop rdi once again let's type si next we are about to execute pop rsa you just keep noticing here the next instruction to be executed i'll just keep hitting enter pop rsi is the next instruction to be executed which is the instruction from our gadget and next two instructions are pop rdx and pop r12 if you notice r12 now contains the 6s and after that we are jumping onto m protect function if you notice here so that means empty m protect function is about to be executed and we have properly set up all the arguments that it requires now before we execute m protect let's quickly check vm if you notice the stack is still not executable here rw is there but not x so let's type s i let's type s i few more times and let's type vmap once again let's just check look at that so after executing m protect a few insta few instructions inside m protect the stack became executable and when the m protect return returns back it is going to call the address where the shell code is placed so the execution will be redirected to the shell code and then we are getting a shell so this is how we can manually create rock chains when you use mona basically that this is what it automatically does in windows it will try to find out all the gadgets that you need and it will try to place them in one order for you you will just copy that and you will just place it in your exploit okay so that's return oriented programming fundamentals any questions so far if not i will move on to the next topic which is bypassing canneries and aslr and nx all together so this is the stack structure of our exploit we have already done that as i said i'll just skip the plt and got from this training because we have very less amount of time we have one hour i i'll try to cover the remaining if there are no questions i will move on to the next one bypassing stack canaries and bypassing aslr and nx all together in one exploit i will try to write only one exploit to bypass all of this that covers everything that i have planned okay i assume there are no questions because i don't see anything can we move on to the next topic okay uh i'll need a two minute break i'll be back i'll just get some water and come back meanwhile i'll open up the exploit poc if anybody wants to see that here it is also since i'm taking a short break uh if you haven't please help us uh tweeting or you know putting some messages on the social media if you are enjoying the training if you notice we have very less amount of people it's the reason is not people are not interested but we wanted to uh reduce the size of the you know audience only to those who are really interested in attending the training so basically we that's the reason why we set up a pre-training challenge if people are really interested they would basically solve the challenge and uh show up for the training otherwise since it's a free training we got a lot of requests for attending their training but that's how we filtered people alright so please help us tweeting if you are enjoying it [Music] all right so let's get started with the next topic we have about 45 minutes but please expect uh that there will be a delay like probably by 15 minutes so about let's take another hour we will take one more hour to finish the next exploit so oops i have closed the slides i think anyway so the next topic is to bypass stack canaries and aslr using format string vulnerabilities and buffer overflow so what before we get into that let's first understand the problems we have first let me just go back here and let's create a directory called full bypass okay and let's navigate there if you notice we have been cheating a bit we have disabled nx we have i mean initially we disabled nx later we enabled nx but we still disabled stack canaries and we still disabled aslr so we we have been cheating a bit now there is no more cheating we will enable all the protections and then we will see if we can bypass them using by chaining some vulnerabilities now the first thing i'm going to use i'm going to copy everything from the drop directory once again nx drop because that's the latest exploit we have and i will just delete the core file and i'll edit the make file to have everything enabled i will just disable this stack protector no pie and everything please pay attention for the next one hour because this concept is uh bypassing all together at one exploit is going to be very complicated so i will need your full attention here if you are still here okay so let's save the file and let's remove the existing vulnerable binary and let's create it once again using make function make make command and there it is we have a vulnerable binary now we can quickly type checksick vulnerable here i have installed checksick even here in the machine i hope i have installed it yeah there it is look at that all of them are enabled full railroad canary found nx enabled and pie enabled now we are going to deal with all of these in the next exploit so before we deal with all of these we will have to understand what what are what are some of those protections that we are directly going to deal with number one we are going to ignore pie because it's not pie is not applicable for us in our exploit it's automatically going to be cleared off we are also not going to deal with railroad we are only going to deal with stack canary nx and aslr so pi is pia comes into picture only if you use the addresses from within the binary we are not going to use any addresses from within the binary we will use all the addresses from libsy libsy library so it's not a problem for us at this point of time so pi is out of scope for our exploit okay so let's clear the screen and let's try to run the exploit the same exploit that was working earlier which is exploit dot pl we still did not enable aslr but let's see what happens cat vulnerable look what happened the first problem we are now facing when we enable every protection is stack smashing detected terminated so this means we are not even able to proceed further to execute the shell code so to be able to uh solve other problems like nx and all that we first need to be able to override the return address and then we will uh call the m protect function using some gadgets and all that but this protection is not even allowing us to reach that stage so that means we will first the first and foremost thing that we have to bypass is stack smashing stack smashing detected i will explain how how this is being done but we let's also enable aslr now i'm going back to aslr directory let me let me use a different tab let's verify aslr look at that the value is currently set to 2. so so what happens uh so what are the what are some of the problems that we are going to face in the exploit that we have already created let's take the rock chain exploit as an example this one the first and foremost thing because of stack canary uh the stacks because of the stack canary that is detecting the stack smashing we won't be able to overwrite we won't be able to able to take control of red instruction i mean the the the saved return address which is rip register because even before we take control of that the stack smashing detection protection is basically stopping us from everything that's one problem so we will have to solve that we will have to solve that the problem number two nx nx is also enabled in this binary so obviously we will have to go with one of these two techniques which is return to libsy or return oriented programming using m protect function right so that's the second problem number three aslr since aslr is enabled this libsy base address is not going to be static anymore this will keep changing every time you start the binary so if you write this exploit with this particular base address as a static address it's not going to work every time you restart the binary so basically the moment you start the binary it's going to get some different lipsy base address which is completely different from what you have in this exploit so obviously that's going to fail so these are the three problems that we will need to solve in this particular scenario so first i'm going to change the binary because uh it's it's a bit hard to exploit this exploit this binary with all these protections um so let me just copy another binary i mean let me just copy another vulnerable program into this which contains some memory leak problem so we are going to chain those memory leaks and we are going to leak the base address of the libsy at libsy library and then we are going to come up with a new exploit okay so let me get the vulnerable binary so this is going to be the vulnerable binary here i'm just copying this if we have more time i would have explained everything with gdb and all that uh currently i think we will have to skip some of the basics but i hope you will understand like how the stack can read how stack canary detects the stack smashing detection and all that i'll try to do as i'll try to show as much as possible but yeah let's compile this and we should have a new binary here and this particular program if you notice is vulnerable to two different vulnerabilities it is taking an argument from the user if you see arc v1 and it is calling one function which is this and that user supplied input is being passed to printf function without using any format specifiers that causes a format string vulnerability when you have format string vulnerabilities you can basically leak the addresses from the stack if you if you are lucky enough if those addresses that are being leaked from the stack contain any libsy addresses and cannery the stack canary which is detecting your stack smashing attack you can basically use those details to actually perform this buffer overflow attack which is being caused because of the gets function so that's what we are going to do now we will try to use this printf format string vulnerability to leak the la to leak the stack canary as well as the libsy addresses and when we leak those libsy addresses we will try to compute the base address from those libsy addresses remember we are not going to get the base address directly from the stack we will still have to compute that by using some addresses so let's try to use this vulnerable binary to achieve that as i said it's going to be slightly complicated so pay full attention and if you don't understand something like how i'm doing a specific step please ask me because since we are running short of time i may skip some of the steps but feel free to ask me if you don't understand a specific step so i'll be explaining explaining them to you in detail so the first thing we will have to interact with the program if it is a network program we can basically exploit the format string vulnerability using one packet or one request and wait for the response and then send another request for the for exploiting buffer overflow but this is a very simple ctf style binary right so it's pretty hard to interact with this binary as one process because it's just one process it just takes some input and it just exits so to be able to interact with this kind of ctf style binaries we can use something called pawn tools so i have already installed pawn tools in your vm so you can basically use that pawn tools you can basically use this pawn tools to interact with this binary and write this write this exploit so where is my full bypass okay let's navigate to full bypass i think i have i think i have copied the vulnerable program into a different location looks like that yes so i think i'll have to copy it once again let me get that let me get that into the current uh directory yep so this is the program we want there [Music] it will take another 45 minutes [Music] so i'm just setting the expectation in case if you are in rush all right so printf and gets everything is set let's remove the binary and let's compile it once again let me quickly check if our make file is properly there yes it is so yeah so we are all set now let's start exploiting this function exploiting this particular binary so the first thing as i mentioned we are going to use a stack canary bypass right so if you see this vulnerable binary we can basically pass some test input and we can ex we can exit from there and this test input is going to be printed using the printf function which is vulnerable to format string vulnerabilities and the next one is gets function which is taking the input from u so you can use this gets function to basically provide a long input which is going to cause the buffer overflow okay so that's the process of using this vulnerable binary now if you if you provide even longer input here the s it's going to cause a segmentation fault but even before that the stack smashing detection is going to be done now let's quickly check how the stack smashing detection is being performed i'm opening gdp dash q vulnerable i'm basically loading the vulnerable binary in gdb and i'll quickly explain how stack smashing is being detected and disassembling the one function using this as one function and if you notice there is look at this there is an instruction at this address which is at move i mean one function plus 22 there is something from fs 0x28 being loaded into rax register and if you further go down some checks are being done with the rx register and there is a function stack check fail being called so basically it is putting some it is the program is basically storing some value from somewhere into rax register and once that is done it is just doing its job and before it is returning to the caller it is performing some uh verification here if you notice on the same rax register basically it is taking the it is it is getting uh some uh the same value into rx register i mean it is basically taking the same value from the previously shown location which is here and it is performing xor on the content of rax register if it is 0 that means the value that is placed in rx earlier is not modified that means there is no buffer overflow if the if the value uh if this value in rx and if this value are not matching that means there is a stack based buffer overflow attempt and it will basically show this message stack smashing detected so that's how this stack can re works it's being it's being placed just before the return address so if this value is overwritten that means the written address is also overwritten so that's how it detects a stack smashing now how do we bypass this if you can somehow leak the value that is being placed in this rx register which is basically being used to to detect the stack smashing we can basically adjust our buffer by sending this value when we are attacking when we are exploiting the buffer overflow so just to uh give a representation here and just to give better picture it is checking uh so we are just passing some value here like uh some s and somewhere here it expects a canary and here it expects uh probably let's say the written address so this is the original uh i mean when you are not exploiting this is what is expected and let's say we are passing some more buffer here i mean this is this is the original binary but when you are exploiting the binary basically you are overwriting this canary with some value so it's trying to find out the canary value but it is not able to find out so it's basically returning a stack smashing detection error so how do you exploit this how do you bypass this problem we will have to use some other vulnerability like format string vulnerability to leak this scanner somehow so we will obtain this scanner using a format string vulnerability and we will place this scanner using the buffer overflow vulnerability here so when the program checks for canary detection uh the canary protection i mean the stack smashing it stack smashing attacks it's going to fail because we are actually placing the required canary value there so it it has no way it can detect the buffer overflow so that's the first step that we are going to do we will have to somehow find out the calorie value and we will have to uh we will have to adjust our buffer in a way that the canary value is available in our buffer right so that's the first step and let's see how we can do that is it clear any confusion here yes uh most of the cases yes because canary is a random value we will it's it's pretty hard to brute force it if it is 32-bit systems you can brute force the cannabis but in 64-bit systems uh it's pretty hard because there are also multiple types of calorie values the one that we are dealing with is a random calorie and moreover it's a 64-bit calorie value so yeah we will have to somehow leak it using some other vulnerability okay so yeah so let's proceed further uh so i'll probably just start writing the exploit template because we have less time so i'm just going to use pawn template i'm just trying to find out the command okay let me first show you some other things i mean i'll show you first how to use the format string vulnerability to leak the canary and after that i will start creating the template so let's use gdb vulnerable dash queue and set up a and probably we can just run the binary if you notice i am running the binary using some values here percentile llx x is to basically uh leak the hex values from the stack so percentile x can be used if you are using a 32-bit machine but since we are on a 64-bit machine i am using llx long long hex values okay so let's use percentile llx i'll probably copy it because i'm just going to use a long value here i'll copy it from somewhere else and let's paste it here so i'll use this long value as the argument to the program and i'm running the binary if you notice it has leaked some values from the stack now at this point of time this is greek and german for us it's these are some hex values but they are going to be very very useful for us at a later point of time now the first thing any guesses just by looking at these values can anybody guess which one could be the stack cannery i'll give one minute to think any so so basically this output which is leaked from the stack has canary values uh just in case if you are wondering uh what format string vulnerabilities are how they work and all that i have recently published very detailed format string exploit exploitation articles probably after the training you can go through them you will have very very detailed understanding of format string vulnerabilities if you see how print functions work how format specifies work and how you can simply exploit format string vulnerabilities and how you can lick the canvas and all that with with very detailed explanations so you can just go through this blog later okay for now um yeah any answers which one could be the format string i mean which one which one could be the stack calorie someone sachin grover says the one which is starting with f0 b5 ff 0 b 5 f f o no no such and it's not okay i'll tell you the answer the one which is here obviously i'm just starting the binary along with you i i don't have this value anywhere documented but looking at this this is the stack canary because if you see it's ending with the zero zero which is null byte so these people who implemented stack calendars are very very smart even if you manage to put your canary here if you notice the candy is ending with this null byte so that means you will your buffer will terminate here so that's that's another reason why i'm using gets vulnerable function here for the buffer overflow vulnerability uh but there will be some canaries which will have a new line also in the canary value so that means even gets function will not be uh even gets one gets function also will terminate the buffer when the moment it finds the canary in the buffer so i hope you're understanding you are passing the buffer and you you you somehow managed to find the cannery but the canary has a null byte so what that means is even if you manage to leak the camera you can't make use of it especially if you're using a binary with vulnerable function like sdr cpy because the moment it trigger that the moment it encounters the null byte in the canary it is going to stop copying the buffer so you can't basically overwrite rap and you can't execute shell code or anything so that's how can rays work in this case we are using gets function so null byte is not is not a problem so now this is the canary um so we have used multiple llx percentile llx uh strings here so that that's that's how we when these are the format specifiers since we have control on the printer function we are basically able to pass the format specifier since that since it has a vulnerable implementation and by passing those format specifiers we are able to leak some addresses from the stack and out of which one of these addresses is stack cannabis so this is a stack canary i'm just copying this actually it's not needed because the moment you run the program once again the cannery is going to change so there is no point copying it but just saying this is the canary now we don't want to leak all of these addresses right we just need the cannery to bypass stack canary protection however these addresses some of the other addresses are required for us uh for actually bypassing aslr and nx so let's see what we can do next to basically bypass nx and aslr give me a moment i'm just making sure that we are doing everything properly okay so to um there seems to be a question here uh as i said it's going to just leak the hex values in hex format the percentile lx is long long hex if you are if you have seen format string vulnerabilities in 32-bit systems you typically see percentile x or percentile s right so since it's six since it's a 64-bit machine if you just use percentile x let's say you can't get this long values so to be able to get these longer values let me show you so this is a vulnerable function vulnerable program and we are able to leak like this let's assume that we are just using vulnerable and percentile x percentile x percentile x personal dialects or let me just use some separators so it's this percentile llx is leaking some values from the stack because of by using the format string vulnerability if you notice uh if you don't use percentile llx it's it's only printing as a shorter values because it can't it can't give us a 64-bit values because that's the reason why we are using llx so when you do when you're dealing with 64-bit machines you will have to use percentile llx okay similarly you can use percentile s to leak some uh strings that are being pointed by the address on the stack so that's that's format string vulnerabilities i know i should have covered more details about the basics of format string vulnerabilities but we don't have enough time so just go through the articles that i have just referred okay so yeah so that's the first step we managed to leak we managed to leak the stack camera if you notice we have stack canary here now to be able to get the actual canary value by using the exploit we can count it actually one two three i mean how which what is the number at which we can actually get this value for for instance one this is the first value this is the second value this is the third value similarly i think this is the 41st value if you count all of these i think it becomes 41. let's quickly try dot slash vulnerable percentile 41 llx let's try it again i think it's uh i think it's 41 lx oh sorry i think we need to use a dollar here yeah so if you notice let me just show it again so this is the stack canary in this run now if you run like this basically the dollar has to be escaped so i just added a slash here and so basically if you want to extract a specific entry if you see this is the 41st entry this is the way to extract that instead of extracting all the entries from the stack based on how many number of percentile lx you have passed you can just pass the number at which you want to extract so if you see we are only getting the canary now so that's how we can use it in the exploit so that's the first one so i'm just going to use uh font tools to basically produce a template so we can directly use all of these things in the exploit i'm just typing pawn i think let me just find out the command template and the vulnerable program is this and i think we can write it into exploit.pl let's open up let's open it up yep so uh i'm just going to use pawn tools as i mentioned earlier so using pawn tools i have created a template here pawn tools is basically a ctf framework which can be used to interact with the binaries at uh which we can basically we can use it to interact with the binary so now this is a template which is created exploit.pl let me quickly open that by default it creates with python3 it has a long large amount of text don't get confused just follow what i am doing first step i will change this to python3 that's done next step we want to pass the command line arguments to this program right so that can be done here return process exe path is there right so basically it is going to call the function process using which the process will be started and then we we want to pass some arguments to that so the way we can pass arguments is exe path and we can basically specify percentile the same uh 41 llx so this is basically going to leak the stack cannery for us by using this exploit this is i mean don't get confused if you are using pawn tools if you if you are seeing pawn tools for the first time if you remember earlier we were writing some simple pearl templates right it's basically the same thing instead we are using pawn tools to automatically generate it because we need to be able to interact with the program at runtime so i'm using this percentile 41 llx that's pretty much it and if you go that will basically leak the address for us and here exploit goes here so this is where you're going to write all your the complete exploit so what i'll do is i will just uh remove all the necessary stuff here all right so io.start is going to start the binary for us and once that is done we can actually read the canary using io dot redline so this is once the binary gets started with the arguments that we are passing using the the process function it is going to leak the canary right so that canary is going to be placed in this particular variable called cannery we can actually quickly print it out so i'm just going to use print canary so let's save this chmod plus x exploit dot pl we will bypass all of these uh but for now we are just dealing with stack canary if you notice the stack canary has been leaked that's fine so one problem is solved so we managed to write a simple template script which is leaking the stack cannery is it clear so far if yes we will proceed further to understand how we can leak libsy base address and use it use it to bypass nx and aslr so we we basically passed one argument which is exactly liking the base stack gallery so that's pretty much it now let's move on to the aslr and nx part once again we are just going to use the same format string vulnerability by using dot slash vulnerable and we will have to use the same old percentile llx thing um just give me a moment please i'm just copying some text here so that you can i can show it to you okay so once again i'm just executing the binary like this if you see this once again we this is where we have the canary value now if you remember in the return to libsy as well as i mean in the return to libsy attack we were using the base address of libsy library right so that is something that we need now now to be able to leak the libsy address the the base address of libsy to be able to leak the base address of libsy basically we will need to find out some address in this leaked addresses which is from which is coming from the libsy library so the point is we should be able to find out one address at least in this which is actually coming from the libsy library it doesn't matter which function or what it is we we just need to find out the libsy address from these leaked libraries so from that address we are going to uh compute the base address based on some knowledge that we already have okay so let's let's see how we can uh do that so first of all um let me load this in gdb vulnerable dash queue set up a breakpoint at main and let's run this binary using this okay so we should have gotten some addresses i'm just going to copy them looks like it did not give us yet so let's do one thing let's probably um set up a breakpoint at one function so by the time we reach there we will get some leaked addresses i'm just continuing the execution here you go you got some addresses i'm just copying them now the idea is we want to find out at least one address that's being leaked from libsy so these are the addresses that we have got in route right now let's try to find out let's let's enter some text so that it will continue the execution and the break point is hit on red instruction now let's type vm map and if you notice this is these are the entries associated with libsy now identifying libsy address from these leaked addresses is as simple as that finding out one address from this leaked address letters addresses in this highlighted range so this is the range for the lipsy addresses right so these are this is where the lipsy library is being loaded now if you can find out at least one address from these liquid leaked addresses within this range then that's basically the libsy basset that's basically one address from libsy so let's see uh if we can find out any such addresses in these late ones if you notice this this is one good candidate that we can check 7 ff ending with basics fc8 starting with 7 wfwf if you notice all these addresses are starting with 7wf so basically we already found one so all of these addresses are on the same range right so this address is possibly this address possibly belongs to libsy so if you remember this is the 41st value so this becomes 40th value so from so far the knowledge we have is 40th value is probably not probably actually you can verify this within the vm map it's basically within that range so the 40th value is from libsy and 41st value is from is the stack cannon is the canary so we have gotten this information so far but this address that we are getting is an absolute address what we want is the base address right so to compute the base address any ideas anybody has any ideas how can we compute the base address how can we compute the base address at runtime any ideas from anyone ok let me explain now we know that this is the base address of libc in this case right so i'll copy this but this base address will obviously change next time when the binary gets started obviously in gdb aslr is disabled by default so if you check the check this address if you check the base address of libsy within gdb you will see the same address every time but when you check these addresses outside gdp they will change every time by default gdb disables aslr you can enable it if you want that command is aslr space on simple okay so this is the address that we have gotten and at this point of time this is the base address what happens if you subs if you subtract the base address that we currently have in gdb from this we will get some offset right so we know this value and we know this value and these offsets will always stay at the same uh relative address if you remember we were using bin sh offset within libsy we were using system functions offset we were using m protect functions offset all of these addresses all of these offsets will always say at the stay at the same place so offsets will never change only the base addresses will change so if you know any two addresses you can calculate the third one right i mean if you know any two any two values you can calculate the third value in this case we know one absolute address we know the base address and we want the offset of this address let's calculate that i'll just using uh basically you can use calculator um but in this case i think i'll just uh yeah let me use calculator just to avoid any confusion in case if you have so i'll use hex mode i'll paste it here minus the base address that we have got in so let's paste it here equals 1 f 0 f c 8 so 1 f 0 f c 8 what did i just mention this offset will always be constant this means if you can somehow leak this address at runtime which is the 40th value always and you know the offset you can obviously calculate the base address right how do you calculate that you just need to subtract this offset from the leaked address and you will get the base address that's it so just use these calculations and just reconstruct the exploit once again that's simple so let's do it uh so let's do that i'm just going to remember this is the 40th value because if you notice here this is 41st value candy and this value is just before that so it should be 40th value so within the within our gdp exploit i mean within our what is that the template that we have used we can just update that it will take another 15 minutes we will wrap it up okay so let's open up exploit dot oops pl oh it's saved as pl that's my bad it should be python obviously though the extension doesn't matter let's let's make it pi so exploit dot pi i'm surprised nobody pointed out pointed it out okay so we are already leaking the stack calorie here now we also want to leak the libsy address right so let's do that i'm just going to add one more entry here percentile 40 dollar lx or llx and i'll separate these two with a semicolon a colon okay so that should give us the lipsy address first and then stack canary next let's simply execute it first and see how it looks like exploit dot pi look at that it is leaking two addresses this is the this one is going to be the libsy address and this one is going to be the canary that's it we can we can now construct the buffer by properly extracting these values and calculating everything now i will quickly do this so we have everything done since we have less amount of time i'll probably copy from what i have already written earlier so i'll just go to backup and go to full bypass and i'll go to exploit or final dot pi so this is the file i'll just copy line by line so you will understand why i'm doing and what i'm doing we are pretty much done so this line we have already written okay i think i'll just use this one because it it contains some good strings being printed when you complete the exploit okay so the first thing i'm also placing the shell code that we are going to use later the concept is all done i mean that's the whole concept we are just going to um do we are just going to manually write everything now so instead of writing typing everything i'll just copy and paste so the first thing we have a variable called shell code oops which contains the shell code all right and then let me just close everything else just to avoid confusion and after that we are leaking the whole libsy address as well as the stack canary that part is already done if you see this this part is done but let me just paste it from there so that we will have proper variable names after that we are just printing the leaked addresses which which we have already done earlier now let me just execute it till now exploit dot pi if you see we are just leaking what we have leaked earlier so that part is already done now let's continue with the exploit now we need to extract these two values use programmatically right so let's do that first i will extract the first so if you notice uh i'm just using i'm just extracting the first 12 bytes and i'm just converting it into an into an integer value of base 16 so that we'll get proper hex values that can be used as addresses right and using that we are calculating the lipsy base how are we calculating the lipsy base if you remember we got no we got an offset earlier and whatever the value that we are getting from the leak we are taking that and we are just subtracting the offset that we have computed earlier which is this 1 f 0 f c 8 1 f 0 f c 8. so this should give us the lipsy base address right once this is done we can actually print it i'll show you i'll just print it now so here it is if you run this it should print uh the the computed base address libsy base address so this is what we were hardcoding earlier now if you run this look at that it has leaked this address from the stack and using that it has computed the base address of libsy right now let's move on to the next step so what else we have uh libsy address libsy base address so we can basically start using return to libc attack that we have seen earlier and when we overwrite uh the canary we will just have to place this canary value that we are that we are extracting the second part of the leaked address right so the next step is basically to construct the return to lipsy attack so i'm just making use of this we have already discussed how to construct this return to lipsy payload so i'm just copying it basically i copied it from the previous exploit into this if you see we have a red instruction here which is to uh prevent the stack alignment issues and we have pop rdi bin sh address it's the same exploit that we have written earlier i just added exit address at the end which i asked you to do as uh homework now the return to return to libsy exploit is finished so what can you do with the return to ellipse exploit we can bypass nx right um so nx can be bypassed so that we can execute uh exec we can execute bin shell using system function by using this part so nx part is done we already did this earlier so we are just reusing that now to bypass aslr we leaked the libsy base i mean we leaked some lipsy address and computed the lipsy base right so with that by aslr is also bypassed because we are calculating it at runtime we are calculating it at runtime now the last and final part when we send this payload to the target binary we will have to properly adjust the payload in a way that it contains the canary value as well so let's compute the canary value from the leaked address so to compute the canary value i'm just let me show you what i'm doing here it's basically extra programmatically extracting the values that are leaked so i'll just try to run this for you exploit dot pi look at this so we have gotten these values from the leak and computing the canary value is simply basically extracting the second part which is this that's it it's nothing it's not rocket science we are just extracting it and that's the canary now we will have to use that in our exploit okay so let's go back and now let's craft the complete exploit i will first use 264 oh by the way i missed one thing uh i missed to show you one important part when showing you the cannery uh leak so here you also need to find out the offset to cannery once again you can basically use the same technique you can overwrite the canary value with some uh pattern and then you can find out how what is the offset to leak uh override the calories so here i'm just removing all of these extra pasted ones i'm not sure why but they are being pasted multiple times so here the canary part is done earlier now we are crafting the actual payload the 300 byte payload first we are placing the shell code in the beginning and we are passing some ace minus the length of the shell code right pretty clear till here and once that is done we have to place the stack cannery so in pawn tools we can use just like your pack function in perl we can use this p64 of the exact hex value so that it will be converted into little indian format for you so that's the p64 function here within this uh that's the p64 function here within this template so we have leaked the canary earlier if you remember this one so this just in case if you are unsure this leaked off 13 colon 29 is extracting the canary part from the leaked address which is the 13th character to 29th character that's it and we are converting it into an integer once that is done we have placed the canary this is the offset to canary value which is here and once that is done pretty much everything is straight forward we will just have to place the remaining exploit with the rbp and rap register so after the canary we will overwrite rbp so this is going to be the structure first we will have long long buffer we will have cannery if you don't want to find out the offset to candy by using the if you don't want to find out the canary by using the pattern you can basically use the rbp offset minus 8 because this is going to be the structure canary will be here rbp will be here and rip will be here so since we already know the offset to rbp we can just make it minus eight and that will be the offset to canary okay so that's what we have seen that that's what we are going to do now if you see this 264 minus length of the shin cord and we are going to use the canary next eight b's i think i am i'm wrong uh it should be yeah i think it's it's right so these be these eight b's are for the rbp register and then the next one is the rap so from here rap will be overwritten and the return to libsy payload can be executed here so it's just the return to return to libc payload we are just constructing using python you see this this is the return to libsy payload from here to here and this this is rpp this is canary and this is the junk once that is done we are sending the payload to the uh binary by using io.sendline so this is going to send the input to the gets function right so that's basically payload that we have constructed so far if you just save this file let me quickly show it once again the exploit part first we are enter we are starting the binary and then we are actually the shell code is not needed i have uh uh anyway we are using return to libsy so basically it's not needed so that's a mistake i have added here now the leaked address the leaked variable contains both the libsy address as well as stack cannery once that is done we are calculating the lipsy base by subtracting the offset that we computed earlier manually and after that we are using this lipsy base to actually construct our written to lipsy payload after that we have extracted the cannery and finally and finally we have just uh adjusted the buffer with the canary and the payload so let's run this dot pi hopefully everything should work if everything works we should have a shell there it is so this is how we can basically bypass canneries nx and aslr by chaining multiple vulnerabilities so if you see any real-world vulnerabilities these days typically they'll have to deal with all of these modern exploit development protections exploit protections so if you see we are using ubuntu 2004 it's a modern machine and for this specific exploit we have enabled all the protections as you can see here nx enabled canary is found a full railroad and aslr is also enabled let me put on my earphones if you have any questions feel free to ask me if not i think that's the last topic that i wanted to cover you

Channel: Source Meets Sink

Views: 12,014

Keywords: Linux Buffer Overflow, 64 bit exploit development, Stack Canary Bypass, NX Bypass, ASLR Bypass, 64 bit Ret2Libc

Id: gxU3e7GbC-M

Length: 226min 35sec (13595 seconds)

Published: Sat Oct 03 2020