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

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

날씨도 더운데 일하랴 개인연구 하랴 바쁜 가운데 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-


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

 

 l  Terminator canaries

문자열 끝문자를 이용하여 canary 구성하는 방법으로 canary 값으로 NULL, CR, LF, Oxff 값의 조합이 사용됩니다. 공격자는 공격시, 종료문자로 구성된 canary 값에 접근을 없게됩니다.


l  Random canary

프로그램을 실행할 때마다 임의의 canary 값을 삽입을 합니다. 이에 따라 공격자는

Canary 값을 예측불가능하므로 공격에 어려움이 발생합니다.


l  Null canary(0x00000000)

메모리상의 공격을 막기위해 canary 값을 NULL 구성합니다. 공격자는 공격코드상에 NULL 값을 삽입할 없으므고 canary 값에 접근이 불가능합니다.


 

다음 화면은 canary 적용되지 않은 프로그램을 분석한 화면입니다.

[그림 12] Canary 미적용

 

다음 화면은 canary 적용된 프로그램을 분석한 화면입니다.  GDB 분석결과 메모리상에서 canary 대한 영역이 설정된 , buffer 구조가 설정되는 것을 확인 있습니다.

[그림 13] Canary 적용

 


참고 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를 관통하는 프로그래밍 원리) - 정덕영

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

http://www.cyber.co.kr/mart7/mall.php?cat=002006000&query=view&no=3154

TeamCR@K 팀원들이 참여하여 쓴 책이 천신만고(?) 끝에 발간되었다.

프로젝트를 하면서 팀원들과 같이 써내려간 시간들은 힘들었지만, 나름 결과가 나오니 보람이 느껴진다.

처음부터 결과물이 좋을거라 생각하지는 않는다. 이제 시작이기 때문에, 더욱더 많은 경험과 지식이 쌓인다면 후에 더 훌륭한 책이 또 발간되지 않을까 생각한다.

이 책은 "모의해킹"이라는 분야에 처음 접하는 학생들과 그동안 점검을 받으면서 내용적으로 궁금했던 고객분들에게 필요한 책일거라 생각한다.

어느 한 부분에 집중해서 조명한것은 아니기 때문에 그런 방향을 원하는 독자들한테는 맞지 않을것이다.



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