Try the challenge thoroughly before reading the write-up. Otherwise, it's your loss.
We ssh to [email protected] and authenticate using the password we had obtained after solving the previous level.
Recap of previous level.
The recap tells us an important resource for shellcodes: shell-storm’s shellcode database. Other good resources include: exploit-db, packetstorm. The solution in the recap has directly used one of these shellcodes. We however had gone through the entire process of writing the shellcode and I think that was much more fun.
The story tells us that there is a vulnerable service running at nc 127.0.0.1 2988. So we access this service and see what it does.
So the service echoes what we input(along with a banter) and exits. We go ahead and examine the source code.
So it seems to be a simple format string bug, since it is directly printing the buffer in printf(buffer); without any format-string specifiers. I had read a bit about this vulnerability, but had never actually exploited it. Now seemed to be a good chance.
So I copied the source code and ran it at my home turf(my own PC) where I had the luxury of using a password that I know already and tools like peda in my hands. I modified the location of the .pass file in the source code and also created a .pass file in the directory.
On reading upon the format string bug, I got to know that the %x format-specifier leaks the stack information. So using this knowledge…
So yes, it is leaking some data. Let’s try to figure out the address of the password, so that we can then use the %s format specifier and read the data at that address. We’ll set a breakpoint just before the printf(buffer); is executed and examine the stack there.
It is quite clear from peda’s output that the password is located at 0xffffcd78. And the string that we have input is printed at the 14th position on the stack(Notice the 41414141).
We know that we can read from a memory address using the %s format specifier. We’ll have to input the address 0xffffcd78 in our string and %s at the 14th position so that we are able to read the value at that address.
Let’s try this out.
And yes, we are able to successfully leak the password present at the address 0xffffcd78.
However the address will obviously be different on the gracker machine. The trick is that even though the address might be different, the differences between the addresses will be nearly same. The 3rd value on the stack(from our output) is ffffcd88. So it is a fair enough conclusion that the password will be present near the 3rd address - 0x10 on the gracker machine too. Let’s see if we are correct.
The address output was 0xffffdc20 and so we try to read the value at the address 0xffffdc10. And yes, we do get a part of the password. However that seems to be too small to be the password. Let’s try some nearby address. How about 0xffffdc06?
And Voila! We have the password to the next level. I am not revealing the password here so that the readers try the challenge on their own. This was a really long way to solve this challenge, but it was fun too and we learned a lot along the way.