MS Windows CHM File Processing Buffer Overflow

취약점 분석/2009년 이후 2009. 2. 10. 16:30 Posted by 알 수 없는 사용자

▷ 작성자 : InPire(aramlee@a3sc.co.kr)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)

 


MS Windows CHM File Processing Buffer Overflow

취약점 보안 권고안




1. 요 약

CHM 파일은 HTML문서와 이미지, 자바스크립트 등을 하나의 파일로 모아 HTML로 컴파일된, MS Windows 플랫폼에서 사용되는 도움말 파일이다. 이 취약점은 CHM파일을 실행할 때 발생하는 버퍼오버플로우로 DoS가 발생한다.

2. 대상시스템
이 취약점은 MS Windows XP Service Pack 3 에서 적용된다.

3. 심각도 및 취약점 확인

취약점 영향

MS Windows CHM File Processing Buffer Overflow

원격 버퍼 오버플로우



Ⅱ. 취약점 세부 분석

1. 취약점 내용
취약점 분석은 아래 URL의 POC로 분석하였다.

http://www.milw0rm.org/exploits/7720

POC를 실행하여 만들어진 chm파일을 더블클릭하여 실행하면 다음과 같은 오류메시지가 뜬다.

[그림 1] Windows CHM 파일 실행 오류


윈도우에서 CHM 파일을 로딩할 때, itss.dll을 로딩한다. itss.dll은 Microsoft 저장 시스템에 의해 사용되는 함수를 담은 파일이다. 이 itss.dll의 “TEST [ECX], EAX” 부분에서 취약점이 존재한다. 이 때,  ECX의 값은 40964이며, 0x40964의 위치을 찾을 수 없기 때문에 액세스 위반으로 인한 오버플로우가 발생한다.

[그림 2] 버퍼오버플로우 발생지점


2. 공격 분석

CHM 파일 포맷은 다음과 같다.

The Header

0000

ITSF(Info-Tech Storage Format)

 

0004

버전

3

0008

전체 헤더 길이

96 bytes

000C

unknown

1

0010

A Time stamp

 

0014

윈도우 언어 ID (Big-endian)

English

(Ireland)

 

0018

GUID

 

0028

GUID

 

The Header Section Table

0000

파일이 시작하는 부분부터의 오프셋

 

0008

섹션의 길이

 

Additional header data

0000

파일안에 콘텐츠 섹션의 오프셋

 

Header Section 0

0000

$01FE. Unknown(Big-Endian)

 

0004

unknown

0

0008

파일 크기

 

0010

Unknown

0

0014

Unknown

0

 

Header Section 1 : The Directory Listing

0000

ITSP

 

0004

버전

1

0008

Directory header 길이

 

0010

unknown

$0a

0014

“Density” of quickref section

 

0018

Depth of the index tree

 

001C

Chunk number of root index chunk

 

0020

Chunk number of first PMGL chunk

 

0024

Chunk number of last PMGL chunk

 

0028

unknown

-1

002C

디렉토리 chunk

 

0030

윈도우 언어 ID

 

0034

GUID

 

0044

길이

$54

0048

Unknown

-1

004C

Unknown

-1

0050

unknown

-1

표 1 CHM File Format



익스플로잇에 삽입된 기계어코드를 파일 포맷에 따라 분석하여보면, Header Section 1에서 ITSP, 버전을 제외한 값은 모두 \x41로 채워져 있다. 아래 그림에서 붉은 글씨 부분이 Header Section 1부분이다.

[그림 3] 익스플로잇에 삽입된 기계어코드


Header Section 1 부분에 엉뚱한 코드를 넣어 ECX값을 변조하여 [ECX]를 액세스 할 수 없게 만든다.

3. 위험 분석
Header Section 1에 이상한 코드가 삽입된 CHM파일을 실행할 때, [ECX]의 위치를 액세스할 수 없어 오버플로우로 인해 DoS가 발생한다.


Ⅲ. 대응 방안


1. 보안 대책

현재 패치가 없는 상태이기 때문에, 의심스러운 도움말파일(CHM 파일)은 열지 않아야 한다.

패치는 헤더값을 읽어올 때 데이터 변환과정의 알고리즘을 패치하는 방법으로 이루어질 것이라고 예상된다.


