Skip to main content

Introduction to Heap Overflow part 2 (use-after-free) (ง'̀-'́)ง (day 75)


Hi guys back again with the introduction of Heap Overflow, this time we move to the third challenge of the heap protostar challenge "Heap 2"

Static Analysis:

Before we move into the exploitation, let's take a look at the source code first and do a little bit of analysis


  1. At the start of the main function, we immediately enter an infinite loop and then there is a fgets function that will be used to store your input into the "line" variable. Notice that fgets is a safe function since it has a size limitation that enables the program to allocate enough memory without getting the risk of buffer overflow 
  2. After accepting our input the program will compare the value with 4 string which is "auth ", "reset", "service" and "login". If we choose "auth " options it will allocate memory in the heap for "auth" struct with malloc and then fill the memory with a bunch of zeroes using memset(). Finally, the program will take any data that comes after "auth " and stored it into the heap memory that was just reserved earlier.
  3. If we choose to input "reset" it will free the heap memory using free() and then back to the loop again
  4. If we choose to input "service" it will store the input after "service" to the heap memory using strdup().
  5. Last will be "login" that will check the "auth" value if it contains any data or not. Our goal is to fill the "auth" variable in order to pass heap2 challenge but how do we do that? since this variable is never touched by the program in the first place

 Dynamic Analysis:

Let's try to run the program so we know exactly what we are dealing with



from the above figure, you can see that the program tell us where the program store our input (auth and service), for example, the first input will be stored at 0x804c008 and next input will be put to the next 10 bytes



strange things happen when we send "reset" to the program and enter another value, as you can see that both of the variables now store at the same place

what you just witness here is the "use-after-free" vulnerabilities in heap vulnerabilities. According to owasp community guideline(link: https://owasp.org/www-community/vulnerabilities/Using_freed_memory) it is a bad idea to reference memory after it has been freed this could lead to crash or undefined program behavior

"use-after-free" occur when we free() the auth variable by inputting "reset" but the program still use the memory to do some checking



let's load it into GDB to get a closer look

we will put a breakpoint into these two locations so we know how the program fills the heap using our input.







at the first breakpoint, our input is stored at 0x804c008



but do you notice something strange?

take a look at the size of the allocation at the left side (0x00000011)  it should allocate memory more than that since struct consist of 32 bytes of char and integer. Why this is happening?

this is happening due to using the same name of a variable across the code that eventually confused the compiler on how it should correctly set the memory for each variable for the program



back again to the debugging let's try to free the memory and then input some value to it again



after we reset the heap memory of "auth" we can see that the program store our value to the previous location and if we do it again-again it will eventually replace the value of "auth-auth" and when enter "login" it will said that we already log in cool :)







but wait how do we know the exact location of "auth-auth", well it's pretty simple, take a look at the last section program.



this piece of assembly code is equivalent to if(auth->auth)

we can see that before comparing the value the program moves the content of the location "eax+0x20" to eax register. this eax register is actually pointing to our "auth" struct and by adding it with 0x20 it actually reference it to the integer "auth" variable inside the struct. We can take a look at the actual address in the following way.



Cool :) we just experience how one poor programming practice can screw up the entire program LOL

Hope you enjoy this

see you at the next blog post

Labels:

Comments

Post a Comment

Popular posts from this blog

Having fun analyzing nginx log to find malicious attacker in the net (ง'̀-'́)ง (day 37)

  What makes you sleepless at night? is it because of a ghost or scary stories? is it because you have an important meeting tomorrow? or is it because you have an exam? For me, what keeps me up all night is that I keep thinking about what happens to a website that I just created, is it safe from an attacker (certainly not) or did I missing some security adjustments that lead to vulnerability? well I'm not the best secure programmer in the world, I'm still learning and there is a big possibility that I can make a mistake but for me, a mistake can be a valuable investment to myself or yourself to be better so from this idea, I want to know more about what attackers casually do when attacking a website. Here in this post, I'm going to show you how I analyzed attack to the website that I have permission to design and also some interesting findings that I could get from the analysis Background: All of this analysis comes from the traffic that is targeted to th...
Post a Comment
Read More »

Utilize Pwntools for crafting ROP chain :') (day 69)

who doesn't like pwntools? it is a very versatile tool and can be customized according to our need using the python script but did you need to know that pwntools itself can help us to automatically craft a rop chain for us? so in this post, I will show you how to make rop chain less painful and make pwntools do all the heavy lifting. To demonstrate this I will use the binary challenge callme 64 bit from ropemporium link: https://ropemporium.com/challenge/callme.html Crashing the app: Like any other exploitation process, we need to crash the program by generating a long string pattern to determine the offset. based on the information from the above figure we can see that we required to provide 40 bytes of offset Fun stuff: now this where the fun stuff began write the following python script: as in the guideline of the challenged said we need to chain the function call by first to call the callme_one function, callme_two function and then callme_three funct...
Post a Comment
Read More »

Bypassing stack canaries protection :') (day 51)

In my previous blogs, I show you guys how to bypass some common protection usually used in Linux binary such as NX and ASLR but this time we are going to take it to the next level we are going to talk about protection employ in the modern Linux OS which is "The Canaries" and how to bypass it. note: this post was not originally mined it was inspired by the following resources https://ctf-wiki.github.io/ctf-wiki/pwn/linux/mitigation/canary/ (Credit goes to the author) we are going to start this post about what is stack canaries and types of different implementation of it then move to the implementation about how to bypass this protection. We are going to focus on "leak canaries" technique What is stack canary: In layman terms, canaries are just another protection mechanism to prevent stack overflow implemented by appending 4/8 bytes value (depend on the architecture) into the stack when a function is entered. When the function is at the end of its exec...
Post a Comment
Read More »