Reverse & More

※ CVE-2011-0611 Adobe Flash Player Zero-Day 취약점에 대한 정보를 등록합니다.
   본 취약점은 MS Office MSWord와는 무관한 Adobe Flash Player내의 취약점입니다. 


[ 파일 정보 ]
파일명 :: Disentangling Industrial Policy and Competition Policy.doc
            ( 내부 파일명 :: [Malware] Disentangling Industrial Policy and Competition Policy.doc )
파일 크기 :: 176,144 ( Bytes )
MD5 :: 96cf54e6d7e228a2c6418aba93d6bd49

파일명 :: Japan Nuclear Weapons Program.doc
            ( 내부 파일명 :: [Malware] 2011.doc )
파일 크기 :: 167,440 ( Bytes )
MD5 :: df45a5bc07153b20af1e375626b5addc
 
< 샘플 파일 >

CVE-2011-0611.zip

Exploit DB :: http://www.exploit-db.com/exploits/17175/

[Exploit DB] CVE-2011-0611.zip

 [ 동적 분석 ]

0. 동작 시나리오

< Figure. 동작 시나리오 >

1. 최초 유입

< Figure. Mail을 통한 Malicious DOC 파일 전파 >

2. Malicious DOC 파일 실행 

< Figure. Malicious DOC 파일 실행 화면 >

   :: Malicious DOC 파일을 실행하면 악성 동작을 완료한 후 사용자가 악성 동작 의심을 갖지 않도록 정상DOC 파일
      을 보여준다. 

3. Binary 확인
1) SWF 파일 확인

< Figure. DOC 파일내의 SWF 파일 >

   :: SWF File Format 에 따라 DOC내에 확인된 SWF 파일은 Signature + Version까지 모두 포함한 파일 크기가
     <Figure. DOC 파일내의 SWF 파일> 에서 언급한 파일 크기 0x2775 이다. 따라서 위의 SWF 파일 크기는
     10,101 Bytes가 된다.
     ( 실제 다른 분석 정보를 참고하면 파일의 크기가 10,421 Bytes로 되어 있으나 아직 그 이유는 모르겠다. )

2) SWF DeCompile

파일명 :: 513.swf ( 추정 )
파일 크기 :: 10,101 Bytes
MD5 :: 79b1c0ed2df4977d70c7d21817213fa6

< Figure. SWF 파일 생성 >

   :: SWF를 DeCompile 할 수 있는 Tool은 여러가지가 있겠지만 우선 내가 알고 있는 swfdump.exe를 이용할 것
      이다. 우선 DOC에서 확인한 SWF 파일을 확인한 크기 ( 10,101 Bytes )를 HxD 등의 Hex Editor 툴을 이용해
      별도의 파일로 저장한다. ( Offset 0x2E08 ~ 0x557D ) 이때 1)에서 언급한 파일 크기 10,421 Bytes로도 파일
      을 생성해 보겠다. ( Offset 0x2E08 ~ 0x56BD )
     - Dump_10101.swf ( Size :: 10,101 Bytes )
     - Dump_10421.swf ( Size :: 10,421 Bytes )
   :: 내부 문자열을 통해 추정해 보면 내장된 SWF 파일명은 "d:\513.swf" 이다. 

< Figure. swfdump.exe를 이용한 DeCompile 시도 >

< Figure. 생성된 DeCompile 파일 >

   :: swfdump 를 사용해 DeCompile을 수행한다. 이때 두 파일의 DeCompile 내용을 비교해 차이가 무엇인지 확인
      해 보겠다. 실제 두 파일을 DeCompile 하면 다음과 같이 10,421 Bytes를 갖는 파일의 경우 Error가 발생하며
      DeCompile 파일을 생성하지 못하지만 10,101 Bytes 파일의 경우 정상적으로 DeCompile이 되는 것을 확인할 수
      있다. 따라서 다른 분석 정보에서 10,421 Bytes로 입력한 이유는 아마 샘플의 차이가 아닐까 생각한다.
   :: 이제 생성된 DeCompile 파일을 분석해 보겠다.
< DeCompile 파일 >

3-1) DeCompile 파일 분석 ( swfdump.exe 이용 )
    :: DeCompile이라고 표현했으나 실제는 SWF 파일형식에 맞춰 Assembly를 했다고 보는게 맞다. 
    :: 10101 Bytes 파일이 우리가 원하는 악성 SWF 로 추정되므로 이를 Action Script DeCompiler를 통해 소스
       레벨의 내용을 확인할 수도 있다. ( Decoded Action Script Code )
    :: Assembly 된 파일에서 ShellCode를 확인할 수 있고 해당 ShellCode는 push를 통해 Stack/Heap에 저장되는
       것을 알 수 있다. x86 Assembly에서 PUSH 명령어는 Stack에 저장하는 명령어이므로 Stack에 저장하는 것으로
       추정할 수 있다. 그럼 위의 ShellCode를 확인해 보자.

