'2011/01/27 글 목록

메모리 보호기법 우회 - 2 - ROP(Return Oriented Programming) Exploit

S/W 역공학 분석(Reversing) 2011. 1. 27. 16:37 Posted by 알 수 없는 사용자

메모리 보호기법 우회 연구분석보고서 -2-

본 문서는 Stack Overflow 보호기법과 이를 우회하는 방법에 대하여 작성하였습니다. 해당 내용과 테스트 결과가 많은 관계로아래와 같은 주제로 3회에 걸쳐 연재하도록 하겠습니다.

1. 'Windows/Linux 환경에서의 Stack Overflow 보호기법'
2. 'ROP(Return Oriented Programming) Exploit'
3. 'SEH(Structed Exception Handling) Overwrite'

ROP(Return Oriented Programming) Exploit

1. ROP(Return Oriented Programming)
ROP(Return Oriented Programming)는 취약한 프로그램 내부에 있는 기계어 코드 섹션들(Gadget)을 이용하여 BOF공격 시 특정 명령을 실행시키는 방법을 말합니다. 보통 Gadget은 함수 끝에 기술되어있는 ret 명령어를 포함, 상위 몇가지 명령어들의 집합이며 이를 이용하여 단한번의 실패없이 한번에 공격을 성공할 수 있습니다

[그림 1] Gadget #1

[그림 2] Gadget #2

이러한 ROP는 ASLR, DEP/NX, ASCII-Armor 메모리 보호기법들을 우회할 수 있기 때문에 Fedora core 13(kernel 2.6.33.3-85)에서 BOF공격이 가능합니다.

ROP는 RTL, Chaining RTL calls, GOT overwrite의 3가지 특징적인 기술을 사용합니다.

(1) RTL(Return to libc)
스택에 있는 리턴 주소를 특정 라이브러리 주소와 이에 알맞은 인자 구성을 하여 공격하는 방법을 Return-to-libc 공격이라고도 부릅니다. 특정 프로그램(/bin/sh)을 실행 하기 위하여 system(), exec*() 등과 같은 함수를 사용하여 관리자 권한의 쉘을 획득합니다.

다음은 RTL 공격 전후의 스택구조를 나타낸 그림입니다.

[그림 3] RTL 개념도

DEP/NX의 보호기법으로 인해 스택영역에 코드를 삽입하여 공격하는 고전적인 쉘코드 삽입방법은 무용지물이 되었습니다. 하지만 이러한 RTL 공격기법을 이용하여 코드 삽입 방법이 아닌 함수를 직접 호출하는 RTL 방법으로 우회할 수 있습니다.
이러한 방법은 DEP/NX + ASLR 보호 기법이 적용되면서 공격이 어렵게 됩니다. 라이브러리 로딩 순서가 바뀌거나, 부팅할 때마다 이미지 적재 위치가 바뀌게 되면 임의의 리턴 주소를 찍어 맞춰야 하기 때문에 사실상 공격이 어려워집니다.

(2) Chaining RTL calls
Chaining RTL calls 기법은 RTL 공격을 연속적으로 일어나게 스택을 구성하여 공격하는 방법을 말합니다. pop-pop-ret 과 같은 명령어를 이용하여 스택의 인자 참조 영역을 지나치고 다음 함수주소로 이동, 연속적으로 함수를 호출할 수 있습니다.

다음은 Chaining RTL calls의 구성을 나타낸 화면입니다. 아래와 같이 스택이 구성된다면 연속적인 함수 호출이 가능합니다.

[그림 4] Chaining RTL calls 개념도

(3) GOT(Global Offset Table) Overwrite
GOT Overwrite는 libc.so 내에 실제 함수 주소를 저장해 놓은 공간인 GOT에 특정 함수의 GOT 값을 변경하여 원하는 함수가 실행되게 하는 방법입니다. 예를 들어 printf 함수의 GOT값(실제 함수 주소)을 execve 함수의 주소로 변경하게 된다면 printf 함수가 수행될 때 printf가 호출되는 것이 아닌 execve함수가 호출되게 되는 것을 말합니다.

다음은 PLT에서 GOT의 흐름과 실제 함수 주소를 확인하는 화면입니다.

[그림 5] PLT, GOT 흐름도

2. ROP 시나리오
ROP 시나리오는 Stage-1과 Stage-0으로 구분됩니다. Stage-1에서는 ROP 공격을 위한 Payload가 구성되며 Stage-0에서는 Stage-1에서 구성된 Payload를 특정 스택 영역에 복사하기 위한 strcpy 함수의 Chaining RTL calls가 구성됩니다.

