TEAMCR@K

▷ 작성자 : indra (indra@a3security.com)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)


Zeroboard 4 취약점 분석완료(2건) 하였으며 현재 해당 벤더사에게 보고 절차중입니다.

패치 되는대로 상세내역을 포스팅 하도록 하겠습니다.


Copyright(c) 1998-2009 A3 Security ,LTD

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

▷ 작성자 : indra (indra@a3security.com)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)

Castle (PHP버전) 취약점 분석완료 하였으며 현재 해당 벤더사에게 보고 절차중입니다.

패치 되는대로 상세내역을 포스팅 하도록 하겠습니다.


Copyright(c) 1998-2009 A3 Security ,LTD

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

▷ 작성자 : indra (indra@a3security.com)
▷ 편집자 : 니키 (ngnicky@a3sc.co.kr)

WebKnight 우회기법 취약점 분석완료 하였으며 현재 해당 벤더사에게 보고 절차중입니다.

패치되는대로 상세내역 포스팅 하겠습니다.


Copyright(c) 1998-2009 A3 Security ,LTD

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

▷ 작성자 : 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바이트로써 위 헤더에서 할당 되었습니다.

SAT 역시 chain 으로 이뤄 져 있습니다. 앞서 살펴본 MSAT는 SAT chain을 포함하였으며 그 값은 [0,-2] 로 이뤄졌었습니다. 즉 MSAT는 SAT 의 chain을 나타냈으며 SAT 에서는 실제로 할당된 섹터의 오프셋의 chain이라고 생각하면 되겠습니다.

위에서 첫 4바이트는 -3 값으로 SAT 의 시작을 알리는 SecID 라고 보시면 됩니다. 위에서 생성된 SecID 의 배열을 나타내면 아래와 같습니다.

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	..

위 표에서 알 수 있듯이 SecID chain 에 의해서 가령 1번의 SecID 가 8임을 알 수 있고 8번에는 11을 가리키며 11은 12 이런 형태로 전달 되다가 -2 를 만나게 되면 끝이 됨을 알 수 있습니다.

다음은 SSAT 의 값들입니다. 역시 헤더에서 SSAT 의 진입 오프셋 값이 섹터의 2번째임을 알 수 있었고 아래와 같은 SecID 의 chain 값들로 이루어 져 있습니다.

역시 사이즈는 200byte(섹터의 크기이며 헤더에서 선언한 64바이트의 크기는 할당 되는 크기임을 헷갈리지 마시길) 만큼 선언이 됩니다. 이걸 또한 표로 살펴보면 다음과 같습니다.

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	..

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

