HackTheBox Cyber Apocalypse 2021 CTF - Pwn Challenge Walkthroughs

in this video we're going to take a look at some of the prone challenges from the height the box cyber apocalypse 2021 ctf the first challenge is called controller and it says the extraterrestrials have a special controller in order to manage and use the resources wisely in order to produce state-of-the-art technology and weapons for them if we gain access to the controller server we can make them drain the minimum amount of resources or even stop them completely take action fast so we're able to start a docker container once we get this working locally so let's go and take a look at the files first of all so if you check the files that were downloaded we have a libc library which should be the libsy version that's running on the server we have the controller binary which is a 64-bit executable it's not stripped so the debugging symbols haven't been removed we can run checksec on it and see what protections are enabled so full railroad so we're not going to be able to overwrite sections of the binary like the global offset table no stack can arrows so we don't need to worry if there is a buffer overflow we don't need to worry about tripping over stack canaries or having to leak them nx is enabled so if there is a buffer overflow and we're able to place shell code on the stack we won't be able to execute it so we'll need to look for some kind of gadgets maybe return to the libc library and pi is not enabled so each time the program loads it'll have a predictable memory address and we'll be able to use hard-coded function and gadget addresses and stuff without needing to get the pi base address first we might want to run strings just to see if there's anything interesting here any passwords or anything sticking out um we can get an idea what's going to happen with the program as well so it looks like some kind of calculator here it's going to take in some decimal inputs and produce a decimal output and we have the plus minus multiplication and division and uh we can see that there with the string as well it's asking for two different types of resources okay i don't see any passwords or anything anyway let's try and run the program and we run the program we have it's asking us for the two types of resources let's try and put in some values and we get an operation available let's try and divide cannot use these many resources at once okay so we're going to need to go and have a look at the binary we could try and use ltrace although i've been finding with this ctf because of the way that the characters have printed out one character at a time you know um with this kind of animation it makes it makes us quite a bit harder and you'll see later on when we go into pwn tools with this as well it makes the debugging and prone tools a lot more difficult i ended up just disabling a lot of the functions i normally use just because they were taking so long to write the output so i hope they i hope they don't do this again in future ctfs anyway um but we could try and put in a value again let me try and put in one three three seven again and we'll do the same again i just want to see whether it comes up with a string compare but it doesn't appear to so all right well let's try and do an addition this time and you'll see there it's just looping through we cannot use these many resources so we're going to want to go and have a look at the binary a little closer let's open up geardraw i'll create a new project and speed through the process so once gear just open up we can go and have a look at our functions we know that we're going to be able to find our main function because it's not been stripped the function names haven't been stripped so we're going to have a look we've got this welcome function which is just dealing with the colors and i guess the slow output maybe of the text so we don't need to worry about that let's go and have a look at the calculator so we have a buffer declared here of 28 chars and then this local c integer and local c is going to be assigned a value from this calc function and we can see that right after this let's trace before we have a look at the calc function let's have a look and see what we actually want to happen so in terms of this local c is coming back it's checking if it's equal to ff3a which we can let me go and convert this so we can just go and convert this to decimal so it's comparing the result of that six five three three eight and if it equals that it's gonna say something would happen do you wish to report the problem and then it's gonna call scan f it's gonna bring in some it's gonna read in some input from us let's have a look here the data section so it's written in a string from us and it's reading it into this local 28 which is 28 characters long but there's no there's no check right there's nothing to check how long the what we're entering is whether it's actually going to fit in that variable so there's a clear buffer overflow there and it looks like that's what we're going to want to that's where we want to go so we need this condition to be true and then it's going to check whether we entered a yes if it if we did then it'll say reported if not ignored but we don't need to worry about that because we're not going to be entering a yes we're going to be entering in some something to overflow the buffer so let's go and have a look at this calc function and see how we can get the result to equal six five three three eight so i mean this is a calculator pretty standard calculator is gonna check whether we want to it's gonna take two numbers from us as you can see here and it's gonna check do we want to add them together do we want to subtract them do we want to multiply them or do we want to divide them and then it's going to return the the result the problem is before it does the calculation it's going to check and see do the two values we entered are they both below 45 in hex which again we can go and highlight this we can convert it if we want convert that's decimal so it's checking to see if it's 69 you don't need to convert that by the way you can just highlight it here um to see what it actually equals just if you want to keep it permanently at that so we need to make sure both are less than 69 but at the same time then we need the result to equal 65535 i think so i mean obviously if we were able to put in a larger number it'd be no problem we could just put in like six five three three four plus one but that's obviously not an option so we could go through here and try and work out is there anything any values that we can put in together to to get the right value maybe we can multiply two values but the problem is that even if we do 69 times 69 that gets us less than 5000 so nowhere close to the to the result we need so there's nothing to stop us from entering in negative values here so if we enter in if we subtract a negative value from another negative value we can get a positive value back so in this case if we subtract like well the value that we want to get is mat is six five three three eight so if we subtract if we double that and make it negative and then subtract it from this as a negative as well in fact let me just type that out just so it's a little bit clearer um so if we take a copy of this let me just do python c print and then six five three three eights times two so we have this negative value and then we can subtract we can say that the result is equal to minus six five three three eight minus minus one three zero six seven six and that will return us a plus six five three three eight so let's try it let's try and run that let me go let me run the program without any l trace or anything that's just for two different resources so let's say we want first of all six five three three eight and what do we want to subtract from it in this case it's gonna be double that with negative again so one three zero six seven six and then we're given an operation to choose from we want to subtract and you can see there it's trying to subtract the negative 130 000 from the negative 65 000 and that gets it the plus 65 000. so now we get do you want to report the problem so we could enter in a lot of a's here and see what happens and when it returns you see we get the segmentation fault because we've overwritten the instruction point so let's go and have a look quickly as well at how we can identify where the uh the offset is for that in gdb so i'm going to open this up in phone debug and i'm going to generate a cyclic pattern here it doesn't really matter too much how long we know it's going to be well the buffer there is 28 characters so you know we don't really need this many but it's okay so we can run the program and we're asked to insert the numbers again it was minus minus six okay so minus six five three three eight and then minus 130 670 and then the subtraction operation it asks us do we want to report the problem and now we can put in our cyclic pattern and you'll see that we've crashed the program we don't have anything in the rip because on a 64 bit it won't it won't go in there so we just take the first four bytes from the stack pointer which would have made it into the rip and then we can do cyclic l and paste that in so we know that there are going to be 40 bytes that we need to overwrite before we overwrite the uh return address before we overwrite the instruction pointer with a value that we want to jump to now the issue is here there's nowhere to jump to the program we can't just add some shell code at the end of that and say we want to jump to the rsp because nx is enabled so we want to have a look and see if we can return to lib c so i'm going to close down gdb let's go and try and put this together in a phone tool script okay so i have a phone tools script here let me open this up this is part of a template which i normally use these scripts which some people are a bit daunted by maybe the size of the template initially it's nothing to worry about at the moment here there's nothing so your whole exploit goes in this section where you have this big head in saying exploit goes here i've been up here most of which you don't need to touch whenever you use this template the reason i use this template is because you have the start function which means that whenever you run the program you can either just run the exploit or you can run it with gdb and it'll automatically open up in a debug mode where you can then go and put your break points in here we can say like we want to break at main or we can give it an address or something like that and it's quite easy then to swap between those two you can also add stuff like no no aslr to the end of that and you can provide remote as well so if we get this working locally and once it's working locally all we need to do is provide remote and then server ports and then we'll be able to without having to just go and comment out and and add in lines constantly to say you want to open it in gdb or you want to run remotely and things like that that take that takes care of that for you and i never touch this this function it just stays as it is this function is to find the offsets the instruction pointer which we don't really need to do right it was easy enough for us to find in gdb but um i just i just normally have this here to be honest in this specific challenge i quickly removed it because normally whenever i'm running these challenges we i run it i run them with debug mode on so i can see what's happening in the background and just trying to find the instruction pointer look at how this comes out with um because of the way it does a character at a time it just takes so long to run through and takes up a lot of space on the screen so i did end up just going in and changing this manually to 40 but this is how we can automatically find the offset we're just launching the process we're doing i've created a function here to calculate the to send off the negative values and get back the positive six five three three eight value that we need and then we send off the payload we wait for the programs crash and then we read the instruction pointer so again it's not really needed if you'd rather not have that there you can just take that all out there and just say instead of finding the offset just say that the offset is 40 because we went and found it manually anyway so um just in case anybody sees this big chunk of code and freaks out uh apart from that here we're just defining the binary name that we look that we're working with and we're setting the context so that throughout the program we don't need to specify whether we're dealing with 32-bit or 64-bit addresses we don't need to um worry about yeah the architecture the bits the operating system or anything like that if we're writing shell code we don't need to say this for linux or for windows because it'll know what what what type of binary it is and then here we're just setting the the debug level so that you can see so you can print out so if we change that to info we would get very little there although we should get very little anyway because i've just removed the find instruction pointer function apart from that i'm loading in the libc library here so we were given a libsy library which is going to be the libsy which is running on the server so i've just added this as a comment so that we can uncomment the local lib c and the remote lib c depending whether we're running this locally or against the server okay and with that out of the way let me paste in the rest of the payload here so we have two payloads so we launched the program we do our calc which is just going to send this off and make sure that we get to our buffer overflow and i've grabbed the pop rdi gadget here so you can go let's have a look with wrapper you can do robert dash dash file controller and then you can search so we'll search for pop rdi and you can just find the address and then put that in here you don't need to do that you can actually just you can load them in through pawn tools as well um you can go and have a look at some my scripts on github to see different ways of doing this but that's just manually defined there and our first payload we're going to be leaking we want to leak an address from the libsy library so in this case i've chosen to leak puts because we use inputs to leak the address anyway we might as well leak the address of puts and we just need to make sure it's an address of a function which has already been called or that we're calling that function we know that in this case if we go back to our main function the welcome or was it the welcome somewhere there was there was a some put statements printed out somewhere maybe it's in here menu this menu so we know that puts has been called so all that means is that in the global offset table the address will have been populated so initially these libsy library addresses like puts they'll essentially be in the plt and whenever the plt is called it'll populate the it'll go to the libsy library which is on your system um on the system of wherever the binary is running and it'll find what address offset the function which is being called is at and then it'll write it to the global offset table so that in future it knows the offset so we just need to make sure that that's already been populated or that we're populating it during a payload in order to delete that address hopefully that makes sense i'm not confusing things where i don't need don't need to be um so that's all we're doing here is we're popping into the rdi the puts got dot puts address and then we're leaking it by call inputs and then we're returning back to calculator because we want to not this calculator we're returning back to this one because we want to run through this again and us on our second payload we're going to be actually calling another libsy function so let me just comment out some of this i've probably maybe talked a bit too much there without demonstrating what's going on so we're leaking the address we grab the leaked address and then from there we look for the libsy base address because from there we can then look for the system address and things like that uh so let me just let me run that python exploit you'll see it takes a while because it's having to wait for all of the the characters to go through that process of animating but yeah we leak the gotputs address we leave the we get we get the libsy bass if we wanted to verify this we could go to our gdb script and let's say we want to in fact i don't even need to break let me let's set that up and then let's just enable this i o interactive that should be okay if i run this again with gdb and then we're waiting for it to leak the address it leaks this got puts address let me go back to gdb and there you can see then if we look for the address that equals got puts we could then go and find for example x system there's the libsy system address and we could look and find out okay well if i look for x puts minus system and that'll tell you the offset between those so essentially we i mean we're gonna find the offset from here back to the base of libsy and then from the base of libsy we can find the offset to system let me just show another way to do that so if we go and do ldd controller this is the libc library which i'm using so i can do read elf dash s and then that will print out all of these offsets and in this case we want to find out where is the system uh oops we want to grep out system i want to find where's the offset of the system function uh which is right here four eight e five zero for me so we i would find the lipsy bass which we've done right here libsy lipsy bass and then i could just say now system is equal to lip see dot address uh plus and that offset and that's now the system address but the reason i've not done that here the reason you don't need to do that is because we're loading in the libsy binary right here so once i find the libsy base address of it from then on pawn tools knows where the each function is located so that means whenever we get down to our second payload here rather than manually dealing with these offsets all i've said is just call libsy.symbols.system and the only reason it's able to do that is because we first set this libsy address hopefully that makes sense and then also similarly we look for the bin sh address in libsy because we've specified this as well and we just pop that into the rdi and then call system and that should be everything let me try and run through that run that without gdb so we leak our address and we see their problem ignored but if we look here we can see that we have a shell so the cool thing here is that if we want to test this now against the server because we're specifying the libc address libsy right here let's go and comment this out and now let's specify the remote server and we just need to call it then with the server address and port number because we have this handy template so now let's go and spawn an instance i'll show how we can shorten this down even more as well using rock objects let me just let's get this working remotely first of all take a copy of this address so we run python exploit remote and paste in that address get rid of the colon and we run that it might take a little bit longer against the server in fact i should have probably had debug mode on so you can see the progress but we've leaked the addresses and there you go switch to interactive mode but we've got an end of files so we're not itch we don't actually have a shell we're not able to run any commands i wasn't too sure what the exactly what the problem was here but i did deal with the challenge similarly to this recently whereby everything worked perfectly using the local lib c and then as soon as i switched to the service lib c i couldn't get it working even though all the offsets were correct and i verified the offsets on the libsy database and um i ended up solving that using the one gadget tool so if we i think this might actually be the same libc library it was also a high the box challenge so if we run one gadget against the lib c library and this will give some different possibilities of offsets as long as these constraints are met then it will perform this uh it'll execute this so it'll exec the bin sh so let's take this offset just like i did in the previous one and because we've now calculated the lib c base address we don't even need to do any of this let's just put in here libsy.address plus and then give it the offset of that one gadget and so long as these conditions are met which hopefully they are um it'll all work okay so we'll run that again and you'll see this time we haven't got end of file we can list this out we can print our flag.txt and there's the integer overflow saved or resources so that's that one solved another way to do it was somebody else had mentioned to me that they'd solved this rather than using the one gadget they used a similar function here but also just made sure that the rsi was cleared so if you go and run wrapper dash dash file controller and search for pop rsi so we could grab this officer and put that in as our rsi pop rsi but it's also was a pop pop rsi pop r15 so we just need to deal with that as well so we're gonna put zero into rsi and then we'll just put zero into the r15 as well and if we run that against the server that should also work for us so we leak our addresses and yeah switching to interactive mode so that also worked fine for us so i'm not sure it must be something to do with that libsy library where the rsi needs to be clear and it isn't on others i'm not too sure if anybody knows and wants to let me know in the comments i'd be interested to know some of the things to mention here um let me let me put that back to the one gadget let's go in fact i'm just gonna put this back let's put this back to the local mode for a minute i'm going to put this on we've got the flag remotely now so let's just switch back to local and i just want to show you how we could have done some of this wrap objects so let's take this out all together this pop rdi and what we'll do here is create a wrap object um from the elf file and rather than having this payload here we'll let this do the hard way for us we'll just say rop dots puts we're going to call puts and we want to leak the got elf dot dot dot puts and then we want to return to calculator so we'll call calculator and then we can just go ahead and at this offset that's what we want to send so we'll say rop.chain let's i'll print this out as well just so we can see what's happening print out rop dots chain oh sorry i'll print out rock.dump so we can just see how it's assembling that for us and then so you can see here i mean we wouldn't even we don't even need to do that payload there we can literally just take this and send that in there and have it as a nice one line payload if we want so that's our payload to to leak and then we leak our address we get back now we want to call system but now that we've got the libc address we can just say then we'll update our rop object it's now going to equal rop c and then we're going to call rock.system i'm going to search for the bin sh address in there and that should be everything so again we can take all this out make this another one-liner and just say at the offset we want to do rop.chain and i'll take that out so we don't even need a payload just send that there and let's just print this out as well so we can see what that looks like rob dot dump okay that's all looking good so python exploit i might have needed to no okay that's fine all right so we can see it's assembled the first one and it's just basically put everything together for us it's found the pop rdi gadget at this address it's um put the got puts address into the rdi and then it's called puts and then it's returned to calculator we've leaked the address we've updated the libc base address and then it's called system so it's popped the system address into the rdi oh sorry it's popped the bin sh address into the rdi and then it's called system and again that's got as a flag oh sorry not a flag a shell and that'll do it for this challenge i'm not hopefully i'll i'll be able to get another one solved here i'm kind of i want to try and get somewhat decent video out of each category if possible so i'll just try and keep each video around the sort of same length and this one's quite a lot longer than the others at the moment so hopefully we'll get on to this next challenge which is minefield the next challenge is called system drop and it says in the dark knight we managed to sneak in the plant that manages all the resources ready to deploy our root kit and stop this endless draining of the planet we accidentally triggered the alarm acid started raining from the ceiling destroying almost everything but us and a small terminal like console we see no output but it seems to work somehow so again we've got a downloadable file to get this working locally and then we have the docker instance spawned as well so let's go and take a look at the files so we check our file types first of all we have the python script here this is a script i've put together already and then the lib c file is just a lib c from the previous challenge so it didn't actually come with this one just presumed that it might be the same version and went off that although i did go and verify that on the blue cat libsy database as well and then system drop which is our actual binary we want to exploit another 64-bit executable it's not stripped no pi let's have a look at some of the other protections enabled so run checksec and we'll see there's no canary either nx is enabled so if we're able to inject shell code onto the stack we won't be able to execute it we want to probably have a look for some rock gadgets which would explain the name system drop and let's try and run the program see what happens and we run it and nothing actually happens we can type in some input here and we see if we type in some input we very very quickly get a segmentation fault so we could play around with that and see how much is required to get the segmentation fault but let's just go ahead and have a look at this engine so i've already got this opened up so it didn't look like there was too much functionality in the program anyway let's go straight to the main function and you'll notice that we don't have much code here we've got a 32 byte buffer which is declared at the beginning we have an alarm call and then we have a read call here which is reading in 256 bytes we can see here we can go and highlight this so we can convert it if we want to and that's reading 256 bytes into this 32 byte buffer which is obviously going to overflow and then it's just going to return so we could have a look to see if there are any other functions here which are of interest um but doesn't look like it doesn't like it's too much in here we do have a syscall here which is worth noting so we might want to look into calling that let's go back here um so we're going to want to go and have a look at some of the rop gadgets that are available to us obviously the the name hints at that we're not able to execute shellcode but we've got plenty of room to execute some rough gadgets so let's go and open this up in gdb phone debug and once we open this up we can run info functions to get a list of the functions here as well we might want to disassemble a function to have a look at the assembly code or grab some addresses or offsets that we can jump to later or we might want to set up some breakpoints we can break for example the main function um in this case let's generate our cyclic pattern let's work out exactly what the offset is here so i'll generate a cyclic pattern of a thousand bytes it doesn't really matter too much we just want to find out how many bytes we need to overwrite to overwrite the how many bytes we need to write to overwrite the instruction pointer so we just run the program we know that we need to paste in our input so paste in the input there and we'll see that we've got k a a a in the beginning of the stack pointer so we can take that run cyclic dash l to find out the offset and see that it's 40 bytes in so if we were to write 40 a's here and then eight b's we would see the b's in the rsp and the a's would lead up to that we'd see the bs and the rsp and then everything after the c's would be our shell code or in this case our rob gadgets and so that's cool we're going to do that in phone tools anyway we'll let pawn tools calculate this offset for us just to show that we can do that manually also when you're in gdb if we type here phone debug if you if you're using the phone debug plugin you'll get a list of different plugins and functions and things that you can run from here so a lot of these i haven't even tested out myself but we can call things like ropper from in here and get all the rop gadgets which is handy um we can search rop gadgets but i think there's it's a little bit different running it from inside here to the command line we could also open up radar from in here as well so sometimes you'll find if the functions are stripped we can't see where the main function is i would sometimes just open up red air and then we can get the main function from in here it will normally identify it anyway based on the entry point and then again we can if we want to disassemble in here we can s main we can disassemble um so yeah let's go let's go open it open let's go and open another terminal and check the rub gadgets so we can see that we have our syscall wrap gadget here if we want to search for anything specific as well we'll be able to search for if we want pop gadgets or we want to specifically pop a certain register so pop rdi is likely going to be useful pop rsi also comes in useful but obviously our three main registers to pop to um can be useful so let's go and let's let's start to set up a point tools script or i'll just open up the points script here and let's talk through what we have at the moment so as in the last challenge this is all part of the template here so if you use this template which i have on github then every time we do a challenge we'll copy this over and this can be used to find the instruction point we really don't need to because we just found it manually but um just to show that we don't actually need to find it manually we can just do this all in phone tools and we don't even need to touch the script we can just essentially send it a cyclic pattern and that'll calculate the offset for us on the fly so it just makes things quite reusable we have our gdp script here as well so we can put in breakpoints and things in there we'll calculate the pi base if we needed to in this case pi is not enabled so we don't need to worry about it and the start function will just allow us to pass in parameters through the command line so whenever we run exploit we can pass in things like remote and a server and a port number or gdb or no no slr no debug things like that um apart from that we've got a file which is being loaded we're setting the context for the files so this will mean that any time we're given addresses and functions and things like that we don't need to worry about the operating system the architecture etc and then our context.log level will just help with debugging if we have this set to debug we'll see quite a lot of output when things are being sent and received and we'll be able to see what's happening in the background and yeah with that with this set up stuff out the way let's have a look at the actual exploit here so we're loading in our libsy library again this is my local libsy library but i have the remote one that we use in the previous script so that we can easily swap between them and we have some useful gadgets defined here so these were just found with wrapper as was seen there so if we search for the pop we can find our rdi rsi and we can do the same with the syscall and these are just being loaded here i credit to my teammate for finding a solution for this we weren't too sure at the start uh in terms of the approach we were looking to see if we could inject the bin sh string onto the stack and then call xxvi with um with the with the location of that but we were having problems basically leaking the location of finding the offset of the string in the end we used a return to lib c attack so uh we have a we use a syscall here let me actually open up the syscall table and here we have the syscall for read so we're popping into the rdi 1 which let me go back to the syscall documentation so we know we can make a recall there is a recall in the program already so if we have zero in the rax which we will do because the read call because read has been used then we can provide some other parameters in this case if we go back to the script we have the rdi which is set to one so that equals the file descriptor for standard output which means we'll be able to print it to the screen we're reading from something to the screen and then what do we want to read from is going to be in the rsi so you can see here then the rsi we've we pop in the got alarm so it doesn't really matter we could just we could be sending read or we could be sending an alarm as long as we can find a foothold to something which has already been called which is going to be called which then we can find the populated address from the global global offset table so just as a reminder once one of these functions called for example alarm once the alarm is called it's going to make a it'll it'll reach out to lib c depending what version lib c is on the system and it'll find what the address of the alarm is and then once we've leaked that then we can use that offset we can use that address to calculate the address to any other function within that lip c library so yeah we pop that into the rsi we have we didn't have a gadget just to pop rsi so we need to just pop some junk into the r15 register and then we make the syscall because we now have everything in our registers which will ensure that this syscall occurs we have the zero in the rax we have the one as the file descriptor to print the standard output and then we have our address that we want to leak in the rsi so uh we want to do all that and then we want to return back to the main function or return back somewhere so that we can exploit this buffer overflow again and on the second time that we exploit the buffer overflow we'll just be doing a standard um return to libc we'll be calling system so right here we we get the leaked address we calculate the libsy base address and i'm actually assigning our libsy binary uh resigning the base address to equal the address we leak which is the alarm from the global offset table minus the libsy offset of alarms so this will be version independent so if we swap this over to the server side all we'll need to do is swap these two lines over we won't need to change anything else in the code to make it work which i think is pretty cool so yeah we'll do that we'll now have the lipstick based address so now we can just pop the bin sh address into the rdi based on whatever it is in this particular libsy library and then we can call the libsy system function which again it knows where that is because we've found the base right here so let's test this out is that set to run it's set to run locally at the moment so let's run python exploit and you can see it runs through we have debug on the mode debug mode on so we see quite a lot of output but essentially here we're calculating the offset so everything up here is just and printed out is is unimportant basically once we found the offset here we then get to uh this section of the code we're now right here and from from there on the rest is the exploit so we send off our first payload and then we receive back our uh alarm address so you can see right here 7f472077 that's the address will leak in we then calculate the libsy base and then we send off our system bin sh payload and you can see here that we've oh we haven't returned a shell uh let me go back let me try that again yeah okay we have got a shell maybe the alarm triggered at the end there or something i was leaving it too long i don't know um so yeah that works fine and as i say the cool thing is here now because we've set this up so that we can just literally swap this libc library over and run it against the server it means i can just go and copy and paste this address now and nothing else in the script should need to change all we need to do is enter remote paste that in and then run it remotely and you can see it now we've actually got into the server we can print out the flag so that's how i solve that um let's also show how we could have automated this a little better or how we could make use of some wrap objects as well so i'm just going to paste this over as well this is from just another version of the code that i put together which you can see is a little bit shorter here so rather than us putting that payload together which oh we still kind of put the payload together here but we're creating a wrap object here and then rather than manually finding the offsets of the gadgets in ropper we just find the gadgets from inside pawn tools and then we'll call rob raw so this is just the same thing we just call in uh we call in syscall after first preparing the register so we put put one in the rdi for the standard output we put the else.alarm into the rsi and then some junk into r15 and then call syscall and then we return to main so we just send that off as a payload and that'll leak us our address so everything here is the same and then we now that we've got the libc base address we just update our rop object to now point to the libsy binary and from there we can just call rock.system it'll work all this stuff out for us so i think i kind of showed this in the last foot on the last example but just go here rob dot dump and we'll be able to see exactly what this is doing we can do that here as well i was actually trying i kind of thought that because um with these rop objects you should be able to call any resolvable function so for example here rock dot read but i was trying to do rock.read and pass it in one and then the elf dot dot alarm but it wasn't actually working for me let's let's just test this out first of all maybe somebody can explain that to me okay doesn't know how to dump these ones the wrapped up raw here take that out so you can see that works we've got a shell again and essentially the the system payload you can see here we dumped that out so it just put that together for us because it was able to find the system is able to find a bin sh address and work out how to set the registers up and things like that so this isn't a great example but you see some examples where it it builds some quite complex rock chains for you again we can just take that straight to the server as well so if i go and update the libc library and run that oh run that remotely then you'll see we get our shell again also note that if we didn't know what version the ellipse library was so i just kind of assumed it was going to be the same libsy library if we didn't know what it was we would just leak out this got address we've got the we leak out the same address and then we can just go to the libsy database here and let's go and enter this in so we can go and enter in the address and just set this to alarm find and then this will find different possible live c libraries so it's actually this bottom lipsy library in this case so you can see that the alarm here is you can see the difference from the offset you can see where system is as well so that's if you want to do this manually you could just go and use this to manually calculate it what you can also do as well is potentially if you don't want to go through and test all five of these manually you could download them all and you could just set up a loop to loop through against the server and update this update you know between the various libc versions so you could kind of automate the process for that as well but yeah it would be cool if anybody can find out in terms of rather than calling rob raw here i was hoping that we would have been able to call rob dot read and then we could give the zero which we sorry one as the file descriptor which was just what we were passing in here and that will go into the rdi then the rsi we want our elf dot got dot alarm and yeah i hope i'd hoped this would work let's try and run that and just see what happens just go back to the local lib c library and it seems to be freezing there so yeah it doesn't seem to come back with anything uh so if anybody can work that out i'd be interested to know if you can because it's resolvable i guess i'm missing something here which i'm not aware of let me just do the rock dot dump there actually pretty print rob dump and then if we try that again so you can see that it looks like it's building this okay it's it's popping into the rdi it's popping one which is the file descriptor to make sure that we print the s so it reads to the sd out so it prints it out and then popping into the rsi it's got the same gadget there the rsi and r15 and it's popping up the got alarm into the rsi so it's basically doing everything the same the only difference is instead of the syscall here it calls read but um yeah if anybody can work that out i'd be interested to know anyway okay slight update actually it turns out that we weren't doing a read operation we were doing a write operation so i've already got geardra closed down so i'm not going to open up again but let's open up radar and have a quick look here if we have a look at the functions and select the main function and disassemble it and notice that right after our read call we have the eax is set to one so essentially we the main method is called it sets the alarm it reads some data from us which is where we're overflowing the buffer and then it sets the eax to one so it's enabling the which is the value needed for a right cisco rather than a read syscall so that's why let's go back to the code here that's why whenever we were let me just return that because i tried doing that with the right it still doesn't work anyway i'm doing right there but that's why we don't need to worry about setting the rax register because it's already being set to the right operation for us so i was confused there i thought we were reading to the to the output i guess that's not possible so um just like make that correction anyway before moving on

Channel: CryptoCat

Views: 1,399

Keywords: cyber apocalypse, #CyberApocalypseCTF21, hack the box, hackthebox, htb, hacking, wargames, challenges, capture the flag, ctf, pwn, binary exploitation, rop, return oriented programming, ropper, rop gadget, pwntools, pwndbg, gdb, disassembly, reversing, reverse engineering, ghidra, ltrace, debug, stack smashing, stack canary, format string vulnerability, exploit, exploit dev, infosec, security, cyber-security, kali, parrot, ida, malware, tutorial, learn, hacker, cyberchef, integer overflow, bof, buffer overflow

Id: 6DRuT1JBmBE

Length: 48min 30sec (2910 seconds)

Published: Sun Apr 25 2021