(1) Stage-1
Stage-1은 GOT Overwrite로 실행 함수(exec* 계열)나 getreuid함수를 호출하게 합니다. 하지만 ASLR 보호기법으로 인해 직접적인 함수 주소를 overwrite를 할 수 없기 때문에 add operation gadget을 이용하여 함수간 offset을 add operation으로 계산하여 원하는 함수가 호출되게 합니다.

다음은 execve 함수와 printf 함수의 주소 그리고 이들간에 offset값을 나타낸 화면입니다.

[그림 6] execve, printf 함수 주소

offset = execve() - printf()
execve() = printf() + offset
execve() = 0x94ee40
printf() = 0x8fad30
offset = 0x54110

다음은 Stage-1애서 GOT Overwrite를 하기위한 스택구조를 나타낸 화면입니다.

[그림 7] GOT Overwrite가 일어나는 스택구조

ecx 레지스터에 해당 offset 값을 넣어두고 add operation gadget의 명령에 맞춰 5b042464를 빼준 값을 ebp에 넣어둡니다. 해당 명령이 실행될 때에 ebp와 5b042464값이 더해지게 되어 printf함수의 주소로 바뀌게 되고 이를 ecx(offset)와 더하면서 printf 함수의 GOT 값이 execve 함수의 주소로 바뀌게 됩니다. 마지막으로 printf의 PLT값이 호출되면서 execve함수가 수행되는 방식으로 진행됩니다.

(2) Stage-0
Stage-1에서는 Stage-0에서 구성된 Payload를 실행은 되지 않지만 메모리 주소가 변하지 않는 특정 custom stack영역에 복사를 수행합니다. 여기서는 앞서 설명한 Chaining RTL calls를 이용하여 반복적으로 strcpy 함수를 호출하게 되는데 이는 부분 부분 흩어져 있는 특정 문자열들을 모아서 Stage-0 Payload에 맞게 구성해야 하기 때문입니다. 이와 같은 작업을 하는 이유는 Stage-1에서 존재하는 NULL byte(0x00) 이후의 값을 strcpy 함수로 복사할 수 없기 때문이며, 원하는 기능을 수행하기 위해서 ebp의 값을 원하는 위치에 놓이게 하기 위해서 입니다.

3. ROP Exploitation
ROP Exploit은 Fedora Core 13에서 수행하였습니다. 일반적인 BOF는 수동으로 공격을 수행하기도 하지만 ROP Exploit을 수동으로 구성하는 것은 효율적이지 않습니다. 다양한 gadget들을 모아야하며 Stage-1을 구성하기 위해 사용되는 수많은 코드들 또한 모아야 하기 때문에 오랜시간이 소비됩니다. 이 때문에 ROP는 자동화된 공격도구를 사용하게 됩니다. 앞으로의 예제는 공격코드가 구성되는 gadget과 Stage-1과 Stage-0를 쉽게 구성하기 위해 BlackHat 2010에서 소개되었던 ROPEME(ROP Exploit Made Easy)를 이용하였습니다.

다음은 BOF 취약점이 존재하는 프로그램 소스코드 입니다. strcpy함수로 인해 BOF가 일어나게 됩니다.

[그림 8] BOF 취약점이 존재하는 프로그램

다음은 ROPEME에서 제공하는 ropshell을 이용하여 해당 gadget들을 찾는 화면입니다.

[그림 9] ropshell을 이용한 gadget 검색

다음은 Stage-1이 놓이게될 custom stack 영역을 찾는 화면입니다. 주소값이 변하지 않는 .bss 영역을 지정하게 됩니다. 정확한 위치는 사용하고 있는 8byte를 지난 bss+8 영역이 됩니다.

[그림 10] custom stack이 놓이게 될 위치

gadget들과 custom stack의 위치를 찾게되면 이를 이용하여 exploit합니다. 다음은 exploit 코드 화면입니다.

[그림 11] exploit #1

[그림 12] exploit #2

exploit은 지정된 gadget들을 참조하여 stage-1과 stage-0를 구성합니다. ret의 주소를 70번 삽입하고 그 이후 stage-0를 구성하는 형태로 공격이 진행됩니다.

다음은 이를 이용하여 관리자 권한을 획득하는 화면입니다.

[그림 13] exploit #3

exploit에서 구성된 공격코드를 추출하여 분석결과 ret 이후 strcpy 함수의 Chaining RTL calls로 구성합니다. 또한 stage-0을 구성할 시에 쓰이는 문자열들은 취약한 프로그램 코드를 검색하여 수집합니다.

다음은 exploit상에서 출력되는 Stage-1과 Stage-0의 구성화면입니다.

