Remote or Local Format String 하기 전 반드시 알고 넘어 가야 할 요소들 By dibi Remote Daemon 공격은 자신의 플랫폼에서 테스트하여 비슷한 시스템에게 공격 하는 방식으로 Exploit을 작성 할 수 있다. 즉, 임의로 만들어진 Daemon은 공격하기 무척 까다로울 수 있으며 만약, 임의의 취약성 Daemon의 source가 공개 되어 있다면 그것을 비슷한 시스템에 갖다 놓고 테스트 해 볼 수 있을 것이다. 해킹 대회 때 임의의 취약한 Daemon source를 open한 이유도 비슷한 맥락이라 할 수 있다. 다시 말해 그 source를 가지고 비슷한 공격자의 local 시스템에서 compile을 하고 dump를 시켜 보고 exploit을 작성 하여 real 해킹 서버에 적용 시키는 방법이다. GCC 2.96 기반의 Stack Format String을 공부하며 분명하게 Return Address를 덮어 씌웠음에도 불구하고 쉽게 해킹에 성공 하기 어려웠을 것이다. 얼마 전의 Buffer overflow 해킹 강의에서도 Return Address에서 약 100만큼을 EGG 주소로 덮어 씌워 버리는 방법을 썼다. 하지만, Format String에서는 앞의 길이를 이용하여 민감하게 계산해야 하기 때문에 막무가내 덮어씌우기가 쉽지는 않다. (차라리 .dtors 영역을 덮어 씌우는 것이 훨씬 쉬울 것이다.) 이렇게 Return Address를 찾기가 어려웠고, 그 이유조차 알 수 없었다. 그러나, 알고 보니 그 이유인즉 2.96의 Stack은 그 이하 버전과 틀리게 사용 된다. 2.96기반의 Stack은 왜 이렇게 쓰레기(garbage)값이 군데군데 생겨 나서 Stack을 사용하는지 도무지 이해가 안 갔지만, 자세하게 그 규칙성에 대해 돌아 보니 더 깨끗(?)하게 정리 하며 사용 되는 것 같다. 그럼, 그런 규칙성이나 Stack의 구조를 다시 한번 상기 하며 알아 보겠다. (2.96 이후 버전에서 테스트 해보지 못함) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~소스 화면~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ;우리를 이해 하기 쉽도록 만든 소스 #include #include "dumpcode.h" #define X 20 /* buffer1 */ #define Y 20 /* buffer2 */ main(int argc, char *argv[]) { long offset, garbage; char buffer1[X]; char buffer2[Y]; offset = (buffer1 - buffer2); garbage = offset - Y; fgets(buffer2, 100, stdin); printf("[buffer2][buffer1][ebp][ret]\n"); printf("buffer2 : 0x%x, buffer1 : 0x%x, (buffer2-buffer1) : %d, garbage : %dbyte.\n\n", buffer2, buffer1, offset, garbage); printf("[buffer2(%dbyte)][garbage1(%dbyte)][buffer1(%dbyte)][ebp(4byte)][ret(4byte)]\n",Y, garbage, X); printf("|_________________________________|\n"); printf(" (%dbyte) \n", offset); printf("\n"); dumpcode((char*)buffer2, 200); printf("\n"); printf("[buffer2(%dbyte)][garbage1(%dbyte)][buffer1(%dbyte)][garbage2(??byte)][garbage3(8byte)][ebp(4byte)][ret(4byte)]\n",Y, garbage, X); printf("|_________________________________|\n"); printf(" (%dbyte) \n", offset); } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~실행 화면~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [buffer2][buffer1][ebp][ret] buffer2 : 0xbffff910, buffer1 : 0xbffff930, (buffer2-buffer1) : 32, garbage : 12byte. [buffer2(20byte)][garbage1(12byte)][buffer1(20byte)][ebp(4byte)][ret(4byte)] |_________________________________| (32byte) 0xbffff910 0a 00 00 00 00 00 00 00 98 70 01 40 f0 72 01 40 .........p.@.r.@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0xbffff920 60 f9 ff bf 16 d8 00 40 d0 9a 04 08 95 82 04 08 `......@........ ~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20 byte 12byte 0xbffff930 3c 91 03 40 e4 89 15 40 64 6b 01 40 6e 1c 14 40 <..@...@dk.@n..@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0xbffff940 78 f9 ff bf b0 d9 00 40 20 e4 05 40 e4 89 15 40 x......@ ..@...@ ~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20 byte 12byte 0xbffff950 64 6b 01 40 dc f9 ff bf 0c 00 00 00 20 00 00 00 dk.@........ ... ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~ 8 byte ebp ret 0xbffff960 b0 9a 04 08 94 9b 04 08 a8 f9 ff bf 77 a1 04 40 ............w..@ 0xbffff970 01 00 00 00 dc f9 ff bf e4 f9 ff bf 66 83 04 08 ............f... 0xbffff980 60 88 04 08 00 00 00 00 a8 f9 ff bf 61 a1 04 40 `...........a..@ 0xbffff990 00 00 00 00 e4 f9 ff bf dc 74 15 40 f8 65 01 40 .........t.@.e.@ 0xbffff9a0 01 00 00 00 f0 83 04 08 00 00 00 00 11 84 04 08 ................ 0xbffff9b0 14 87 04 08 01 00 00 00 dc f9 ff bf 50 83 04 08 ............P... 0xbffff9c0 60 88 04 08 84 e1 00 40 cc f9 ff bf c0 6b 01 40 `......@.....k.@ 0xbffff9d0 01 1e 00 40 e4 f9 ff bf ...@.... [buffer2(20byte)][garbage1(12byte)][buffer1(20byte)][garbage2(??byte)][garbage3(8byte)][ebp(4byte)][ret(4byte)] |_________________________________| (32byte) ;와 딱 보면 이해가 되지 않는가. 난 가지런히 있고 싶다고 몸부림 치는 듯한 이 규칙성... 그렇다면 이번엔 버퍼 크기를 바꿔 실행 화면을 보도록 하자. [buffer2][buffer1][ebp][ret] buffer2 : 0xbffff920, buffer1 : 0xbffff940, (buffer2-buffer1) : 32, garbage : 9byte. [buffer2(23byte)][garbage1(9byte)][buffer1(12byte)][ebp(4byte)][ret(4byte)] |_________________________________| (32byte) 0xbffff920 0a 00 ff bf 16 d8 00 40 d0 9a 04 08 95 82 04 08 .......@........ 0xbffff930 3c 91 03 40 e4 89 15 40 64 6b 01 40 6e 1c 14 40 <..@...@dk.@n..@ 0xbffff940 78 f9 ff bf b0 d9 00 40 20 e4 05 40 e4 89 15 40 x......@ ..@...@ 0xbffff950 64 6b 01 40 dc f9 ff bf 09 00 00 00 20 00 00 00 dk.@........ ... 0xbffff960 b0 9a 04 08 94 9b 04 08 a8 f9 ff bf 77 a1 04 40 ............w..@ 0xbffff970 01 00 00 00 dc f9 ff bf e4 f9 ff bf 66 83 04 08 ............f... 0xbffff980 60 88 04 08 00 00 00 00 a8 f9 ff bf 61 a1 04 40 `...........a..@ 0xbffff990 00 00 00 00 e4 f9 ff bf dc 74 15 40 f8 65 01 40 .........t.@.e.@ 0xbffff9a0 01 00 00 00 f0 83 04 08 00 00 00 00 11 84 04 08 ................ 0xbffff9b0 14 87 04 08 01 00 00 00 dc f9 ff bf 50 83 04 08 ............P... 0xbffff9c0 60 88 04 08 84 e1 00 40 cc f9 ff bf c0 6b 01 40 `......@.....k.@ 0xbffff9d0 01 1e 00 40 e4 f9 ff bf 01 00 00 00 02 fb ff bf ...@............ 0xbffff9e0 00 00 00 00 09 fb ff bf ........ ;직접 싸인펜으로 그어 보며 확인 해보길. 그럼 와 정말 깔끔하게 정리 되어 보인다고 감탄 할 것이다. 그래도 역시 해킹하기에 계산하게 만들어 싫긴 싫다. [buffer2(23byte)][garbage1(9byte)][buffer1(12byte)][garbage2(??byte)][garbage3(8byte)][ebp(4byte)][ret(4byte)] |_________________________________| (32byte) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ;offset이 어떻게 규칙적으로 움직이나 더 자세하게 정의를 내려 보자 ---------------buffer1----------------> 4 8 12 16 20 ... 4 4 4 4 4 4 8 12 8 8 8 8 12 28 24 16 16 16 16 28 24 16 16 16 ----------------------------------------------------- 20 44 40 32 32 32 24 44 40 32 32 32 28 44 40 32 32 32 32 44 40 32 32 32 ----------------------------------------------------- 36 60 56 48 48 48 40 60 56 48 48 48 44 60 56 48 48 48 48 60 56 48 48 48 ----------------------------------------------------- 52 76 72 64 64 64 56 76 72 64 64 64 60 76 72 64 64 64 64 76 72 64 64 64 ----------------------------------------------------- 68 88 84 80 80 80 ... [buffer2] ;이 표를 자세히 보아 하니 buffer2 쪽에서 16의 배수에 4묶음은 값이 똑같다. (단, 버퍼의 값들이 16 보다 작을 때는 제외) 식 --> buf / 16 == v ... 나머지(버림) 16 * v == a 16 * v == b a < buf <= b ~~~~~~~~~~~~~~ 따라서 b의 값이 offset값이 되는 것이다. 문제 ---------------------------------------------- [buffer2] 100 [buffer1] 12 그렇다면 buffer2에서 buffer1까지의 offset값은? --------------------------------------------------- OK, 그럼 buffer가 하나 선언 되어 있을 때 RET 까지의 거리는 어떻게 계산 할까. RET는 12번째의 자리를 고집하기 때문에, 항상 ebp앞에는 쓰레기 값 8byte가 온다. 이것만 알고 위의 계산 방법과 똑같다. [....][....][....][garbage3(8byte)][ebp(4byte)][ret(4byte)] 확실하게 알고 넘어 가기 위해서 다시 한번 예를 들어 살펴 본다. 예제 source #include #include "dumpcode.h" main() { char buffer[20]; fgets(buffer, 128, stdin); dumpcode((char *)buffer, 128); } 실행 화면 AAAAAA 0xbffff950 41 41 41 41 41 41 0a 00 20 e4 05 40 e4 89 15 40 AAAAAA.. ..@...@ 0xbffff960 64 6b 01 40 ec f9 ff bf 88 f9 ff bf d1 84 04 08 dk.@............ 0xbffff970 e4 97 04 08 c8 98 04 08 b8 f9 ff bf 77 a1 04 40 ............w..@ 0xbffff980 01 00 00 00 ec f9 ff bf f4 f9 ff bf 66 83 04 08 ............f... 0xbffff990 90 87 04 08 00 00 00 00 b8 f9 ff bf 61 a1 04 40 ............a..@ 0xbffff9a0 00 00 00 00 f4 f9 ff bf dc 74 15 40 f8 65 01 40 .........t.@.e.@ 0xbffff9b0 01 00 00 00 f0 83 04 08 00 00 00 00 11 84 04 08 ................ 0xbffff9c0 14 87 04 08 01 00 00 00 ec f9 ff bf 50 83 04 08 ............P... gdb를 이용하여 ret의 값을 알아 보자. GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) disassemble main Dump of assembler code for function main: 0x8048714
: push %ebp 0x8048715 : mov %esp,%ebp 0x8048717 : sub $0x28,%esp 0x804871a : sub $0x4,%esp 0x804871d : pushl 0x80498c4 0x8048723 : push $0x80 0x8048728 : lea 0xffffffd8(%ebp),%eax 0x804872b : push %eax 0x804872c : call 0x80483a8 0x8048731 : add $0x10,%esp 0x8048734 : sub $0x8,%esp 0x8048737 : push $0x80 0x804873c : lea 0xffffffd8(%ebp),%eax 0x804873f : push %eax 0x8048740 : call 0x8048540 0x8048745 : add $0x10,%esp 0x8048748 : leave 0x8048749 : ret 0x804874a : mov %esi,%esi 0x804874c : nop 0x804874d : nop 0x804874e : nop 0x804874f : nop End of assembler dump. (gdb) break *0x8048717 Breakpoint 1 at 0x8048717 (gdb) run Starting program: /root/Documents/what/ret Breakpoint 1, 0x08048717 in main () (gdb) info registers ebp ebp 0xbffff968 0xbffff968 (gdb) x/10 0xbffff968 0xbffff968: 0xbffff9a8 0x4004a177 0x00000001 0xbffff9dc ~~~~~~~~~~ ~~~~~~~~~~ ebp ret 0xbffff978: 0xbffff9e4 0x08048366 0x08048790 0x00000000 0xbffff988: 0xbffff9a8 0x4004a161 (gdb) 77 a1 04 40 ---> RET (DUMPCODE와 비교 하여 찾아 보라. 우리가 예상했던 위치에 있는 것을 발견 할 수 있다.) 0xbfff96c --> 음. 원래는 이것이 우리가 생각 했던 RET 주소 였던 것이고 + 10 0xbfff97c --> 이것이 우리의 생각을 바꾸게 한 RET 주소다. offset 10의 차이가 나는 것을 우리는 확인하고 이것 또한 생각 해두자. buffer = 20 20 / 16 = 1 ... xx 16 * 1 = 16 16 * 2 = 32 16 < buffer <= 32 ---> 따라서 garbage3(8byte)까지의 거리는 32 그럼 버퍼가 어떻게 되냐 그림으로 살펴 본다. [buffer(20)][garbage(12)][garbage3(8)][ebp(4)][ret(4)] 이제 공격 해 보는것은 여러분의 몫! 행운을 빕니다.