kanari

Solved by : grb

Now we movin' to the real deal here. This is what the challenge looks like, and there's a binary file and a Dockerfile attached with it.

Too hard? Heh, I dont think so.

As always, lets open up the binary under IDA.

So here we can see that the vuln function accepts 2 input. One input is passed to printf, leading to format string attacks, and the other one, uses read, will lead us to ret2win attack. On the vuln function, we can also see that it looks like the binary have canary enabled, lets check it using checksec.

No biggo problemo, because we have the format string attack, we must be able to leak 'em canary! I created a simple pwntool script to let me fuzz 'em format strings! This will help us determine the location of our leaks. You can check it here. Running it will give us...

So, the way my fuzzer works is that it will use the %N$p format string where N is our offset, and it will compare the leak from the remote machine and the local binary. What we need to look for here is to find matching sub-page offset (essentially means matching 3 last digits.) because if it does match, it usually lead to an internal function. For example here, we found that in offset 19, we have a matching sub-page offset, a matching 3 last digit.

We could validate this address by checking it on gdb.

So as we can see, the sub-page offset or the last 3 digit number is matching with the one that we fuzzed before, and it leads us to the main function, but unfortunately the address is not the starting address of the main function, rather an address inside the scope of the main function. We actually could use this but when I solved this challenge, I forgot about this and ended up using another leak.

So, I ended up using offset 23, which as you can see below, have a matching last 3 digit number between the remote and the local, and when checked on gdb, actually lead us to the actual main function address.

So, we figured on how to leak the main function address, which we could use to leak the base address of the ELF binary, essentially a PIE leak, YAYY!!! Next, lets figure out on how to leak the canary. So, remember that offset 19 leak, that lead us to an address inside the scope of main function? Well thats actually the return address from the vuln function. That's where the RIP will land when the vuln function returned.

With this piece of information, we could check out the stack layout of the vuln function from IDA.

And because we know the layout of the stack location, if the RIP is at offset 19, then the canary is at offset 17. Equipped with all of this information, we could continue to the next step. As usual, because this is a 64-bit binary, we need a ret gadget for alignment. Lets find the RVA/offset using ROPgadget.

Now, lets build our final exploit. This is what the exploit does :

1. Leak main function address and canary using %23$p %19$p format string
2. Calculate base address by substracting the main RVA/offset from the main function address leak.
3. Calculate win function address by adding the base address with win RVA/offset
4. Build our payload that will look like this

[72 BYTES STACK SMASH]
[LEAKED CANARY]
[8 BYTES STACK SMASH (RBP)]
[RET GADGET ADDR]
[WIN ADDR]

You can check out the full pwntools script for the exploit here. And when we run the exploit...

PO- PO- PO- PWNED!!! WHAT A FUN JOURNEY HEH!