[그림 14] Stage-1 Payload

[그림 15] Stage-0 Payload

다음은 공격코드를 추출하여 Stage-0의 strcpy의 호출과 복사 위치를 확인하는 화면입니다.

[그림 16] Stage-0의 strcpy 복사 위치 확인 #1

위와 같이 Stage-1을 구성하기위해 custom stack위치에 특정 문자열을 반복적으로 복사하는 것을 확인 할 수 있습니다.

다음은 이해를 쉽게하기 위해 실제 디비거 상에서 source위치를 확인하는 화면입니다.

[그림 17] Stage-0의 strcpy 복사 위치 확인 #2

다음은 Stage-1의 Payload 입니다. 복사되는 문자열이 Stage-1의 값이라는 것을 확인할 수 있습니다.

[그림 18] Stage-0의 strcpy 복사 위치 확인 #3

Stage-1이 일어나는 액션은 다음과 같습니다. 취약한 프로그램의 getuid함수의 GOT를 Overwrite하여 setreuid() 함수로 root권한을 상속받고 setreuid() GOT를 다시 execvp함수로 Overwrite하여 shell을 실행하는 순서로 진행합니다.

[그림 19] Stage-1의 액션 확인

위에서 설명했던 액션을 대략적으로 스택에 반영하여 확인하면 다음과 같습니다.

[그림 20] Stage-1 스택 구성도

다음은 추출한 공격코드들을 수동으로 수행하는 화면입니다.

[그림 21] 추출한 Payload로 수동공격

다음은 trace 명령으로 해당 공격코드를 삽입하여 strcpy함수를 연속적으로 호출하고 있는것을 확인하는 화면입니다. 정상함수 수행 후 BOF되어 strcpy함수를 연속적으로 호출하는 것을 확인할 수 있습니다.

[그림 22] trace 명령으로 함수 호출 확인#1

[그림 23] trace 명령으로 함수 호출 확인#2

참고 URL

1. http://msdn.microsoft.com

2. http://x82.inetcop.org/

3. http://nchovy.kr/forum/5/article/377

4. http://en.wikipedia.org/wiki/Buffer_overflow_protection

5. http://ko.wikipedia.org/wiki/버퍼 오버플로우

6. http://lucid7.egloos.com/

7. http://uptx.egloos.com/

참고 문헌

1. poc09-sotirov.pdf(POC 2009 발표자료)

2. BHUS10_Paper_Payload_already_inside_data_reuse_for_ROP_expl.pdf

(BlackHat 2010 USA 발표자료)

3. Linux Memory Protectiion Mechanism

4. bh08sotirovdowd.pdf(BlackHat 2008 발표자료)

5. BOF_공격방지_매커니즘_구현의_최신_동향.pdf

6. http://www.shell-storm.org/papers/files/732.pdf

7. www.phreedom.org/presentations/reverse.../reverse-engineering-ani.pdf

8. CanSecWest2010 – SEH Overwrite, Shuichiro Suzuki

9. Windows 구조와 원리 (OS를 관통하는 프로그래밍 원리) - 정덕영

저작자표시 비영리 변경금지

메모리 보호기법 우회 - 1 - Windows/Linux 환경에서의 Stack Overflow 보호기법

S/W 역공학 분석(Reversing) 2011. 1. 27. 16:16 Posted by 알 수 없는 사용자

메모리 보호기법 우회 연구분석보고서 -1-

By. eloi@a3sc.co.kr
(A.K.A eloi)

jtsong@a3sc.co.kr
(A.K.A trynerr)

본 문서는 Stack Overflow 보호기법과 이를 우회하는 방법에 대하여 작성하였습니다. 해당 내용과 테스트 결과가 많은 관계로아래와 같은 주제로 3회에 걸쳐 연재하도록 하겠습니다.

1. 'Windows/Linux 환경에서의 Stack Overflow 보호기법'
2. 'ROP(Return Oriented Programming) Exploit'
3. 'SEH(Structed Exception Handling) Overwrite'

Window 환경에서의 메모리 보호기법

1. Window 버전별 메모리 보호기법

Window의 각 버젼에서 실행되고 있는 메모리 보호기법입니다. 새로운 운영체제가 출시 될 때마다 발전된 메모리 보호기법을 확인할 수 있습니다.

	XP sp2, sp3	2003 sp1, sp2	Vista sp0	Vista sp1	2008 sp0