3-2) DeCompile 파일 분석 ( Action Script Decompiler 이용 )

   :: Assembly 형태로 표현된 것과 크게 차이가 나지 않음을 알 수 있다. 
< DeCompile 파일 >

4) ShellCode 분석

파일명 :: Unknown
파일 크기 :: 1,484 Bytes
MD5 :: a7435d599a0b7e9ffd5f94338412a93d

   :: ShellCode로 추정했던 부분이 SWF 파일이었다. 즉, SWF 파일내에 실제 Crash를 발생시키는 SWF 파일이
     내장되어 있다는 것이다. 이 파일을 Assembly 로 확인해 보자.

<Figure. swfdump.exe  Error 발생 >

[ 정밀 분석 ]










* 참고 사이트
  - MS Technet :: http://blogs.technet.com/b/mmpc/archive/2011/04/12/analysis-of-the-cve-2011-0611-adobe-flash-player-vulnerability-exploitation.aspx
  - BugiX :: http://bugix-security.blogspot.com/2011/04/cve-2011-0611-adobe-flash-zero-day.html
  - AhnLab :: http://blog.ahnlab.com/asec/518
  - Sempersecurus :: http://sempersecurus.blogspot.com/2011/04/using-volatility-to-study-cve-2011-6011.html

[ 참고 사이트 ]
CVE :: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0611
National Vulnerability :: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0611
Security Focus ::  http://www.securityfocus.com/bid/47314
Secunia :: http://secunia.com/advisories/cve_reference/CVE-2011-0611/ 
Adobe Security Bulletin :: http://www.adobe.com/support/security/advisories/apsa11-02.html 

Update 2011.04.15

Adobe의 Zero-Day가 Patch 되었다. 
* 관련 기사 
  - Threatpost :: http://threatpost.com/en_us/blogs/adobe-patch-flash-zero-day-windows-mac-friday-041411
  - Virus Bulletin :: http://www.virusbtn.com/news/2011/04_14.xml?rss
 

※ Adobe에서 공개한 SWF File Format Spec v10.pdf 파일을 기준으로 한 내용이며 다음의 Post는
   해당 문서중 Appendix A : SWF Uncovered - A Simple SWF File Dissected 의 내용 일부를 번역한
   것이다.

[ Appendix A ]
SWF Uncovered : A Simple SWF File Dissected 

SWF  파일을 만들기 위해선, RAW Bit와 Bytes를 읽고 이해할 수 있어야 한다. 이 Appendix에서는 하나의 Rectangle과 하나의 Frame으로 되어 있는 SWF 파일을 통해 간단히 알아 보겠다.

다음은 SWF 파일의 Hex dump 이다. Figure 1

SWF파일은 항상 Header로 시작된다. Header는 파일 버전, Byte 단위의 파일 길이, Twip 단위의 Frame 크기, 초당 Frame의 Frame Rate, Frame Count 등이 포함된다.
그 타입은 11 페이지의 Chapter 1. "Basic Data Type" 에 정의되어 있다.
Figure 2

첫 세 Bytes는 모든 SWF 파일의 표준 Signature이다. 표준 Signature는 ASCII 값 "F" ( 또는 "C" ) , "W" , "S" 이다.
네번째 Byte는 파일의 버전을 의미한다.

0x46 ▶ "F"   0x57 ▶ "W"   0x53 ▶ "S"   0x03 ▶ 3

다음 네 Bytes는 Unsigned 32-Bit Integer로 파일 크기를 가리킨다. 시스템의 Architecture에 따른 약간의 Trick이 있다. Figure 1을 통해 다음 4Bytes를 확인하면 0x4F000000 으로 파일 길이가 1325400064 Bytes가 된다. 이 값은 너무 큰 값이다. SWF 파일에서, Bytes는 0xB1B2B3B4의 32Bit 값은 0xB4B3B2B1로 쓰여진고 16Bits 0xB1B2는 0xB2B1으로 쓰여진다. 이러한 이유는 MAC과 PC 의 프로세서간의 저장장치와 반환간의 차이 때문이다.

역으로 4Bytes를 읽어보면 파일은 79 Bytes 길이가 된다.

0x4F000000 ▶        0x0000004F ▶         79

다음 9Byte는 Rectangle이라는 SWF 파일 포멧에서 사용하는 데이터 구조체이다. 다음은 Rectangle의 각 Parameter를 설명한 부분이다.
Figure 3

이러한 Bytes을 이해하기 위해, 각각의 개별 Bits를 확인해야 한다.
Figure 4