2.  관련 사이트
본 취약점에 대한 추가적인 정보를 확인할 수 있는 관련 사이트는 다음과 같다.

CVE-2009-0119
Bugtraq Id: 33204
http://www.milw0rm.org
http://www.securityfocus.com/bid/33204



Copyright(c) 1998-2009 A3 Security ,LTD


Disclaimer
※ 현재 ㈜에이쓰리시큐리티에서 테스트 및 분석 중에 있으며, 이 문서는 계속 업데이트될 것입니다. 본 문서는 보안취약점으로 인한 피해를 최소화하는 데 도움이 되고자 작성되었으나, 본 문서에 포함된 대응방안의 유효성이나 기타 예상치 못한 시스템의 오작동 발생에 대하여서는 ㈜에이쓰리시큐리티에서는 일체의 책임을 지지 아니합니다.


▷ 작성자 : Hong10 (hong10@a3sc.co.kr)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)

문서 작성일 : 2009년 2월 5일
최종 수정일 : 2009년 2월 5일

Hong10님께서 이번에는 "Microsoft Excel Could Allow Remote Code Execution(MS08-14)" 에 대해 집중 분석을 하였습니다. 개요 및 설명 (1부), 취약점 분석 (2부)로 하여 포스팅을 하겠습니다.


2. 취약점 분석
먼저 exploit 코드를 살펴 보면 취약한 헤더를 부분을 공략하기 위하여 특별히 제작 한 Resource 가 있습니다. 그리고 나서 Resource 뒷 바이트를 실행 시키고자 하는 바이너리와 합쳐 AV에 탐지가 안되게끔 임의로 Encode 을 함을 알 수 있습니다. 여기서 공격코드는 제가 작성한 Windows Universal ShellCode를 사용을 함으로 논의에서 빼겠습니다.

핵심은 어떻게 해서 헤더를 변조 시켜 Ret Address 를 공격 코드에 향하게 하는지 에 대하여 분석을 하겠습니다. Exploit 코드를 통하여 취약한 엑셀 파일을 생성 후 위에서 분석 한 구조체를 통하여 디버깅 한 결과 특이한 점 3가지를 발견 할 수 있었습니다.

첫 번째 엑셀 루틴에서 파일을 오픈 할 시 헤더를 분석하여 각 Storage 를 Open 하여 Stack  에 할당 하는데 읽어 드리는 사이즈가 헤더에서 정의한 Storage Dir 보다 큰 경우 파일에서 그 사이즈만큼 해당 Stack 에 값을 재할당 합니다.




위 그림에서는 사이즈가 아직 Storage 보다 크지 않기 때문에 바뀌지 않고 있습니다. 하지만 Trace 을 진행하다 보면(마지막 Storage Open 시 레코드의 사이즈가 전체 사이즈 보다 많으면 Stack에 옮기는 작업을 중단 합니다.) 그러한 루틴은 다음과 같이 확인 할 수있습니다.



위 그림에서 eax는 전체 사이즈를 나타내며 ecx는 레코드의 사이즈를 나타냅니다. 그리고 두 값을 비교하는 구문이 있는데 이것은 다음 그림에서 설명 드리겠습니다.

위에서 설명한 사이즈 비교 구문을 리턴 했을 때의 루틴입니다. Cmp [local1],edi 코드 부분을 살펴 보면 위에서 설명한 비교구문이 점프를 타지 않았다면 [local1] 값에는 1이 담겨 지게 되므로 점프를 타게 됩니다. 이는 아래의 cmp esi,809(809 레코드는 엑셀 문서 포맷에서 문서의 시작을 알립니다)

이런 루틴을 타지 않겠다는 의미이며 더 이상 Stack에 값을 할 당하지 않게 됩니다. 그리고 현재 ecx값(사이즈)은 0x5169 이며 esi 값은 0x8a2d(레코드) 값입니다. 이는 파일 오프셋의 0x2260 에 있는 값이며 후에 문제가 발생 되는 부분이기도 합니다.




어째든 최종적으로 0x00136d74 스택 메모리에는 다음과 같은 값이 할당 되었습니다.

