NSSCTF-Pwn-[HGAME 2023 week1]simple_shellcode

一、题目来源

NSSCTF-Pwn-[HGAME 2023 week1]simple_shellcode

二、信息搜集

发现是一个 64 位的 ELF 文件，并且保护措施基本上开全了。

三、反汇编文件开始分析

程序首先用 mmap 在虚拟内存上开辟了一片空间，该空间的访问控制权限为“可读-可写-可执行”（因为 prot 参数的值为 7）：

接着，程序调用 read 函数：

需要注意的是：这里的 read 的第二个参数和以往我们看到的不太一样，这里使用的是 mov 指令而不是 lea指令。

这也就意味着，我们真正写入 rsi 的是地址 0xcafe00000 也就是我们之前开辟的那片虚拟内存的首址。

因此，这个和栈溢出可以说的八竿子打不着了，我们接着分析。

然后，我们就可以看到本程序所使用的沙箱：

为了理解 sandbox，需要理解一下函数 prctl。

函数原型：

和其他函数有所区别的是，该函数所需要的参数即 arg2..arg5 是取决于第一个参数即 option 的，而 option 的可选项是很多的，下面我贴出的是本题所用到的两个 option：

option = 0x26 = PR_SET_NO_NEW_PRIVS：

• 含义：开启 no_new_privs 标志后，该进程及其子孙再也不能通过 execve 获得更高权限（例如 setuid 程序不再提权、文件能力不再生效）。
• 用途：装载 seccomp 过滤器时的常见前置条件（避免“先降低再抬高”的逃逸）。
• 范围：继承到子进程（fork/exec）。

option = 0x16 = PR_SET_SECCOMP：

• 含义：为当前进程启用 seccomp-BPF 过滤；arg3 指向 struct sock_fprog，里面是一组 classic BPF 指令（你题里的 5 条），用来判定每个系统调用是允许/拒绝/杀进程/返回特定 errno 等。
• 典型动作码（RET 的 k 值）：
  • SECCOMP_RET_ALLOW（放行）
  • SECCOMP_RET_KILL_PROCESS（直接杀掉当前进程）
  • SECCOMP_RET_TRAP（向用户态发 SIGSYS）
  • SECCOMP_RET_ERRNO | (errno & 0xFFFF)（让该系统调用以指定 errno 失败）
  • SECCOMP_RET_TRACE、SECCOMP_RET_USER_NOTIF（配合 ptrace / 用户态通知框架）
• 要求：通常在设置前需要 no_new_privs=1（或有 CAP_SYS_ADMIN 且系统允许的策略），否则 EINVAL/EPERM。$\Leftarrow$这是为什么本题会采用两个 prctl 的原因

其中提到的 classic BPF（cBPF） 指令指的是最早一代的 32-位“小虚拟机”指令集，它只有两个寄存器 A（累加器）和 X（索引），再加 16 个 scratch 内存槽 M[0..15]。Linux 的 seccomp-BPF 复用了这套 cBPF 指令来写“系统调用过滤器”（鉴别每次 syscall 是允许、拒绝、杀进程、返回 errno 等）。

cBPF 的每一条指令是一个 sock_filter，包含 4 个字段：

在题目中对应的部分就是那一大块 mov 指令：

解码后的 5 条 BPF 指令如下（按内存从 var_30 到 var_10 的顺序即从低到高的排序）：

1. LD W ABS 0

   [code]{ code=0x20, jt=0, jf=0, k=0 } // BPF_LD | BPF_W | BPF_ABS, 从 seccomp_data 结构偏移0处加载 syscall 编号 [/code]

   将当前系统调用号装载到累加器 A。

2. JEQ 59, jt=2, jf=0

   [code]{ code=0x15, jt=2, jf=0, k=59 } // 59 = __NR_execve (x86_64) [/code]

   如果 syscall == 59 (execve)，跳过后面两条指令（即跳到第5条）。

3. JEQ 0x142, jt=1, jf=0

   [code]{ code=0x15, jt=1, jf=0, k=0x142 } // 0x142 = 322 = __NR_execveat (x86_64) [/code]

   如果 syscall == 322 (execveat)，跳过后一条指令（也跳到第5条）。

4. RET ALLOW

   [code]{ code=0x06, jt=0, jf=0, k=0x7FFF0000 } // SECCOMP_RET_ALLOW [/code]

   上述两条件都不满足（不是 execve/execveat）→ 允许该系统调用。

5. RET KILL

   [code]{ code=0x06, jt=0, jf=0, k=0x00000000 } // SECCOMP_RET_KILL (KILL_PROCESS) [/code]

   命中第2或第3条跳转来到这里 → 直接杀掉进程。

这也就说明了，本题不允许使用的系统调用：

• execve
• execveat

当然，这一部分的分析也可以交给 AI 来快速处理：

沙盒之后，就出现一个关键点：

还记得我们一开始看到的 mmap 开辟的虚拟内存空间吗，那块的首地址就存在在 [rbp+buf] 当中，依据：

那么，如果我们能向地址 0xcafe0000 写入 shellcode，然后通过 call 一调用，就可以获取到 flag 了。

四、思路汇总

首先，我们整理一下有用的信息：

• 有一块可读可写可执行的虚拟内存，并且能向其中写入 0x10B 的数据；
• 有 call 指令；
• 存在沙盒，不允许使用 execve 和 execveat。

这么一联系，我们就可以知道本题的难点在于：

1. shellcode 的长度被限制；
2. 沙盒保护。

因此，我们的思路就是，先写入较短的 shellcode 实现再次写入且将写入的长度限制给放开，然后再写入较长的 shellcode 来获取 flag 且该 shellcode 需要符合沙盒要求。

五、Poc 构造

一步步分析，我们对第一次 shellcode 的要求就两个：

• 简短
• 实现再次写入

程序已经非常贴心地为我们准备了两行指令：

eax 中已经存放了 read 系统调用的系统调用号，rdx 中已经存放了我们要写入的位置即 0xcafe0000。

因此，为了实现再次 read，我们只需要：

这里还将写入位置进行了“加 0x10”的操作，是为了保护本轮的 shellcode不被后续的 shellcode 破坏。

可是，写入完成之后，我们就已经用完了 call 指令，那么后续还需要执行新的 shellcode 怎么做到呢？

没错，就像构造 ROP 一样，我们再后面跟上一条：

此时 rsi 中存放的依旧是地址 0xcafe0000，但是其中的内容已经通过第二次 read 修改成新的 shellcode 了。

我们可以检查一下 shellcode 的长度，我跑出来是 14，刚好满足小于 16。

后续，我们为了避免被沙盒过滤，采用 ORW 的方式来绕过。

当然，也可以直接使用：

来替换，因为 shellcraft.cat("/flag") 生成的 shellcode 使用的是“Open + Sendfile”的组合，也不会被沙盒过滤。

最终本地执行效果：

成功拿到 flag。