GS
Stack Cookies	Yes	Yes	yes	yes	Yes
Variable reordering	Yes	Yes	yes	yes	yes
#pragma strict_gs_check	No	No	no	yes	yes
SafeSEH
SEH handler validation	Yes	Yes	yes	yes	yes
SEH chain validation	No	No	no	yes	yes
Heap protection
Safe unlinking	Yes	Yes	yes	yes	yes
Safe lookaside lists	No	No	yes	yes	yes
Heap metadata cookies	Yes	Yes	yes	yes	yes
Heap metadata encryption	No	No	yes	yes	yes
DEP
NX support	Yes	Yes	yes	yes	yes
Permanent DEP	No	No	no	yes	yes
OptOut mode by default	No	Yes	no	no	yes
ASLR
PEB, TEB	Yes	Yes	yes	yes	yes
Heap	No	No	yes	yes	yes
Stack	No	No	yes	yes	yes
images	No	No	yes	yes	yes

2. 메모리 보호기법 설명

(1) GS

GS 는 Window 상에서 스택을 보호하는 기법으로, Visual Studio 2003버젼 이상에서 컴파일시 기본적으로 추가 되는 옵션입니다.

다음 화면은 Visual Studio 2010 상에서 확인한 GS 옵션입니다.

[그림 1] GS 옵션 설정

● Stack Cookies

GS 옵션을 적용하게 되면 코드에 스택 체크 루틴이 추가됩니다. 컴파일러는 로컬 문자열 버퍼가 있는 함수의 BOF공격을 방지하기 위하여 검사를 합니다.

다음 화면은 BOF 공격이 발생하여 GS cookie 가 공격을 탐지하는 화면입니다.

[그림 2] BOF 탐지

GS옵션은 함수상에 로컬 문자열 버퍼가 있는경우 컴파일러는 쿠키(ret 변조를 막기위한 메모리공간)를 추가하여 Buffer와 Ret 사이에 위치시켜 함수의 return 주소를 보호합니다.

[그림 3] stack cookie 구조

예를 들어 아래와 같은 코드가 있습니다. 먼저 왼쪽은 GS옵션을 사용하지 않은 경우 BOF 가 발생 가능한 소스코드입니다. 하지만 GS옵션을 사용할 경우 컴파일러가 자동으로 쿠키에 대한 코드를 추가로 넣습니다. 이로 인하여 RET 주소의 변조를 확인 가능합니다. 만약에 오버플로우가 일어나면 RET 앞에 위치한 cookie 값을 변조하게 됩니다.

이때 .data 영역에 저장된 cookie 와 RET 앞에 위치한 cookie 를 비교하게 됩니다. 이때 쿠키가 변조된 것으로 판명되면 Abort()해서 스택오버플로를 방지하게 됩니다.

[GS 옵션 미적용]

void a3sc(char *input)

{

char buffer[256];

strcpy(buffer, input);

}

[GS 옵션 적용]

static_cookie = rand();

void a3sc(char *input)

{

int cookie = random_cookie;

char buffer[256];

strcpy(buffer, input);

if (cookie != random_cookie)

abort();

}

(2) SafeSEH

SEH(Structured Exception Handling)는 Window 상에서 예외처리를 하는 기법입니다. DLL 상에 있는 SafeSEH 에서 존재하며 H/W, S/W 상에서의 예외처리가 가능합니다. 그리고 BOF 또는 메모리에 대한 손상이 발생이나 시스템이 예기치 않게 종료되는 이벤트 발생시, 프로그램에 대한 예외처리를 해주는 역할을 담당합니다.

SafeSEH는 에러처리 레코드를 덮어쓰는 공격을 막기위한 기법입니다. SafeSEH 옵션을 지정후, 컴파일하게되면, 링커에서 안전한 예외 처리 목록을 생성하며, 이것은 헤더에 예외처리 목록에 포함됩니다. 만약 공격자가 예외처리 레코드를 덮어쓰게 되면 프로그램은 예외를 탐지하여 프로그램을 종료하게 됩니다.

다음 화면은 Visual Studio 2010상에서 SafeSEH 옵션을 설정하는 화면입니다.

[그림 4] SafeSEH 옵션

(3) ASLR(Address Space Layout Randomization)

ASLR은 프로세스내에서 매핑되는 오브젝트에 대하여 호출 및 실행시 실행하는 주소를 랜덤화하는 기법입니다. ASLR 은 매핑된 파일들을 힙, 스택, PEB, TEB의 위치상에서 랜덤화를 적용합니다. 공격자는 BOF 공격을 시도하더라도, 오브젝트에 대한 정확한 주소를 알지 못하므로 BOF 공격을 실패하게 됩니다.

다음 화면은 링커의 속성에서 ASLR 옵션을 설정하는 화면입니다.

[그림 5] ASLR 옵션

