Skip to content

BCTF – bcloud – exploit 200

Challenge
BCTF – bcloud – exploit 200

Category
Heap overflow

I solved this challenge after the CTF but it is one of the first challenges I solve in heap overflow. I decided to share my solution because I couldn’t find good write-ups about this challenge. There are only two write-ups
1- Japanese write-up http://shift-crops.hatenablog.com/entry/2016/03/21/171249 
2- http://rex.sex/ctf/2016/bctf/bcloud/ex.py >> only the exploit

Basically, the main source I’ve used to exploit was https://sploitfun.wordpress.com/2015/03/04/heap-overflow-using-malloc-maleficarum/

In the article above, there are different techniquess to exploit Heap overflow vulnerabilities. In order to solve this challenge, we will use the following technique House of Force. 

House of Force technique requires 3 main prerequisites:
1- Attacker should be able to control the size of Top Chunk. This is usually achieved by a heap overflow
2- Attacker can call malloc() with user defined size i.e., malloc(user_input)
3- Attacker can call malloc() and fill the malloc’d data with attacker’s input

If the previous 3 prerequisites exist, we can exploit Heap overflow Using House of Force.

 The vulnerability
From disassembling the code, the main vulnerability is at the function located in 0x804868D
The function basically takes three parameters: target address, maximum size n and a terminator character. The function reads from stdin and copies byte by byte to the target address until it reaches max size n or it reaches the terminator. The main vulnerability in the function is off-by one buffer overflowSimply, when a secure function reads n characters and stores them into a buffer, the function should read n-1 chars and append a null byte at location n. However, the custom made vulnerable read function reads n chars and appends the null byte at location n+1.

Because of the previous vulnerability, we can leak the starting address of the heap when giving the application our name which is at address  0x80487A1 (initialise_name). If we initialised our name with "A"*64 (64 A chars)  The printf function will print “A”*64 + starting_heap_address

 

The next function which is at location  0x804884E  (initialise_host_org) uses the same vulnerable read function. From analysing the code, you can see that you can overflow the heap and overwrite the TOP chunk header.
PoC:
1- Org: “A”*64
2- Host:  “B”*64
3- Create note with any size
4- Delete that note you will get the following error

Screen Shot 2016-03-27 at 11.14.37 PM

From initialise_host_org, we can see that we can control the TOP chunk which is the main and first prerequisite for House of Force technique.

The second prerequisite is basically to be able to call malloc() with a size specified by the user. We simply can do that by creating a new note.

The third prerequisite is to create malloc with content controlled by the user. We can also do that by creating a note and fill it with our content.

Exploitation

To exploit:
1- Name: “A”*64
2- Leak start_heap_address
3- Org: “B”*64 <<< to cause heap buffer overflow
4- Host: “\xff\xff\xff\xff” << this will be new size of the TOP chunk (1st prerequisite)
At this point we can overwrite any value in the GOT table. Our goal basically is to overwrite any of the functions pointer in GOT table, such as atoi, printf with system address. However we don’t know the address of system because ASLR is enabled. To solve that, we need a leak in libc to calculate the address of system during the run time.

Libc Leak
To leak addresses from libc, I decided to overwrite the address of atoi in the GOT with the address of printf got.plt. The address of printf is static because the code isn’t compiled with PIE. By overwriting the address of atoi with printf, everytime we send our options, it is sent to printf(user_input) instead of atoi(user_input). Now, we have created a string format vulnerability which we can use to leak information about libc. By dumping data from the stack using "%x"  format specifier we can see that _IO_2_1_stderr is located in the stack at position number 24. As a result, by simply passing %24$8x we will leak _IO_2_1_stderr  during run-time. Because libc was provided so we can extract the following

After the leakage, we can calculate

No we have the address of system in run-time, all we need to do is to overwrite the GOT table again. This time is simple because we have our heap chunk looking at atoi-0x4. So all we need to do is to edit our note with id = 1 and send the address of system instead of printf that we sent earlier.
At this point, every time we call atoi(user_input) <==> system(user_input).

Code

Screen Shot 2016-03-27 at 11.39.00 PM

Published inwriteups

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

nine + six =