# Hacking Tube

## ASIS CTF Finals 2016 -- car market

Category: pwn
Points: 177

64 bit ELF, with Partial RELRO, Canary & NX enabled, no PIE. libc.so was provided.

The binary is a car market program. It will let us list our cars' info, add a car, remove a car and select a car. By selecting a car, we can edit our car model, price and add a customer. While adding a customer, we can set the customer's name, comment and print out the customer's info. The car and customer are defined as the following structures:

After doing some reversing & fuzzing, here's some important program behavior:

• There's a pointer struct car** ptr. The program will first use malloc to allocate a buffer and assigned to ptr, which use the buffer to store the car* array.
• Each time we add a customer to a car, the program will first check if car->customer and car->customer->comment were exist in the car. If it does, the program will free car->customer and car->customer->comment, ensure that there's only one customer in the car.
• There exist multiple off-by-one vulnerabilities while the program try to read the user input. When we input the model, first_name and the name data, we can trigger the vulnerability by entering a long length data. This will cause the first byte of the next data be overwritten to a null byte.

The first thing I try to do is to leak some address. I found that if we do the following operation, we can leak heap's base address:

3. Enter the customer menu again
4. Print out the customer info, the customer's first name will become a heap address

This is because the program will try to free the memory of car->customer before we try to enter the customer menu for the second time. After car->customer was freed, its memory chunk's fd (which is also car->customer->first_name) will be storing the next free chunk's address, so by printing out the customer's info , we can leak out the heap's address.

The next thing is to leak out the libc's address. To achieve this, I decide to corrupted fastbin by exploiting the off-by-one vulnerability. Assume that we have the following memory layout of a car->customer structure:

             +------------------+
customer     |........first_name| char first_name[32]
|..................|
|..................|
|..................|
+------------------+
customer+32  |..............name| char name[32]
|..................|
|..................|
|..................|
+------------------+
customer+64  |        0x12345680| char* comment
+------------------+



By using the off-by-one vulnerability on car->customer->name, we can overwrite the last byte of comment's address, change it from 0x12345680 to 0x12345600. Now if we exit & re-enter the customer menu, the program will try to free car->customer->comment, which is 0x12345600 instead of 0x12345680.

Now if we have the memory layout of a car structure like this:


+------------------+
car    0x123455F0 |               0x0| char model[16]
+------------------+
|              0x51|
+------------------+
car+16 0x12345600 |              0x64| long price
+------------------+
car+24 0x12345608 |        0x12348880| struct customer* customer
+------------------+


By setting the model of the car, we can fake the chunk's header, so when glibc's freeing 0x12345600, it will think that it is freeing a memory chunk with the size of 0x50, the same size as car->customer->comment, and add 0x12345600 into fastbin. This will create an Use-After-Free situation, with 0x12345600 being a dangling pointer. The next time we create a customer comment, the program will allocate 0x12345600 as the comment buffer, and thus we can modify the structure of car, changing the car->customer pointer to atoi's GOT. After that, we can leak atoi's GOT by printing the car's info.

To summarize, the following steps will help us leak out the libc's address:

1. Add a couple of cars, try to make a car's address ends with the 0xf0 byte (ex. 0x123455f0), and put the fake chunk header in car->model.
2. Exploit the off-by-one vulnerability, overwrite a comment's buffer address. (ex. 0x12345680 -> 0x12345600)
3. Exit & re-enter the customer menu, so the program will free the fake comment's address.
4. Create a new comment, the new comment's buffer will be overlapped with one of those car's memory chunk.
5. Edit comment and modify the car's structure, change the car->customer pointer to atoi's GOT.
6. Print out the car's info, leak atoi's GOT and get the libc's address.

Now we have the libc's address. Since the GOT entries are writable, we can try to overwrite atoi's GOT into system's address and do the GOT hijacking. At first I try to overwrite the GOT by using the same method as I leak atoi's GOT -- after we change the customer pointer, we can overwrite the GOT entry by modifying customer->first_name.

Except we can't. That's because when we try to do so, the program will try to free car->customer before we enter the customer menu, and doing free(atoi@got.plt) will crash the program. We'll have to find another way to overwrite the GOT. So how are we gonna do that? Well, remember the ptr variable? The pointer that points to the car* array?

Since we can modify a car's structure by editing the comment, we can once again modify car->customer, changing the pointer to ptr, so when the program free car->customer, it will free the whole car* array instead. When the next time we create a new comment, it will allocate the memory by splitting the memory chunk from ptr, making us able to control the car* array. We can then overwrite the car pointer into atoi's GOT by editing the comment. Once the car pointer is changed, we can overwrite the content by setting car->model, and that's how we hijack atoi's GOT.

So after we leak the libc's address:

1. Edit comment and modify the car's structure, change the car->customer pointer to ptr.
2. Exit & re-enter the customer menu, so the program will free the fake car->customer's address.
3. Create a new comment, the new comment's buffer will be overlapped with the car* array.
4. Edit comment and modify the car pointer, change it to atoi's GOT.
5. Overwrite atoi's GOT to system's address by setting car->model.

At last, when the program ask us to input our choice, we can input sh\x00 and execute system('sh'), spawning a shell and get the flag...right?

After I finished the exploit, I found it once again, the exploit has timeout due to the crappy internet connection. So I upload the exploit to trello and ask freetsubasa if she can send the payload for me. And then she told me that she had the shell spawned, but she can't find the flag. What ?

OK, so the ASIS organizer try to play some trick on us. It's alright, no big deal, just give us the flag so we can pass the challenge.

WHAT. THE. F*CK.

How is this even possible? The file is just right there and now you're telling me the file does not exist? This is bullsh*t !@#$%^& So after we have the shell, we spent another 30 minutes trying to figure out how to read the god damn flag. After some trial & error, teammate ddaa finally get the flag by using the cat .* command. It's strange because I've tried for f in .*;do cat$f;done and it failed, don't know why :/

Anyway we finally got the flag and the 177 points. The binary itself was a great challenge, but the command line one was kind of evil -.-

flag: ASIS{a0b8813fc566836c8b5f37fe68c684c5}