다음은 간단한 소스를 통하여 ASLR의 기능을 확인해보았습니다.

#include <stdio.h>

void main()

{

char buffer[256];

printf("buffer address: %p\n", buffer);

}

다음 화면은 ASLR 옵션을 적용하지 않았을 때의 프로그램 실행화면입니다. 프로그램을 실행할 때마다 Buffer 의 주소가 같음을 알 수 있습니다.

[그림 6] ASLR 옵션 미적용

다음 화면은 ASLR 옵션을 적용하여 프로그램을 실행한 화면입니다. 위의 화면과는 다르게 프로그램을 실행할 때마다, 주소값이 달라짐을 확인 가능합니다.

[그림 7] ASLR 옵션 적용

(4) DEP(Data Excution Prevention)

DEP는 가상 메모리의 최소 단위인 페이지에 기존에 읽고 쓰는 권한 외에 실행 권한에 대해서 체크하도록하여 메모리 공격으로부터 시스템을 보호하는 방법입니다.

기본적으로 DEP는 공격자가 stack, heap, data section에서 shellcode를 실행하는 것을 금지합니다. 예를들어 DEP 기능이 활성화 되어 있을 때, 악의적인 코드가 실행하는 시점에서 해당 영역에서 실행권한이 없으므로 예외가 발생하여 공격을 막을 수 있습니다.

다음 화면은 Window7에서 DEP 옵션을 설정하는 화면입니다.

[그림 8] DEP 옵션

Linux 환경에서의 메모리 보호기법

1. Linux 버전별 메모리 보호기법

	ASLR			N/X(DEP)			ASCII Armor	main() canary
	S	H	L	S	H	L
Red Hat Linux9.0	O	X	X	X	X	X	X	X
Fedora 8 ~ 10	O	O	X	O	O	X	O	O
Fedora 11	O	O	X	O	O	O	O	X
Fedora 12	O	O	O	O	O	O	O	X
Cent OS 4.4	O	O	X	O	O	X	O	X
Cent OS 4.5~4.8	O	O	O	O	O	X	O	X
Cent OS 5.0~5.4	O	O	O	O	O	X	O	O
Ubuntu 6.10~ 8.04.1	O	X	O	X	X	X	X	O
Ubuntu 8.10~ 9.0.4	O	O	O	X	X	X	X	O
Ubuntu 9.10	O	O	O	O	O	X	O	X
openSUSE 11.2	O	X	O	X	X	X	X	X
Gentoo 2006.0	O	X	O	X	X	X	X	X
Gentoo 2007.0	O	X	O	X	X	X	X	O

(S : Stack, H : Heap, L : Library)

2. 메모리 보호 기법

(1) ASLR(Address Space Layout Randomization)

메모리상의 공격을 방어하기 위해 주소 공간배치를 난수화 시키는 기법입니다. 즉, 스택, 힙, 라이브러리 등의 데이터 영역 주소등을 난수화 시킨 주소로 프로세스의 주소 공간에 배치하는것입니다. Window 에서 적용되는것과 유사한 기법이며 리눅스 커널 2.6.12이후로 적용되어있습니다

다음은 Fedora 13에서 현재 프로세서상에서 메모리구조를 확인하는 화면입니다.

ASLR의 적용으로 인하여 메모리상에 존재하는 주소가 지속적으로 변함을 알 수 있습니다.

[그림 9] ASLR

(2) DEP / NX(Not Excutable)

메모리상의 보호를 위해 stack과 heap에서 코드가 실행되는 것을 막는 기법입니다.

공격자가 BOF 공격을 일으키면 DEP 가 적용된 상태에서는 실행권한이 없으므로 프로그램에 대한 예외처리후, 종료가 됩니다.

다음은 Fedora 13에서 현재 프로세서상에서 메모리구조를 확인하는 화면입니다.

DEP의 적용으로 인하여 stack, heap, libc 영역에 실행권한이 존재하지 않음을 확인 가능합니다.

[그림 10] DEP

(3) ASCII-Armor

Libc 영역을 보호하기 위한 기법으로 상위주소를 \x00으로 시작하게 만드는 기법으로 공격자는 라이브러리를 호출하는 BOF 공격시, NULL 바이트가 삽입된 주소로 접근 할 수 없게됩니다.

[그림 11] ASCII-Armor

(4) Canary

canary 는 Window 에서의 메모리 보호 기법인 stack cookie 와 같은 개념으로 Buffer와 RET 사이에서 스택의 BOF를 모니터링하는 역할을 담당합니다. BOF가 발생하면 canary 데이터의 변조로 인하여 오버플로우에 대한 경고하고 프로그램을 종료시킵니다.