Rectangle 구조체는 5개의 Field로 구성되어 있다. : Nbits , Xmin , Xmax , Ymin , Ymax. Unsigned Nbits Field는 Rectangle의 첫 5Bits로 다음 네개의 Field의 길이를 기리킨다. SWF 파일에서 또 다른 미묘한 부분은 Bit를 읽고 쓸때 Word와 dwords에 차이가 있다. Bits를 읽고 쓸때, Byte-Swapping은 발생하지 않는다. 이는 Flash Player는 n-bit Field를 읽을 때, n Bits를 모두 읽을 때 까지, Bytes 단위로 읽기 때문이다. 그러므로, 다음 5Bits는 다음과 같이 읽어야 한다.

01111 ▶ 15

Nbits의 값 16은 무엇일까? 이는 Word의 크기를 나타내는 것으로 Word와 Swap Bytes로 다음의 Field와 같이 읽어야는 것인가? 그렇지 않다. Field는 Bit 크기를 가리키므로 항상 Byte 단위로 읽어들인다. Swapping 없이 단순하게 순서대로 읽으면 된다.

Figure 5

Header에서 Rectangle은 파일의 Height를 위해 Xmax와 Ymax 치수를 파일에 저장하기 위해 사용한다. SWF 포멧에서, Twip은 20/픽셀 을 의미한다. 그래서 만약 픽셀을 변환하면, 파일은 550 * 400이 된다.

이제 Rectangle Field를 모두 확인해 계산해 보았다. 그러나 마지막 7Bits는 왜 0일까? Byte 경계를 맞추기 위해 0으로 채워놓은 것이다.

0000000 = pagging bits

어떤 구조체 다음, 마지막 Bytes까지 정확하게 채워져 있지 않다면, Byte 단위 정렬을 위해 0으로 채운다. 그래서 만약 다음 Item이 Word나 dword이면, Bytes의 중간부터 읽어야 한다는 걱정없이 읽을 수 있다. 이 경우, 마지막 Byte내의 1Bit를 사용해 나머지는 0으로 채워진다.

Header의 다음은 Frame Rate이다. Frame Rate는 16Bit Integer로 저장되어 있지만, 처음 Byte는 무시한다. 그래서 Frame Rate는 12fps이다. 

0x000C ▶      0x0C00 ▶     0x0C ▶     12 Frame Rate

다음은 Frame Count로 이 또한 16 Bit Integer로 되어 있다. 그래서 Frame Count는 1이 된다.

0x0100 ▶       0x0001 ( Byte Swapping ) ▶     1 = Frame Count

( 역 - 지금까지 위에서 설명한 내용을 바탕으로 악성 SWF 파일을 분석한 구조도이다. )

Header는 이제 모두 살펴 보았다. Header 다음은 Tagged Data Blocks이 잇다. 다음은 tag에 대해 설명해 놓았다.

Figure 6

Tag의 타입은 두 종류가 있다. : Short Tag Header 와 Long Tag Header. 첫번째 Word를 찾음으로써 Tag가 시작된다.

0x4302 ▶      0x0243 ▶     000 0010 0100 0011

Tag의 첫 10Bits는 Unsigned tag 이다. Tag 타입은 다음에 따라오는 Body내의 Data Block의 Data 타입을 결정한다.이 경우 Tag 타입은 9이고, SetBackgroundColor Block을 가리킨다. 다음 Unsigned 6Bits는 62Bytes 보다 작거나 같으면 Data Block의 길이를 의미하고 62Bytes보다 크면, 이 Field는 모두 1로 그 길이는 dword가 가리키게 된다. 우리가 살펴본 Tag에서, Field는 모두 1이 아니므로, 3Bytes 길이값을 의미한다.

0000 0010 01 = 9 = SetBackgroundColor
00 0011 = 3 = Body Length

Body의 길이가 3Bytes이므로, Body를 살펴보자. SetBackgroundColor tag는 3Bytes의 RGB color를 갖고 있으므로 다음과 같이 계산할 수 있다. Color은 3Bytes Data Type이므로 Byte Swapping은 일어나지 않는다.

0xFFFFFF = White

다음 Tag는 Long Tag이고 DefineShape Tag 이다.

0xBF00     0x00BF     0000 0000 1011 1111

0000 0000 10 = 2 = DefineShape

11 1111 = 63 = Body Length
( 다음 두 Bytes가 Body Length를 가리킨다. ( 역-Body Length가 62Bytes를 넘었기 때문에 다음 2Bytes가 Body Length가 된다. ))

0x23000000     0x00000023     35 = Body Length

다음은 DefineShape 을 정의한 것이다.

Figure 7

( 역 - 이 이후의 추가적인 번역은 수행하지 않겠다. 하지만 지속적으로 Tag를 찾아가 Parsing해 원하는 정보를
         얻는 과정은 모두 동일하다. )

National Vulnerability Database :: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3654