▷ 작성자 : Hong10 (hong10@a3sc.co.kr)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)
문서 작성일 : 2009년 2월 4일
최종 수정일 : 2009년 2월 5일
Hong10님께서 이번에는 "Microsoft Excel Could Allow Remote Code Execution(MS08-14)" 에 대해 집중 분석을 하였습니다. 개요 및 설명 (1부), 취약점 분석 (2부)로 하여 포스팅을 하겠습니다.
개요 및 설명
08년 3월쯤 나온 Micro Office Excel 관련 취약점에 대하여 분석을 해보며 해당 분석을 이용하여 Exploit 코드로 만든 취약점을 가진 엑셀 파일이 아닌 분석을 토대로 취약점을 가진 문서를 만들어 보겠습니다. Micro Office 관련 파일은 Compound Document Format 을 가지며 관련 특징을 설명 하며 나아가 새로운 취약점을 발견하는 것을 목표로 이 문서를 제작 합니다.
아래 사이트에서 관련 Exploit 코드를 받을 수 있습니다.
URL)http://www.milw0rm.com/exploits/5287
1. Compound Document Format
일반적인 excel 파일을 생성 후(macro활성) 문서의 바이너리 값 분석. 아래는 200h 크기의 Header 내용입니다.
위 그림에서 각각의 값들이 가지는 내용을 알아 보겠습니다.
1) 8bytes containing the fixed compound document file identifier
위 8byte가 나타내는 값은 compound 문서를 나타내는 식별자 입니다.
2) 16bytes containing a unique identifier, followed by 4bytes containing a revision number and a version number. These values can be skipped.
16바이트의 값은 유니크 한 식별자(UID) 값으로써 대부분 0값으로 채워져 있습니다. 또한 뒤 4바이트는 (0x003e,0x0003) 값은 버전을 나타내는 값으로 거의 대부분 저 값으로 할당 되어 집니다.
3) 2bytes containing the byte order identifier. It should always consist of the byte sequence 0xFEFF
0xfeff는 little-endian 이고 0xfffe는 big-endian 을 뜻합니다.
4) 2bytes containing the size of setors. 2bytes containing the size of short-sectors. The size is 512 bytes, and the short-sector size 64bytes.
0x0900 은 sector size 를 뜻하며 크기는 512 바이트입니다. 또한 0x0600 은 short sector size 를 뜻하며 크기는 64바이트입니다.
5) 10bytes without valid data, can be ignored.
위 10바이트는 무시해도 좋다.
6) 4bytes containing the number of sectors used by the sector allocation table. The SAT uses only one sector
위 4바이트는 SAT 가 몇 개나 사용되었는지 나타내며 현재 SAT 가 하나 사용된 것을 알 수 있습니다.
7) 4bytes containing the SecID of the first sector used by the directory. The directory starts at sector 1
위 4바이트는 directory 의 시작점을 알 수 있으며 sector 첫 번째 에서 시작됨을 알 수 있습니다.
8) 4bytes with out valid data ,can be ignored.
위 4바이트는 무시해도 좋습니다.
9) 4bytes containing the minimum size of standard streams. This size is 0x00001000 = 4096 bytes
표준 스트림 의 최소 사이즈를 나타내며 현재 4096 바이트가 할당 되었음을 알 수 있습니다.
10) 4bytes containing the SecID of the first sector of the short-sector allocation table, followed by 4 bytes containing the number of sectors used by the SSAT. In this example the SSAT starts at sector 2 and uses two sector
위 처음 4바이트는 SSAT가 섹터 2번째부터 시작됨을 알 수 있으며 다음 4바이트 에서 SSAT 가 2개 할당됨을 알 수 있습니다
11) 4bytes containing the SecID of the first sector of the master sector allocation table , followed by 4bytes containing the number of sectors used by the MSAT. The SecID here is -2(End of Chain SecID) which states that there is no extended MSAT in this file.
처음 4바이트는 -2 값으로 SecID 체인에 의해서 끝을 나타냅니다. 따라서 MSAT 는 할당 되어 있지 않으며 다음 4바이트는 MSAT 할당 수 인데 0 임을 알 수 있습니다.
12) 436 bytes containing the first 109 SecID of the MSAT. Only the first SecID is valid , because the SAT uses only one sector (see above). Therefore all remaining SecIDs are set to the special Free SecID with the value -1 The only sector used by the SAT is sector 0
마지막으로 436바이트 만큼은 MSAT의 SecID를 나타내며(즉 SAT의 SecID 라고 이해하면 좋다) 처음 4바이트 값은 유효하며 그 값은 0을 나타냅니다. 이는 하나의 섹터가 SAT 로 사용되며 0 SAT는 0 섹터에서 시작됨을 알 수 있습니다.
다음은 SAT (Sector Allocation Table) 을 그 크기는 512바이트로써 위 헤더에서 할당 되었습니다.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 .. -3 8 20 4 5 6 7 9 11 10 11 12 13 14 15 16 18 27 19 21 -2 22 23 ..
SAT 역시 chain 으로 이뤄 져 있습니다. 앞서 살펴본 MSAT는 SAT chain을 포함하였으며 그 값은 [0,-2] 로 이뤄졌었습니다. 즉 MSAT는 SAT 의 chain을 나타냈으며 SAT 에서는 실제로 할당된 섹터의 오프셋의 chain이라고 생각하면 되겠습니다.
위에서 첫 4바이트는 -3 값으로 SAT 의 시작을 알리는 SecID 라고 보시면 됩니다. 위에서 생성된 SecID 의 배열을 나타내면 아래와 같습니다.
위 표에서 알 수 있듯이 SecID chain 에 의해서 가령 1번의 SecID 가 8임을 알 수 있고 8번에는 11을 가리키며 11은 12 이런 형태로 전달 되다가 -2 를 만나게 되면 끝이 됨을 알 수 있습니다. 0 1 2 3 4 5 6 7 8 9 10 .. 47 48 49 50 51 52 53 54 55 .. 1 2 3 4 5 6 7 8 9 10 11 48 49 50 51 52 53 54 55 -2 ..
다음은 SSAT 의 값들입니다. 역시 헤더에서 SSAT 의 진입 오프셋 값이 섹터의 2번째임을 알 수 있었고 아래와 같은 SecID 의 chain 값들로 이루어 져 있습니다.
역시 사이즈는 200byte(섹터의 크기이며 헤더에서 선언한 64바이트의 크기는 할당 되는 크기임을 헷갈리지 마시길) 만큼 선언이 됩니다. 이걸 또한 표로 살펴보면 다음과 같습니다.
다음은 Directory 헤더에 대하여 알아봅시다. Directory 가 존재하는 이유는 Compound Document 의 특징상 여러 형태의 파일 스트림과 MS 고유한 OLE 특성 때문에 여러 스트림 에 대하여 트리 구조 형태의 Storage 가 있어서 관리에 용이하기 위하여 존재하는 것 같은 개인적 생각입니다.
다시 처음으로 돌아가 Diretory 의 시작부분은 헤더에서 섹터의 첫 부분에 선언이 되어 있습니다. 또한 각 섹터당 4개의 Directory entries 를 가집니다.(즉 한 Directory의 정의부분의 크기는 128byte)
위 그림에서 알 수 있듯이 Sector 1에는 4개의 Directory entries 가 존재함을 알 수 있다. 여기서 각 Directory 가 갖는 값의 특징을 알아 보겠습니다.
1) 64bytes containing the character of the entry name
64바이트의 크기를 가지며 entry name 을 의미합니다 또한 유니코드 형태이므로 2바이트씩 한 character를 의미합니다.
2) 2bytes containing the valid rage of the previous character array
위에서 정의된 entry name 의 character 의 배열 수 이며 널을 포함하여 22개의 배열을 가짐을 알 수 있습니다.
3) 1byte containing the type of the entry. Must be 0x05 for the root storage entry.
0x05값은 Root storage 을 의미합니다.
4) 1byte containing the node colour of the entry. It is red in this example, breaking the rule that the root storage entry should always be black.
5) 4bytes containing the DirID of the left child node, followed by 4 bytes containing the DirID of the right child node. Should both be -1 in the root storage entry.
처음 4바이트의 -1 값은 왼쪽 자식 node 를 포함 하고 있는지 나타내며 뒤 4바이트의 -1은 오른쪽 자식 node 를 포함 하고 있는지 나타냅니다. Root storage 이므로 -1값을 가집니다.
6) 4 bytes containing the DirID of the root node entry of the red-black tree of all members of the root storage. It is 1 in this example
7) 16bytes containing a unique identifier, followed by 4bytes containing additional flags, and two time stamps, 8bytes each, containing the creation time and last modification time of the storage. This data can be skipped
8) 4bytes containing the SecID of the first sector or short-sector of a stream, followed by 4 bytes containing the stream size. In case of the root storage entry, this is the SecID of the first sector and the size of the short-stream containing stream. It starts at sector 3 and has a size of 0x00002c00 = 11264 bytes in this example
처음 4바이트의 3 값은 Root Storage 가 섹터 3 에서부터 시작을 한다는 의미입니다. 또한 뒤 4바이트는 해당 DIR 의 크기를 나타낸 것이며 11264 바이트 크기를 가지고 있습니다.
1부는 여기서 마치겠습니다^^)..2부는 빠른 시일내로 포스팅 하겠습니다.
Copyright(c) 1998-2009 A3 Security ,LTD
Disclaimer
※ 현재 ㈜에이쓰리시큐리티에서 테스트 및 분석 중에 있으며, 이 문서는 계속 업데이트될 것입니다. 본 문서는 보안취약점으로 인한 피해를 최소화하는 데 도움이 되고자 작성되었으나, 본 문서에 포함된 대응방안의 유효성이나 기타 예상치 못한 시스템의 오작동 발생에 대하여서는 ㈜에이쓰리시큐리티에서는 일체의 책임을 지지 아니합니다.