두 번째 특이한 점은Storage 는 레코드 값으로 형성 되어 있습니다.엑셀을 이러한 레코드 값과 뒤에 할당 되어 있는 값을 읽어 드려 수행을 합니다. 이때 레코드 값이 DF 값이면 MsofallocMemcore 이란 함수를 사용하여 공격코드가 존재하는 오프셋 위치에서 사이즈 만큼 메모리에 할 당을 합니다. 해당 레코드 값을 엑셀 포맷 문서에서 찾아 본 결과 엑셀에서 그래프 같은 것을 쓸 때 생성되는 레코드 값인걸 알 수 있었습니다.




위 그림에서 문제가 되는 루틴을 자세히 살펴 보겠습니다.

300C1015   .  8B45 70       mov eax, dword ptr ss:[ebp+70]
300C1018   .  8B4D 64       mov ecx, dword ptr ss:[ebp+64]
300C101B   .  8941 04       mov dword ptr ds:[ecx+4], eax

Ebp+64 주소 값은 첫 번째 특이한 점에서 살펴본 주소 값입니다. 이 주소 값에 는 0x0013f8bc 라는 값이 할당이 되어있습니다. 그리고 ebp+70 에는 MsoAllocMemCore 함수에서 할당한 쉘 주소를 가리키는 주소 값을 가지고 있습니다. 거기에 0x0013f8bc+0x4 = 0x0013f8c0 이 되며 이 주소에는 쉘 주소를 가리키는 값을 담게 됩니다.

그림에 보면 eax 값은 0x0995000c 값이며 주소를 찾아 확인 해보면 쉘 주소임을 알 수 있습니다. 아래는 파일 오프셋의 0xe30 부근에 레코드가 0xd1e 이며 사이즈가 0x0d0a 인 값이 존재 함을 알 수있습니다.




이 값 다음에 e40 부근에 쉘 코드들이 시작 되었고 0xe3c+0xd0a = 1b46 즉 파일 오프셋 0x1b47 에 보면 다음과 같이 레코드가 0xdf 인 값을 발견 할 수 있습니다.



이는 DF 레코드 값을 처리 할 때 그 이전에 사이즈 만큼을 메모리에 할당 함을 알 수 있었습니다.

세 번째 엑셀 루틴에서 레코드 사이즈가 0x2020 보다 크다면 특정 루틴으로 향하게 됩니다. 이때 모든 루틴을 수행 하고 나서 다시 함수를 부른 주소로 돌아 갈 때 “add ebp,0x13d8 “ 라는 루틴이 존재합니다. Stack 값을 살펴 보면 ret address 는 쉘 코드가 존재하는 메모리 시작 주소를 가리키고 있으며 그 ret address 를 가리키는 Stack 값은 파일에 존재하는 특정 값으로 할당이 됩니다.

이는 첫 번째 특이한 점에서 Storage 을 Open 할 때 헤더에서 해석한 Storage Size 가 크다면 그 사이즈만큼(아마도 다음 Storage 분석을 위한 루틴인 듯) Stack 에 저장 하는데 이때 ret address 까지 덮어 씌울 수 있어서 두 번째 특이한 점에서 할당된 쉘 코드 주소로 변경 할 수 있어 실행 될 수 있었습니다.




위 그림에서 cmp eax,2020 과 비교를 하며 eax는 문제가 되는 레코드 사이즈 0x5169 값입니다.이렇게 점프를 타게 되고 쭉 trace를 하다 보면 다음과 루틴이 나오면 결국 쉘 주소로 리턴 됨을 알 수 있습니다.



위 그림에서 알 수 있듯이 add ebp,13d8 루틴으로 인해 리턴 어드레스 주소는 0x13f8c0 이며 이는 두 번째 특이한 점에서 할당된 쉘 주소를 가리키는 값임을 알 수 있습니다. 다음은 0x0905000c 루틴 입니다. 실행하면 쉘 이 실행 됨을 알 수 있습니다.



3. 취약한 엑셀 파일 만들기
분석 한 것을 토대로 취약한 엑셀 파일을 새로 만들어 보겠습니다. 참고로 DF 레코드 관련 된 엑셀 파일은 디폴트 페이지로 C:\Program Files\Microsoft Office\OFFICE11\1042 에 존재하는 XL8GALRY.XLS 파일이 있으며 예상대로 그래프 관련 엑셀 파일 이었습니다. 이 파일을 취약점 이 존재하는 파일을 만들기 위하여 다음과 같은 순서를 따르면 됩니다.

