ROP - Leaking LIBC address
Quick Resume
Find overflow offset
Find
POP_RDI
,PUTS_PLT
andMAIN_PLT
gadgetsUse previous gadgets lo leak the memory address of puts or another libc function and find the libc version (donwload it)
With the library, calculate the ROP and exploit it
Other tutorials and binaries to practice
This tutorial is going to exploit the code/binary proposed in this tutorial: https://tasteofsecurity.com/security/ret2libc-unknown-libc/ Another useful tutorials: https://made0x78.com/bseries-ret2libc/, https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html
Code
Filename: vuln.c
ROP - Leaking LIBC template
I'm going to use the code located here to make the exploit. Download the exploit and place it in the same directory as the vulnerable binary and give the needed data to the script:
ROP - Leaking LIBC template1- Finding the offset
The template need an offset before continuing with the exploit. If any is provided it will execute the necessary code to find it (by default OFFSET = ""
):
Execute python template.py
a GDB console will be opened with the program being crashed. Inside that GDB console execute x/wx $rsp
to get the bytes that were going to overwrite the RIP. Finally get the offset using a python console:
After finding the offset (in this case 40) change the OFFSET variable inside the template using that value.
OFFSET = "A" * 40
Another way would be to use: pattern create 1000
-- execute until ret -- pattern seach $rsp
from GEF.
2- Finding Gadgets
Now we need to find ROP gadgets inside the binary. This ROP gadgets will be useful to call puts
to find the libc being used, and later to launch the final exploit.
The PUTS_PLT
is needed to call the function puts.
The MAIN_PLT
is needed to call the main function again after one interaction to exploit the overflow again (infinite rounds of exploitation). It is used at the end of each ROP to call the program again.
The POP_RDI is needed to pass a parameter to the called function.
In this step you don't need to execute anything as everything will be found by pwntools during the execution.
3- Finding LIBC library
Now is time to find which version of the libc library is being used. To do so we are going to leak the address in memory of the function puts
and then we are going to search in which library version the puts version is in that address.
To do so, the most important line of the executed code is:
This will send some bytes util overwriting the RIP is possible: OFFSET
.
Then, it will set the address of the gadget POP_RDI
so the next address (FUNC_GOT
) will be saved in the RDI registry. This is because we want to call puts passing it the address of the PUTS_GOT
as the address in memory of puts function is saved in the address pointing by PUTS_GOT
.
After that, PUTS_PLT
will be called (with PUTS_GOT
inside the RDI) so puts will read the content inside PUTS_GOT
(the address of puts function in memory) and will print it out.
Finally, main function is called again so we can exploit the overflow again.
This way we have tricked puts function to print out the address in memory of the function puts (which is inside libc library). Now that we have that address we can search which libc version is being used.
As we are exploiting some local binary it is not needed to figure out which version of libc is being used (just find the library in /lib/x86_64-linux-gnu/libc.so.6
).
But, in a remote exploit case I will explain here how can you find it:
3.1- Searching for libc version (1)
You can search which library is being used in the web page: https://libc.blukat.me/ It will also allow you to download the discovered version of libc
3.2- Searching for libc version (2)
You can also do:
$ git clone https://github.com/niklasb/libc-database.git
$ cd libc-database
$ ./get
This will take some time, be patient. For this to work we need:
Libc symbol name:
puts
Leaked libc adddress:
0x7ff629878690
We can figure out which libc that is most likely used.
We get 2 matches (you should try the second one if the first one is not working). Download the first one:
Copy the libc from libs/libc6_2.23-0ubuntu10_amd64/libc-2.23.so
to our working directory.
3.3- Other functions to leak
4- Finding based libc address & exploiting
At this point we should know the libc library used. As we are exploiting a local binary I will use just:/lib/x86_64-linux-gnu/libc.so.6
So, at the begging of template.py
change the libc variable to: libc = ELF("/lib/x86_64-linux-gnu/libc.so.6") #Set library path when know it
Giving the path to the libc library the rest of the exploit is going to be automatically calculated.
Inside the get_addr
function the base address of libc is going to be calculated:
Then, the address to the function system
and the address to the string "/bin/sh" are going to be calculated from the base address of libc and given the libc library.
Finally, the /bin/sh execution exploit is going to be prepared sent:
Let's explain this final ROP.
The last ROP (rop1
) ended calling again the main function, then we can exploit again the overflow (that's why the OFFSET
is here again). Then, we want to call POP_RDI
pointing to the addres of "/bin/sh" (BINSH
) and call system function (SYSTEM
) because the address of "/bin/sh" will be passed as a parameter.
Finally, the address of exit function is called so the process exists nicely and any alert is generated.
This way the exploit will execute a /bin/sh shell.
4(2)- Using ONE_GADGET
You could also use ONE_GADGET to obtain a shell instead of using system and "/bin/sh". ONE_GADGET will find inside the libc library some way to obtain a shell using just one ROP address.
However, normally there are some constrains, the most common ones and easy to avoid are like [rsp+0x30] == NULL
As you control the values inside the RSP you just have to send some more NULL values so the constrain is avoided.
EXPLOIT FILE
You can find a template to exploit this vulnerability here:
ROP - Leaking LIBC templateCommon problems
MAIN_PLT = elf.symbols['main'] not found
If the "main" symbol does not exist. Then you can just where is the main code:
and set the address manually:
Puts not found
If the binary is not using Puts you should check if it is using
sh: 1: %s%s%s%s%s%s%s%s: not found
sh: 1: %s%s%s%s%s%s%s%s: not found
If you find this error after creating all the exploit: sh: 1: %s%s%s%s%s%s%s%s: not found
Try to subtract 64 bytes to the address of "/bin/sh":
Last updated