1월 23일에 올렸던 파이어폭스(FireFox)의 Clickjacking 에 대해서(http://teamcrak.tistory.com/58) 문서를 포스팅 했는데, 몇일 사이에 Google Chorm 과 Internet Explorer 7 대상에 대해서도 관련 공격문서가 발표되었습니다.

Firefox 3.0.5 Status Bar Obfuscation / Clickjacking
Google Chrome 1.0.154.43 ClickJacking Vulnerability (2009-01-23)
Internet Explorer 7 ClickJacking Vulnerability (2009-01-23)

아래는 Internet Explorer 6에서 테스트한 결과입니다. Internet Explorer 7 도 동일한 결과가 나올거라 판단됩니다.



이 부분에 대한 보안뉴스의 기사내용입니다.
http://www.boannews.com/media/view.asp?page=1&idx=14065&search=&find=&kind=1

Internet Explorer 8의 X-FRAME-OPTIONS 기능과 FireFox의 NoScript Firefox plug-in 기능을 사용하여 보안을 하는 부분도 있지만, 이것을 제한하게 되면 그만큼 웹 서비스를 이용하는데 제한이 심할거라 판단됩니다.

우선은 일반사용자들이 링크문서에 대한 접근을 조심할 수 밖에 없는듯 합니다.

Copyright(c) 1998-2009 A3 Security ,LTD

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

현 A3시큐리티 지식사업팀장이 발표한 내용에 대한 뉴스입니다.

뉴스 링크 : http://www.boannews.com/media/view.asp?page=4&gpage=1&idx=13982&search=&find=&kind=0

기사 내용으로 접하다 보니 전달이 잘 안되는 부분이 있습니다.

중요한것은 우회 기법에 대한 필터링을 지속적으로 업데이트 해야 하는 방향과 개발 소스단(ASP, JSP, PHP, ASP.NET 등)에서 원척적으로 해당 취약점에 대한 대응방안에 따라 개발을 해야 합니다.

또한 게시판 Editor 솔루션을 보안적인 측면을 생각하지 않고 그대로 사용하고 있는 경우를 많이 볼 수 있습니다. 웹 서비스의 보안에 맞게 (Customize) 수정을 하여 사용할 수 있도록 관리해야 합니다.

▷ 작성자 : 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

Copyright(c) 1998-2009 A3 Security ,LTD

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

 

취약점 세부 분석 :

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

 

클릭잭킹(Clickjacking)이란 마우스 클릭(Click)과 하이잭킹(Hijacking)의 합성어로,  사용자 입장에선 자신이 보고있는 웹 페이지의 콘텐츠를 클릭하지만, 실제로는 다른 웹 페이지의 콘텐츠를 클릭하는 것입니다.
즉, 사용자는 눈치채지 못하는 사이에 자신이 원하지 않는(위험가능성이 있는) 콘텐츠나 링크를 클릭 할 수 있는 취약점입니다. XSS(Cross Site Scripting)와 CSRF(Cross Site Request Forgery)의 응용버전 인것 같은데, 최근 주목받고 있는 보안 동향중에 하나라고 합니다.

milw0rm에서도 2009년 1월 21일짜로 올라왔군요. 예제는 파이어폭스(Firefox)에서만 테스트가 됩니다.(Internet Explorer 에서는 링크된 주소로 정상적으로 이동됩니다)

http://milw0rm.com/exploits/7842

이전 5~6년전에 URL정보에 0x01 문자를 넣어 주소표시줄에 출력되는 URL정보와 실제 이동하는 URL이 달라서 사용자를 속일 수 있는 취약점이 있었는데 비슷한 개념이라고 생각하시면 될것 같네요. (공론화 이후 해당 결함은 패치되었습니다.)
http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2003-12/0353.html

참고로 CSRF 취약점을 익스플로잇 할때 iframe 태그에 width, height 를 0 값으로 채울때 IE는 아무런 특이점도 발견하지 못했는데, firefox, opera 같은 경우는 5x5 pixel 정도 되는 어떤 모양이 되었습니다.
이럴때 div 태그를 iframe 양 옆에 감싸주고 div 태그의 width, height 값을 0으로 주면 완벽하게 사용자를 속일 수 있었습니다.

<div style="position:absolute; width:0px; height:0px; overflow:hidden"><iframe src="URL" width=0 height=0></iframe></div>

[참고사이트]

예제 사이트
http://blog.daum.net/memonpaper/6941607

ClickJacking에 대한 간단한 Demo
http://www.planb-security.net/notclickjacking/iframetrick.html

직접할 수 있는 데모 사이트
http://guya.net/security/clickjacking/game.html

ClickJacking 시연 동영상
http://kr.youtube.com/watch?v=gxyLbpldmuU

ZDNet Korea 뉴스
http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039173575

방지책
http://phpsec.org/projects/guide/2.html

Copyright(c) 1998-2008 A3 Security ,LTD

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

홈페이지 보안 강화도구(CASTLE) 가 보급되었네요.

테스트는 아직 하지 않았지만 사용자 가이드를 읽어보니 웹방화벽 기능이 포함되어 있고 웹관리가 잘되어 있는거 같습니다.

해당 사이트 : http://www.krcert.or.kr

○ CASTLE 다운로드(ASP, PHP, JSP)
○ CASTLE 사용자 설명서 다운로드
○ CASTLE 설치 가이드 다운로드
○ CASTLE FAQ 다운로드
○ 문의 및 기술 지원(Tel : 02-405-5617, EMAIL : castle@krcert.or.kr)

CASTLE 기본 설정 화면입니다. 관리 페이지는 아주 깔끔하네요.

SQL Injection과 XSS(Cross Site Scripting) 에 대응한 정책 설정 페이지입니다. 다른 웹방화벽과 비슷한 패턴(Signature)를 가지고 있네요..


파일로 패턴들이 저장되어 있는 화면입니다. 쉽게 적용할수 있게 되어 있네요..

각 공격에 대한 우회방식에는 어느정도까지 대응할지는 더 점검을 해보고 업데이트가 필요하겠죠?^^)..

개인적으로나 연구적으로 사용하기에는 적합한 프로그램이라고 사용되네요..