PlaidCTF 2014 ezhp: Heap Overflow Challenge

This weekend I had the pleasure to participate in the CTF organized by PPP team, I have only two years playing and definitely the CTFs from these guys are the best, thanks!

As usual, the idea of this blog is a 101 lesson when dealing with this kind of challenges, from Debugger setup to remote shell execution.

I will describe a pwnable 200 called ezhp that I resolved, when dealing with pwnables normally you have two types: those easy to find the vulnerability but difficult to exploit it (the ones that you just sent multiple A's and get the segmentation fault write away) and the ones easy to exploit but hard or tricky to find the vulnerability.

Introduction

So, let's start, by opening the challenge you were presented with below message:

The quote "Luckily when you travel back in time, you still get to use all your knowledge from the present", will make totally sense at the end of the blog. As usual, I am very bad with the hints so did not even read it.

So, we are dealing with a 32-bit ELF Linux binary, good! we can just fire up backtrack and run it, displaying below info:

Please enter one of the following:
1 to add a note.
2 to remove a note.
3 to change a note.
4 to print a note.
5 to quit.
Please choose an option.

So, before doing any reversing, lets step into it with a Debugger to have a better understanding, I will explain two options for this, the first one is using IDA Debugger:

Press F9 in IDA and select "Remote Linux Debugger", then configure the process options, below mine:

The next step is to copy the your linux_server binary from "dbgsrv" folder in IDA to your backtrack machine and run it:

root@bt:~/IDA# ./linux_server
IDA Linux 32-bit remote debug server(ST) v1.17. Hex-Rays (c) 2004-2013
Listening on port #23946...

Set any breakpoint in IDA(F2) and click on Debugger->Start Process (F9). You are ready to start debugging and with the power of IDA to document everything as you go!

After a lot of debugging through all the options in the menu, I realized I was able to add notes with specific size and then write to them with a different size, causing a heap header overflow, I will explain this in a minute, I had certain experience dealing with heap headers overflow so kinda know where I was going. 

Note: A chunk in this context is a space allocated in the heap and has a similar structure like this:

struct chunk {

        int prev_size; 

        int size;

        struct chunk *fd;

        struct chunk *bk;

};

Above structure is stored in the chunk header, where *fd points to the next chunk and *bk to the previous one in a double-linked list.

Before going forward a fundamental knowledge must be known, when the heap allocates new chunks in memory, it decides where to put them based on the size requested, our goal is to request adjacent chunks so that a chunk filled up with more data than expected can overflow the next one, something like this:

By looking add the code of Option 3 to change a note, we can see that the size of the data to include in the note is not restricted and therefore can overflow the current chunk overwriting also the next one:

So, in order to overflow the header of next chunk I followed below steps:

1. Option1 : Add note (ID=0 assigned)
• Size=256
2. Option2: Add note (ID=1 assigned)
• Size=256
3. Option3: to change a note
• Please give me an id: 0
• Please give me a size: 276

Important details of above steps, first, the size chosen equal to 256 is needed in order to make sure to use the whole space of the chunk and force the heap allocator to allocate a new one when adding the second note, if let's say, we would have chosen a size of 10, since too much space remaining in current chunk, a second note added would have not allocated a new chunk.

The second important point, the chunk header is 20 bytes long and is located right after the end of the previous one(if allocated with the right size), and therefore I need 256 bytes to get to the end of the written chunk plus 20 that will overwrite the header of the next one. So, after writing 276 A's to the note 1 and then trying to delete note 2 (which just got its header corrupted) I got a crash!

Program received signal SIGSEGV, Segmentation fault.

--------------------------------------------------------------------------[regs]

  EAX: 0x41414141  EBX: 0xB7FC7FF4  ECX: 0x00000001  EDX: 0x41414141  o d I t s z a P c 

  ESI: 0x00000000  EDI: 0x00000000  EBP: 0xBFFFF478  ESP: 0xBFFFF468  EIP: 0x0804873B

  CS: 0073  DS: 007B  ES: 007B  FS: 0000  GS: 0033  SS: 007B

--------------------------------------------------------------------------[code]

=> 0x804873b: mov    DWORD PTR [eax+0x4],edx

   0x804873e: cmp    DWORD PTR [ebp-0x4],0x0

   0x8048742: je     0x804874d

   0x8048744: mov    eax,DWORD PTR [ebp-0x4]

   0x8048747: mov    edx,DWORD PTR [ebp-0x8]

   0x804874a: mov    DWORD PTR [eax+0x8],edx

   0x804874d: mov    eax,ds:0x804b060

   0x8048752: mov    edx,DWORD PTR [eax+0x4]

--------------------------------------------------------------------------------

0x0804873b in ?? ()

gdb$ 

So, we know we just overflowed the header of the next chunk but what info was there, for the sake of this exercise, we will focus on three components only: size of the chunk, *fd and *bk, which are the 12 last bytes of the header (4 bytes each), that means we can influence their values, will come back to this later.

After confirming I was able to overflow the chunk(heap) header, I thought I was dealing with a typical malloc/free heap exploit challenge like this, and believe me I spent some hours going that route. After failing all my attempts I realized I gotta reverse the binary to understand exactly how the heap allocator was working, and below my findings.

Option 1: Adding a note

Every time a new chunk is added (Option 1), the allocated address is stored in a buffer (I called chunk_addresses[]) with a hardcoded address at 0x0804A060, the content of this buffer looks like:

[0] -> Address of note(chunk) 1

[1] -> Address of note(chunk) 2

[2] -> Address of note(chunk) 3

Where the array index represents the ID of the note added.

Option 3: Change a note

If I want to add content to the note 2, I need to choose Option 3 and provide the Id = 1, then the allocator will go to index (ID) inside the chunk_addresses[] buffer, get the address and start writing the content supplied by the attacker, wait a second!!!!! If I find a way to put my own address inside that buffer I can write anything anywhere, well, anywhere where the memory is writable of course. Below the scenario we want to hit, the note 2 is pointing to a different address.

[0] -> Address note 1

[1] -> note 2

[2] -> Address of note 3

Forcing the deallocator to write data in any destination we want! Write down this, we will come back in a minute.

Option 2: remove a note

These allocated chunks are handled in a double-linked list, and therefore, anytime a chunk (node) is deleted a standard process takes place as described below:

In the image above the second note (chunk in the middle ID 1) is being deleted and therefore, the deallocator will do the next steps:

1. Get the address where ID1->bk and ID1->fd are pointing to of the chunk being deleted.
2. Since ID1->bk is pointing to previous chunk ID 0, go to that chunk and change the ID0->fd to point to chunk ID2.
3. Since ID1->fd is pointing to the next chunk ID 2, go to that chunk and change the ID2->bk to point to chunk ID0.

Above steps can be seen inside Delete Option code:

Pay speciall attention on the step 1, the allocator will read the content of the pointers *bk and *fd from the chunk to be deleted, and as we saw, we can overwrite its values setting them with the destination addresses that we want! 

Written anything almost anywhere in memory

Now the next question is, what can we do with these findings? After a little bit of thinking, if we point ID2->bd to the address of the chunk_address[] buffer (see Option 3 section above), we can change its content and alter the list of allocated chunks, then we can call Option 3 to write our content to whichever address we just set. Below the scenario:

Create 3 notes, add content to note 2 and overflow it to alter headers of note 3 which will end up with below values:

*bk = 0x0804A060

*fd = 0x0804A070

Then call delete option which will end up with below chunk_addresses buffer[] located at 0x0804A060:

[0] -> Address note 1

[1] -> 0x0804A070

[2] -> Address of note 3

Then, we can call Option 3 to print the content of note 2 (index 1) and guess what? will write our data into the address pointing to 0x0804A070 ! 

Let's test if it works, and here the second way to debug the binary, when debugging with IDA, all he input entered at run time must be done via the Linux terminal which does not accept hexadecimal values so we need to create a script for that, but still we need to be able to debug the program, so, we will force the binary to listen into a socket  on port 444 with below command:

socat tcp-listen:4444,fork exec:./ezph

We can also use netcat to acomplish the same thing:

while true; do nc -vv -l -p 4444 -e ezph; done

Now we can just run our script and connect to port 4444 to send our hexadecimal input. 

s.connect(('192.168.74.123', 4444))

But we still need to debug it, so, since we are using python we can pause the script with "raw_input" function:

raw_input('Attach process with gdb here')

 Then attach the process with gdb, set any breakpoint needed and let it continue:

>ps -fea|ezph

>gdb attach

>c

Now that everything is ready, let's run the exploit and check the chunk_headers buffer:

gdb$ x/32x 804A070

0x804a070: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a080: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a090: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a0a0: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a0b0: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a0c0: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a0d0: 0x42424242 0x42424242 0x42424242 0x42424242

0x804a0e0: 0x42424242 0x42424242 0x42424242 0x42424242

So, basically what just happened was, by deleting the note 3 (ID2), we altered the address of the note 2 (ID 1) inside the chunk_buffers[] array. and force it to point to 0x0804A070 as shown below:

Great! Now we can place our shellcode in memory! But wait! how can we execute it!

Here is where option 4 comes into play.

Code Execution

The option 4 is to print the content of a note by calling puts function, so, since we can write anything anywhere, what if we overwrite the whole content of puts function with our shellcode, then print the note 1 which should call our shellcode! So, let's find puts address in the binary:

readelf --relocs ezhp

Relocation section '.rel.dyn' at offset 0x348 contains 2 entries:

 Offset     Info    Type            Sym.Value  Sym. Name

08049ff0  00000406 R_386_GLOB_DAT    00000000   __gmon_start__

0804a040  00000905 R_386_COPY        0804a040   stdout

Relocation section '.rel.plt' at offset 0x358 contains 8 entries:

 Offset     Info    Type            Sym.Value  Sym. Name

0804a000  00000107 R_386_JUMP_SLOT   00000000   read

0804a004  00000207 R_386_JUMP_SLOT   00000000   fflush

0804a008  00000307 R_386_JUMP_SLOT   00000000   puts

We find it at 0x8004a008, just an small detail to keep in mind, this address is a pointer to a pointer, which means, the first 4 bytes of our controlled buffer (shellcode) must be a valid address, which is going to be 4 bytes ahead where our shellcode starts 0x8004a00C. Below would be the execution flow:

Print note -> [0x8004a008]-> [0x8004a00C]->

So, the last step is to generate our shellcode, we can use metasploit to do that:

>msfpayload linux/x86/shell_bind_tcp LPORT=8888 P

Connecting the dots

And finally, below is the sequence to get a remote shell:

1. Option 1: Add a note
• Size:256
2. Option 1: Add a note
• Size:256
3. Option 1: Add a note
• Size:256
4. Option 3: Change a note
• ID=1
• Size:276
• Data Entered to overflow next chunk (ID2)
5. Option 2: Remove a note:
• ID=2
6. Option 3: Change a note
• ID=1
• Size:256
• Inserting our shellcode
7. Option 4: Print note
1. ID=1

And..... viola!!!!! We just need to connect to port 8888 on remote host and cat the flag:

shitty_heap_allocators_are_shitty

Hope you enjoy it as much as I did while exploiting it. 

You can find my exploit here.