'TeamCR@K' 태그의 글 목록

Search

'TeamCR@K'에 해당되는 글 3건

2013.07.25 2013년 상반기 TeamCR@K 내부 연구결과 정리
2011.01.27 메모리 보호기법 우회 - 1 - Windows/Linux 환경에서의 Stack Overflow 보호기법 2
2010.06.30 [도서 출간] 크래커 잡는 명탐점 해커 3

2013년 상반기 TeamCR@K 내부 연구결과 정리

CR@K 이야기 2013. 7. 25. 14:10 Posted by TEAMCR@K

날씨가 점점 더워지고 있습니다~

요즘 사무실 내부에서는 에어컨을 풀가동 시키고 있네요.

날씨도 더운데 일하랴 개인연구 하랴 바쁜 가운데 2013년 상반기의 TeamCR@K 내부 활동 정리해 보았습니다~

2013년 상반기에는 각종 프로젝트가 끊이지 않아서 개인 연구나 기타 공동 연구작업이 원활치 않았습니다.

그 와중에도 개인시간을 내어 버그헌팅을 하고 exploit 제작을 하거나, 프로젝트에 투입 중간에도 솔루션의 취약점을 찾아 0day exploit을 만든적도 있었습니다.

다음은 저희 TeamCR@K에서 금년 2013년 상반기 버그헌팅 및 0day exploit 작성과 관련한 내역을 정리한 것입니다.

Date	Exploit Name	Classification	Summary
2013.02.22	DoubleQuarterPounderCheese-130222.c	0day	Buffalo TeraStation TS5800D Command Injection Vulnerability Exploit
2013.05.24	XE-LFI-1day_fr33p13.py	1day	Zeroboard XE Local File Inclusion Vulnerability (From KISA, 2013.05.13)
2013.05.31	********-insecure_file_creation.pl	0day	Local root exploit ${PROTECTED_COMMAND} command in ${PROTECTED_SOLUTION}
2013.05.31	********-symlink_follow.sh	0day	Local root exploit ${PROTECTED_COMMAND} command in ${PROTECTED_SOLUTION}
2013.06.10	hurse.sh	0day	Remote Command execution exploit ${PROTECTED_COMMAND} in ${PROTECTED_SOLUTION}
2013.06.11	-	0day	Buffalo TeraStation TS5800D Remote Command Execution Vulnerability

* Buffalo TeraStation TS5800D Command Injection Vulnerability Exploit

Buffalo에서 만든 TeraStation이라는 NAS 서버에서 취약점을 발견하여 이를 자동화 하는 exploit을 구현했었습니다.

NAS라는 내부장비에서 root 권한의 명령어를 실행 할 수 있는 취약점으로 버그헌팅 당시 NAS 솔루션의 외부 침입 위험을 진단하는 관점보다는 스마트폰의 Jail Break와 같은 관점으로 버그헌팅을 시작했었습니다.

exploit 이름이 DoubleQuarterPounderCheese.c 인 이유는 exploit 작성 당시.. 야식으로 맥**드의 버거를 먹었다는 후문이... ^^;

본 취약점과 관련해서는 다음 URL에서 상세한 내용을 확인 할 수 있습니다.

http://teamcrak.tistory.com/365

* Zeroboard XE Local File Inclusion Vulnerability (From KISA, 2013.05.13)

2013년 5월 13일 KISA 홈페이지를 통해 Zeroboard XE 관련 LFI 취약점에 대해 패치권고가 올라왔었습니다.

당시 TeamCR@K 김모군(fr33p13)은 패치된 코드를 디핑하여 취약점 내용을 구현하는 테스트를 진행했었습니다.

어찌어찌해서 웹 쉘을 올리는 코드가 실행되고 이에 대해 파이썬으로 자동화 exploit을 구현까지 했었네요.

본 취약점과 관련해서는 다음 URL에서 상세한 내용을 확인 할 수 있습니다.

http://teamcrak.tistory.com/369

* Multiple Vulnerabilities in SOLUTION

본 내용은 모의해킹 수행 중 발견한 솔루션 0day 취약점으로 Local privilege escalation 취약점 2종과 Remote command execution 취약점 1종을 발견하고, 이와 관련하여 exploit을 작성 및 별도의 보고서를 고객사로 송부하였습니다.

원격명령실행 취약점과 관련한 exploit은 초기 이름이 hurse.sh 였는데..

동일 프로젝트에 소속된 정모군과 박모군이 이미 권한상승취약점에 대한 exploit을 작성하고 난 이후..

정모군曰 "오! 이거 될 것 같다. 오늘 내가 이거 원격 명령 실행 취약점 나오면 exploit한다"고 했더니..

이 말을 들은 박모군이 이랬답니다.

허세 작렬! 허세 작렬! 허세 작렬! 허세 작렬! 허세 작렬!

...

그 말에 빡친 정모군은 후일 hurse.sh라고 이름 붙인 exploit을 팀원 모두에게 공유했는데 나중에 박모군은 "허세 아닌 패기"라며 발뺌했다고 하네요!

Unix/Linux 서버용 daemon을 만들고 이를 유지보수 할 때에는 여러모로 보안에 신경써야 하는 부분이 많습니다.

특히 Port를 열고 통신을 하는 daemon의 경우 보안취약점이 존재할 경우 해당 취약점을 자동으로 공격하는 스크립트로 대량의 서버접근권한을 탈취당할 수 있고 이런 서버들은 불법적인 공격에 이용당할 수 있습니다.

솔루션의 경우에는 정식 빌드 이전이나 정식 서비스 오픈 이전, 이러한 보안취약점들을 사전에 차단할 수 있도록 보안성검토와 같은 작업을 통해 보안취약점들을 걸러낼 수 있습니다.

* Buffalo TeraStation TS5800D Remote Command Execution Vulnerability

해당 취약점은 아직 exploit까지는 만들어지지 않았지만 SSL 통신을 하는 NAS의 특정 바이너리 형태를 그대로 소스코드로 복원하여 root 권한의 명령어를 실행시킬 수 있는 취약점이라고 합니다. 자세한 사항은 추후 exploit을 작성 한 후 블로그에 올리도록 하겠습니다.

프로젝트로 심신이 고달픈 가운데 개인연구에 힘 쓰는 TeamCR@K 멤버들이 있네요.

날씨도 더운데 몸 상하지 않게 오래오래 같이 연구했으면 좋겠습니다~

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

메모리 보호기법 우회 - 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 데이터의 변조로 인하여 오버플로우에 대한 경고하고 프로그램을 종료시킵니다.