↓Skip to main content
  1. Posts/

Hack-A-Sat 2: tree in the forest

·728 words·4 mins

Upon connecting to the challenge and providing our ticket, we’re presented with a simple message.

Starting up Service on udp:18.222.149.188:12752

We can connect to this server using nc -u 18.222.149.188 12752 and see what the challenge looks like. After experimenting with a bit of random input, we can quickly see that the server is expecting 8 bytes of input.

$ nc -u 18.222.149.188 12752
555555
Invalid length of command header, expected 8 but got 7
5555555
Command header acknowledge: version:13621 type:13621 id:171259189
Invalid id:171259189
55555555
Command header acknowledge: version:13621 type:13621 id:892679477
Invalid id:892679477

The challenge page provides us with the source code (parser.c) for this server, which easily illuminates what’s going on. The server is expecting us to provide a command_header struct composed of three values:

  • A 16-bit integer for the version of the command. Not used within the program.
  • A 16-bit integer for the type of the command. Not used within the program.
  • A 32-bit integer for the ID of the command. This is the only value used by the program. Valid IDs are defined within the command_id_type enum.

Looking through the possible IDs, the most interesting one is COMMAND_GETKEYS with an ID of 9. This command is what will order the server to print out the flag. However, the server has locked down this functionality on startup using a variable lock_state initialized to LOCKED - a value of 1. Until we can set this variable to 0, the server will refuse to print out the flag.

After analyzing the source code for this server, we discover the vulnerable portion of this code on line 134, which is:

// Log the message in the command log
command_log[header->id]++;

Under normal operations, this array is simply used to track how many times a certain command ID has been received. For instance, to see how many times COMMAND_GETKEYS has been issued, we would access command_log[9]. What makes this exploitable is that C and C++ do not perform bounds-checking by default when accessing an array. In addition, we have full control over what ID is sent to this line of code. So by providing a value outside the bounds of this array, such as negative values, we can modify any memory throughout the program.

Our goal is to determine how many bytes before or after command_log is lock_state located. By knowing this, we will be able to determine the correct ID to use in order to modify the lock_state value. To assist in our analysis, we can compile the provided source code using g++ and debug it using gdb. But before doing this, we uncomment lines 157 and 158 to display the memory addresses for lock_state and command_log when we run the program.

$ g++ parser.c

$ ./a.out
Address of lock_state:       0x56070625c130
Address of command_log: 0x56070625c138
Trying to bind to socket.
Bound to socket.

Looking at this, we can see that lock_state is only 8 bytes behind command_log. So by sending an ID value of -8, we will be able to increment the lock_state variable by 1 on every command. The issue right now is that we can only increase the value of lock_state. Since lock_state starts at 1, we will need to overflow this byte in order to reach our desired value of 0. Thankfully, command_log is defined as an array of char values, so its max value is only 255.

One thing to note is that until now, we’ve only been directly typing input for the server into a nc session. However, since the server only looks at the underlying bytes it receives, it’ll interpret our “-8” as 0x382d0000. So to send a properly formatted payload, we will need to create a simple Python script to construct our message at the byte-level and send it to the server. This is a very simple task using pwntools.

from pwn import *

io = remote('0.0.0.0', 54321, typ='udp')
io.send( p16(1) + p16(1) + p32(-8, sign='signed') )
print(io.recvline())
print(io.recvline())

Using this script, we can validate the exploitation method by examining the server’s memory with gdb. In the following demo, we send the malicious command_header a few times to demonstrate how we’re able to increment the lock_state variable.

The next demo shows how the value overflows after 255 commands.

Finally, we can send our GETKEYS command and retrieve the flag from the server. The following demo shows us running the final exploit script (forest.py):