Storage 의 적정 레코드 위치(0x1de 레코드가 끝나는 오프셋)에 사이즈를 0xd0a 을 setting 한다.



 
setting 한 4바이트 뒤에 쉘 코드를 복사하여 붙여 넣는다.



0xd0a 사이즈를 setting 한 오프셋부터 0xd0a 를 더한 오프셋 위치에 다음 값을 붙여 넣습니다.



역시 setting 한 오프셋부터 0x70a 을 더한 오프셋 위치에서 다음 값을 붙여 넣으면 완성이다. 단 주의점은 ret address 위치 인데 만약 이 과정을 마친 후에 파일을 실행 했을 경우 아마 대부분 exception이 뜰 것이다.

Exception 주소를 살펴 보면 ret address 가 엉뚱한 위치를 가리켜서 그러한 것이니 해당 값을 파일에서 검색한 뒤 원하는 0xbcf81300 값으로 바꾸어 주면 쉘 을 실행할 수 잇습니다 



분석이 모자라 완벽히 리턴 어드레스 오프셋 위치까진 알 순 없었지만 그래도 취약점이 존재하는 엑셀 파일을 수동으로 만들어 볼 수 있었습니다. 이를 바탕으로 최근 패치 된 엑셀 바이너리를 분석 함으로써 새로운 취약점을 찾아 볼까 합니다.


Copyright(c) 1998-2009 A3 Security ,LTD


Disclaimer
※ 현재 ㈜에이쓰리시큐리티에서 테스트 및 분석 중에 있으며, 이 문서는 계속 업데이트될 것입니다. 본 문서는 보안취약점으로 인한 피해를 최소화하는 데 도움이 되고자 작성되었으나, 본 문서에 포함된 대응방안의 유효성이나 기타 예상치 못한 시스템의 오작동 발생에 대하여서는 ㈜에이쓰리시큐리티에서는 일체의 책임을 지지 아니합니다.

▷ 작성자 : InPure(aramlee@a3sc.co.kr)
▷ 편집자 : 니키 (
ngnicky@a3sc.co.kr)

 

[A3AID08-05]

MS Media Player *(.WAV) Remote Integer Overflow

공격 보안 권고안



1.취약점 내용

취약점 분석은 아래 URL의 POC로 분석하였다.

http://www.milw0rm.org/exploits/7585

POC를 실행하여 만들어진 int-ov.wav 파일을 윈도우 미디어 플레이어로 실행시키면, 다음과 같은 오류메시지가 뜬다.


[그림 1] Windows Media Player 오류

윈도우 미디어 플레이어에서 WAV 파일을 로딩할 때, quartz.dll에 있는 MulDivRN(x, x, x) 함수를 호출하는데, 다음은 이 함수의 코드이다.


[그림 2] MulDivRN(x,  x,  x) 함수


프로세서가 “div reg” 명령을 실행할 때, 다음과 같이 실행한다.

EAX = (EDX:EAX)/reg 

DIV 연산의 결과가 32bit를 넘어서면CPU 예외가 발생하는 데, quartz.dll에 이러한 예외처리를 위한 루틴이 없다.

 
2. 공격 분석

WAVE 파일 포맷은 다음과 같다.


[그림 3] WAVE file format.

WAVE 파일 포맷의 시작은 RIFF 부분이다.

ChunkID : ASCII로 “RIFF”라는 단어를 포함한다. (0x52494646, big endian)

ChunkSize : 파일의 전체 크기에서 8바이트를 뺀 값이다. 이 때, 8바이트를 빼는 이유는 ChunkID와 ChunkSize 두 필드를 포함하지 않기 때문이다.

Format : “WAVE”라는 단어를 포함한다. (0x57415645, big endian)

“fmt ”는 sound data 포맷을 설명하는 부분이다.

Subchunk1ID : “fmt “라는 단어를 포함한다. (0x666d7420, big endian)

Subchunk1Size : 16 for PCM. Subchunk의 잔여 사이즈이다.

AudioFormat : PCM=1. 이 값이 같으면 같은 압축방식이다.

