choiys

이번 문제 또한 Level4와 동일하게 ROP를 이용한 풀이입니다.

ROP에 대한 기본 지식이 없을 경우 아래 글을 먼저 보고 오시면 됩니다.

(http://choiys.tistory.com/7)

바로 시작하죠!

이번 문제는 Local 환경에서의 ROP가 아닌 Remote ROP가 나왔네요. 왠지 이전 Level과 동일한 방법으로 접근하면 쉘을 획득 할 수 있을 것 같아 보입니다.

ppr 가젯부터 차근차근 하나씩 정보를 모아보도록 하겠습니다.

[*] ppr gadget : 0x80484f3

[*] printf@plt : 0x8048408

[*] strcpy@plt : 0x8048438

[*] Address of system(system@got after calling func) : 0x7507c0

[*] printf@got : 0x804984c

/bin/sh의 주소를 구하는 find.c입니다.

[*] Address of /bin/sh : 0x833603

[*] c0 : 0x80483f4

[*] 07 : 0x804817c

[*] 75 : 0x80482b4

[*] 00 : 0x8049804

위에서 구한 정보를 토대로 payload를 작성하면 아래와 같습니다.

payload :

A*268 + strcpy + ppr + printf@got+0 + address of c0

+ strcpy + ppr + printf@got+1 + address of 07

+ strcpy + ppr + printf@got+2 + address of 75

+ strcpy + ppr + printf@got+3 + address of 00

+ printf@plt + dummy(4byte) + address of /bin/sh

임시로 Local에서 payload대로 보내봤지만, Segmentation fault 응답을 받습니다.

뭔가 payload 상 문제가 없는 지 확인해보았지만 찾을 수 없어 gdb로 디버깅 하여 값의 변동을 확인 해 보았습니다.

그 결과, strcpy 함수에서 ppr 가젯을 수행 후 다시 strcpy 함수를 실행 할 때 strcpy 함수가 아닌 strchr 함수를 실행하는 것을 확인하였습니다.

의심 가는 부분은 역시 strcpy 함수로 printf 함수의 GOT를 건드릴 때 뭔가 문제가 생긴 것 같아 보입니다. GOT를 확인 해 보죠.

아니나 다를까, strcpy 함수의 PLT를 따라 GOT로 가 보니, 0x783880 이어야 하는 값이 0x783800이 되어 있었습니다!

첫 RTL에서 문제가 발생하여 strcpy 함수의 GOT가 Overwrite 되었으니, printf@got에 0xc0를 Overwrite 하는 과정에서 잘못 된 것 같습니다. 아마 strcpy 함수는 NULL Byte가 올 때 까지를 문자열로 판별하여 덮어 씌우므로, NULL Byte의 위치가 너무 뒤쪽에 있어서 strcpy 함수의 위치까지 덮어 씌워진 것으로 보입니다. Objdump로 한 번 확인해보도록 합시다.

역시, 우리가 사용 한 0x80483f4의 위치에 있는 c0는 0x00(NULL)이 근처에 없었습니다. 눈 앞에 있는 c0만 보고 사용 한 제 잘못이었습니다... 멀찌감치 떨어져있었군요.. GOT에 Overwrite 된 값도 이 값과 동일한 것을 보니 확실 해 졌습니다.

그럼 c0값을 다른 부분에서 찾아 사용해보죠! 이번에는 NULL Byte가 근처에 있는 c0를 사용해보도록 합시다.

[*] c0 : 0x80484d0

c0의 값을 변경하여 Local에서 exploit 했더니 정상적으로 shell이 따진 것을 확인하였습니다! 이제 Remote 환경에서 nc나 telnet을 이용하여 exploit 하면 dark_stone 권한으로 쉘이 따질 것입니다.