Exploit Harvesting at DefCon 20 CTF

The setting for this scenario was DefCon 20 “Capture The Flag” in Las Vegas.  Each server was set up with a spanning port so that each team could see traffic for their server, and we had a notification system set up so that if we saw one of our secret keys going off the wire, our packet capture system would dump the last minute of traffic into a PCAP file for analysis.  We will focus on an exploit that was detected against a service named “coney”.

Once the exploit was seen on the wire, the packet captures revealed the following:

(The red is sent from the attacker and the blue is the server response.)  The key is the 32-byte ASCII sequence on the 5^th from the bottom line, which is what triggered the notification system that the service was being exploited.  So, analyzing the packet capture, there is a question response system:

ATTACKER: “I’m internet famous!\n” (authentication)

SERVER: 16-byte key

SERVER: “enter ip:”
ATTACKER: “dc20:c7f:2012:f:0:0:0:22” (attacker’s IP for the server to connect back to)

SERVER: “knock knock!”

ATTACKER: 32-byte key (authentication)

ATTACKER: (exploit)

SERVER: key + adjacent RAM

The first problem to overcome is that the server gives the client a 16-byte key, but expects a 32 byte one in order to reach the vulnerable code-path.  Upon observation, the keys change every connection, governed by /dev/urandom.  Running this shows that the server is kind enough to send 2 UDP packets 24 bytes long to the IPv6 address specified by the attacker.  Each UDP packet has the same 16-byte key that was in the original connection, but appended is another 8 bytes.  Concatenated together {original 16 byte key} + {8 byte key from UDP1} + {8 byte key from UDP2} == 32-byte key to get to the exploitable code.  Unfortunately, the UDP packets sent to the attacker are sent to random addresses.  The potential for guessing the ports is one pathway to pursue to solve this problem, but the easy (and most quickly implemented) is to listen on all UDP ports 1-65535.  We now know how to reach the exploitable code path and can go about dis-assembling the exploit!

From just a cursory look, the exploit is sandwiched in-between a NOP sled and a bunch of return addresses.  The many 0xBA’s result in 5-byte instructions “0xBA 0xBABABABA”, in assembly: mov dx, 0xBABABABA.  We can assume this is a sled for EIP to hit once the overflow happens, and the 0x16ce9595’s at the end are the part of an overflow that overwrites a return address and causes execution to land in the sled.

Note, the theme of the contest is “everything sheep”, and so the creators of the exploit paid homage to the contest organizers with their “BA BA” sled.

The next step is to extract the exploit and analyze it.  Sometimes this is not the simplest process, as most exploits rely on weird little tricks to compensate for the lack of knowledge about where they are in memory space.  Here is a sample disassembly in IDA: 

and since I don't have a big monitor and it chopped the bottom:

Without looking those far jumps and calls, we can assume the following:

1.     Since the exploit has its strings imbedded in it, it needs to get a reference to the stack so it can use them for function calls.  The string at 0x03e4 -> 0x03f7 could be such a string.

2.     The exploit has to either get references to the import table so that it can call functions that the program uses, or it has to call absolute addresses to do things.  In this case, it looks like it is using an absolute reference to the programs function table.

3.     From the packet capture, the key is printed out, and then some RAM.  This could be two things: the key has been read into memory adjacent to the exploit’s reference to the key file or the key file has been referenced by the program and the exploit is just using a reference to the string to call a read.  We will assume the former, and not the latter (for the moment).

The first jump is most likely a call to a reference giving instruction inside of the programs TEXT segment to get the address of the stack.  The next two calls we can determine by the following criteria: The exploit does not have another string of bytes inside of it (indicating it doesn’t overwrite our key), so we can assume the exploits goal is to print out the key file in the current working directory, and the key is 32-bytes long (0x20 hex).  It then needs to print out this key on the current socket.  So, the following calls are needed:

1.     file_handle = OPEN(“/home/coney/key”, “r”)

2.     storage_area = READ(file_handle, 32 bytes)

3.     WRITE(socket_handle, &storage_area)

4.     Exit / crash

Near the bottom of the exploit listing, there are 3 interesting adds: 0x4f474542 + 0x4f444549 + 0x81534f41.  The potential exists that, despite IDA saying that those instructions are valid, it is actually a string.  Pulling the last 32 bytes and brute force xor’ing them revealed that following about the last 15 bytes: “^EBEGO^EIEDOS^EAOS” xor 0x2a == “/home/coney/key”.  That would be the string needed for the OPEN call.

Re-analyzing the program in light of this in IDA reveals the following:

With this understanding, we can see that the program jumps down to the bottom (0x000003e4) to get a reference to the stack, then back to the decryption section in the middle of the program, the decryption section xors the encrypted “/home/coney/key” string, then jumps to the OPEN call (0x000003a4), which then follows on to the read call (0x00003ac), then to the WRITE(socket, data) call (0x00003c5).

Now that the exploit is fully understood, re-using it is trivial.  Since the exploit is kind enough to re-use the socket file handle and write the key back onto it, there is no need to alter it in order to immediately start exploiting other team’s servers!  Overwriting their keys or gaining a shell is the next step, and since we know where code execution begins within the exploit, all we have to do is substitute the existing shell code with our own, making sure to respect the correct offsets and space requirements.