NumChannels : Mono=1, Stereo=2, 기타.

SampleRate : 8000, 44100, 기타.

ByteRate : == SampleRate * NumChannels * BitsPerSample/8

BlockAlign: == NumChannels * BitsPerSample/8

모든 채널을 포함하는 샘플의 바이트 수이다.

BitsPerSample : 8 bits = 8, 16 bits = 16, 기타.

 

“data” 부분은 데이터의 크기와 실제 소리를 포함한다.

Subchunk2ID : “data”단어를 포함한다. (0x64617461, big endian)

Subchunk2Size : == NumSamples * NumChannels * BitsPerSample/8

데이터의 바이트 수이다.

Data : 실제 데이터이다.


다음은 위에서 사용한 익스플로잇의 힙이다.


[그림 4] 익스플로잇의 힙

다음은 72바이트인 WAVE 파일의 힙이다.


[그림 5] 일반적인 WAVE 힙

 

이 두 힙을 비교해보면 알 수 있듯이, 익스플로잇은 RIFF도, WAVE도, fmt도, 아무것도 없는 잘못된 포맷이다.

일반적인 WAVE 파일은 헤더가 “52 59 46 46”으로 시작해야하고, 9~12바이트에서 “57 41 56 45”(“WAVE”)가 있어야하며 뒤이어 “66 6d 74 20”(fmt )가 있어야 한다.

이 잘못된 형태의 멀티미디어파일을 타겟 유저가 실행함으로써 예외가 발생하여 정수형 오버플로우를 유발한다.

 

3. 위험 분석

비정상적인 형태의 파일이 취약한 버전의 Windows Media Player로 재생될 때 정수형 오버플로우로 인해 DoS가 발생한다.


4. 대응 방안


현재 패치가 없는 상태이기 때문에, 의심스러운 WAV, SND, MID 파일을 Windows Media Player로 열지 않아야 한다.

패치는 해당 함수의 DIV 연산 수행시에 값의 최대값을 check를 하는 방법으로 이루어질 것이라고 예상된다.


5. 관련 사이트

본 취약점에 대한 추가적인 정보를 확인할 수 있는 관련 사이트는 다음과 같다.

CVE-2008-5745

CWE-189

http://www.milw0rm.org

http://securityreason.com/securityalert/4823

http://blogs.technet.com/msrc/archive/2008/12/29/questions-about-vulnerability-claim-in-windows-media-player.aspx

http://www.securityfocus.com/bid/33018



C
opyright(c) 1998-2009 A3 Security ,LTD


Disclaimer
※ 현재 ㈜에이쓰리시큐리티에서 테스트 및 분석 중에 있으며, 이 문서는 계속 업데이트될 것입니다. 본 문서는 보안취약점으로 인한 피해를 최소화하는 데 도움이 되고자 작성되었으나, 본 문서에 포함된 대응방안의 유효성이나 기타 예상치 못한 시스템의 오작동 발생에 대하여서는 ㈜에이쓰리시큐리티에서는 일체의 책임을 지지 아니합니다.

▷ 작성자 : 붉은반점(r3dp0int@a3sc.co.kr)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)


[A3AID08-05]
Excel Viewer OCX Insecure Overwrite
공격 보안 권고안

 


취약점 세부 분석 :

 1. 취약점 내용
본 취약점은 Excel Viewer ActiveX 에서 제공하는 HttpDownloadFile() 메소드에서 파일의 중복 시 사용자의 확인을 받지 않고 중요파일을 덮어쓰기하는 과정에서 발생하였습니다.

아래 그림은 OleViewer 를 이용하여 HttpDownloadFile 메소드를 확인하는 화면입니다.


[그림 1] HttpDownloadFile 메소드 확인

[그림 1]을 보면 본 메소드에는 두 개의 파라미터가 필요함을 알 수 있습니다. 이름에서 알 수 있듯이 첫번째 파라미터에는 웹 서버에 존재하는 파일의 URL 입력 부분이고, 두번째는 파일 다운로드하여 저장할 로컬 드라이브의 위치를 입력하는 부분입니다.

아래는 HttpDownloadFile 메소드를 이용하여 임의의 웹서버에 존재하는 notepad.exe(메모장)를 windows 시스템폴더에 calc.exe(계산기)라는 이름으로 저장하는 웹페이지의 소스입니다. 공격 성공 시, 사용자가 Overwrite 된 계산기 프로그램을 인지하지 못하고 계산기로 둔갑한 메모장 프로그램을 실행시키게 됩니다.


[그림 2] 파일 다운로드 웹페이지 소스

[그림 2]는 exploit 소스파일입니다. 클래스 ID를 Server에는 웹서버에 notepad.exe 파일을 저장해놓은 후 그 위치를 나타내는 URL을 Server 값으로 정해준 후에, 공격 대상인 calc.exe 파일의 위치를 Local 값으로 정해줍니다. 그 후에는 HttpDownloadFile메소드에 파라미터 값을 입력합니다. 18번 줄은 테스트의 편의성을 위해 버튼을 장치하여 클릭 후 결과 확인을 할 수 있도록 하였습니다. 본 코드의 목적은 웹페이지를 방문하여 exploit이라고 씌여져 있는 버튼을 클릭하면 서버의 notepad.exe가 윈도우 폴더에 calc.exe라는 파일로 저장이 되도록 하는 것입니다. 
 
아래의 그림은 이를 확인하는 화면입니다.


[그림 3] exploit이 존재하는 웹페이지 화면

버튼을 클릭하게 되면 사실 브라우저상의 반응은 전혀 없습니다. 하지만, 아래의 그림처럼 windows 시스템폴더에 calc.exe 파일이 메모장 아이콘으로 바뀐 것을 확인할 수 있습니다.


[그림 4] calc.exe파일의 아이콘이 메모장 아이콘으로 변경된 화면

사용자는 이 사실을 인지하지 못하고 평상시와 같은 방법으로(보조프로그램의 계산기 클릭, 명령창에서 calc 입력) 계산기를 실행시키게 되면 계산기가 아닌 메모장이 화면에 출력되는 것을 확인할 수 있습니다.


[그림 5] calc.exe(계산기)를 실행한 후에 메모장이 출력된 화면

위와 같이 파일이 Overwrite되는 것을 확인하였습니다.

2. Overwrite 예외사항
해당 취약점은 몇가지 예외사항에 의해 Overwrite 되지 않았습니다. 파일에 쓰기권한이 없을 때와 현재 exe파일이 실행중인 경우입니다. 따라서, 일반적으로 사용하지는 않지만 빈도수가 낮지 않은 그림판이나 계산기 같은 파일에 대해 공격이 이루어진다면 충분히 공격 가능성이 있습니다.


3. 위험 분석
해당 취약점은 공격자가 사용자의 컴퓨터에서 자주 사용하면서도 보통 때는 실행시켜놓지 않는 파일인 calc.exe(계산기) 등의 파일을 악성파일(웜이나 바이러스), 백도어 등의 파일로 Overwrite할 수 있습니다. 요즘 많이 사용되고 있는 XSS 공격이나 URL Redirection에 악용될 수 있는 소지가 있습니다.

 
4. 대응 방안
현재 테스트 대상은 최신 ActiveX 패치이며 악성프로그램이 복사되도록 막기 위해 백신을 설치하고 항상 최신패치를 유지할 것을 권고합니다.
 

5.  관련 사이트
http://www.milw0rm.com/exploits/7739 


6. 특이 사항
취약점 분석이 Excel Viewer OCX를 대상으로 이루어졌지만 Word Viewer OCX도 같은 메소드가 존재하기 때문에 같은 취약점을 가지고 있습니다. Word Viewer OCX 사용자 분들께서도 이와 같은 취약점에 주의해주시기 바랍니다.

Copyright(c) 1998-2009 A3 Security ,LTD


Disclaimer
※ 현재 ㈜에이쓰리시큐리티에서 테스트 및 분석 중에 있으며, 이 문서는 계속 업데이트될 것입니다. 본 문서는 보안취약점으로 인한 피해를 최소화하는 데 도움이 되고자 작성되었으나, 본 문서에 포함된 대응방안의 유효성이나 기타 예상치 못한 시스템의 오작동 발생에 대하여서는 ㈜에이쓰리시큐리티에서는 일체의 책임을 지지 아니합니다.