Reverse & More

※ CVE-2012-1535 취약점에 대한 정보를 게시합니다.

[ 분석 보고서 및 분석 참고 자료 ]

[ 참고 사이트 ]
CVE : CVE-2012-1535
Adobe Security Bulletin : Security Update Available for Adobe Flash Player
AlienVault : CVE-2012-1535 : Adobe Flash being exploited in the wild
nProtect 대응팀 : [긴급] CVE-2012-1535 취약점 악성파일 증가, Adobe Flash Player 업데이트 권고
MS OTF Format : The OpenType Font File

[ 분석 샘플 ]

[ 기본 정보 ]
대상 프로그램 : Flash Player 
대상 파일 : Flash32_11_3_300_270.ocx 이전 버전
취약 함수 : unknown ( createTextLine( ) 추정 )
취약점 설명 : unknown
         ( SWF 파일내의 취약한 Action Script 함수 호출로 인해 HeapSpray 발생 후 임의의 코드 실행가능 취약점 )
패치 여부 : 업데이트 가능 ( Flash32_11_3_300_271.ocx )

[ 분석 환경 ] 
OS :  Windows XP SP3 ( vmware )
Program : Office 2007 Word 
Flash Player : 11.1.102.55 ( Flash11e.ocx )

[ 취약점 공격 방법 ]
Crash 원인에 대해서는 아직 미확인 상태임.
추정 - Flex내부 함수를 통해 Font를 출력하는 과정에서 Font의 속성을 설정할 때 속성정보에 담긴 데이터의 크기에
         상관없이 Heap에 복사/접근/실행이 발생함에 따라 임의의 코드가 실행되는 형태

[ ShellCode 분석 ]

1) Main_FontClass를 생성해 FontClass로 명명한다. 이때 생성한 Main_FontClass는 FontAsset의 확장된 Class로
    Flex에서 Font 출력을 위해 사용되는 Class로 추정된다. 
   (  http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/FontAsset.html )

2) Super( ) 함수를 수행한다.

3) 내부 함수 HeapSpray( ) 를 수행한다. 

   :: ShellCode의 가장 큰 특이점은 생성한 ShellCode Block의 동작이다. 해당 취약점이 동작하면 DOC 파일내의
      추가 샘플이 Drop되어 동작하도록 설계되어 있는데 WINWORD.EXE에서 현재 실행중인 DOC 파일에 접근해야
      추가 Drop이 가능하다. 이를 위해 ShellCode 제작자는 악성 DOC 파일의 핸들을 얻는 방법으로 일반적으로 PID
      를 얻는 방법인 4씩 증가시키며 특정 함수 ( GetFileSize( ) ) 의 인자값으로 전달하는 방법을 취했다. 
      이 때문에 실제 ShellCode가 동작하는 과정에서 시간이 Random하게 소요되게 된다. 
      좀더 구체적으로 살펴보자. 
Inside 1 ) ShellCode를 별도의 EXE 파일로 작성해 동작을 확인한다. ( ShellCode2Exe )
      :: GetFileSize( )를 통해 전달하는 hFile은 마치 PID 처럼 4씩 증가시키며 전달한다. 정상적으로 GetFileSize( )
         Return을 받는다면 파일의 Size를 얻게되고 이때 얻은 파일의 크기가 0x48E000 ( DOC 파일 크기 ) 와 일치하
         는지 비교 후 추가 동작을 하게 된다. 
         전제 1) hFile은 4씩 증가하는 특성을 갖는다. 
         전제 2) GetFileSize( )로 전달되는 hFile은 Kernel Handle이다. 

      :: GetFileSize( ) 의 정의를 MSDN을 통해 확인하면 다음과 같다. 
Inside 2 ) GetFileSize( )의 정확한 동작을 확인한다. 
      :: GetFileSize( )는 아래의 그림에서 "call dword ptr [ebp + 8]" 부분이다. 

      :: 이때 전달되는 hFile은 [ebp + 113h] 부분이다. 이를 메모리에서  확인하면 다음과 같다. 

      :: 위에서 hFile은 Kernel Handle이라고 정의했다. 이를 확인해 보면 실행되는 DOC 파일은 WINWORD.EXE가 
         Open하고 있으므로 그 Handle 또한 WINWORD.EXE에 있을 것이다. 따라서 WINWORD.EXE로 Context
         Switching 이후 Handle을 조사해 봤을 때 위에서 나왔던 Handle인 0x430이 나올 것이다. 

      :: 실제 확인 결과 WINWORD.EXE가 갖는 Handle중 0x430은 "iPhone 5 Battery.doc" 악성 파일임을 알 수 있다. 

[ ShellCode 동작의 결론 ]
Handle은 4의 배수로 이뤄져 있다는 전제하에 4씩 증가시키면서 DOC 파일의 Handle이 맞을 때까지 Loop를 반복하며 DOC Size를 얻었을 때 hFile을 이용해 악성 파일 Drop을 시도하게 된다. 

4) 내부 함수 TextBlock_createTextLineExample( )를 수행한다. 

5) 내부 함수 createLine( )을 호출한다. 

Action Script는 Flex 문자열 출력과 관련된 createTextLine( ) 함수가 실행될 때 ShellCode가 실행되는 취약점을 갖고 있으며 해당 취약점은 악성 DOC 파일의 hFile을 얻기 위해 4씩 증가시켜 자신의 DOC파일의 Size가 나올때 가지 반복하는 형태를 띄고 있다. 이때 ShellCode는 HeapSpray 방법을 이용한다. 

Action Script 및 실행되는 ShellCode에 대한 분석이 완료되었으므로 정적분석을 통해 추가 분석을 진행해 보자. 
( 저 - DOC 파일 실행시 악성 DLL이 실행되는 일반적인 형태이므로 동적 분석은 제외하겠다. ) 

  ###############################################################################################
  이전에 올렸던 글에서 문제점이 발견되었다. 
  애초에 올렸던 글에 오류가 있었던 것이다. 따라서 해당 사항에 대해서는 삭제하고 관련 사항에 대한 정리는
  최상위에 추가한 분석보고서로 대체한다.
  ############################################################################################### 

[ 분석 Point ]
Crash가 발생하는 지점 :: Flash11e + 0x003d7c08 ( Flash11e!DllUnregisterServer+0x23ccda ) 
HeapSpray가 발생하는 지점 :: Flash11e + 0x 0x5D0F50 ( Flash11e!__VEC_Memcpy->_fastcopy_I( ) )

[ TIP :: SWF 파일 추출하기 ]
이번 취약점과 같이 DOC 파일내에 취약점을 갖는 SWF 파일이 존재할 경우 SWF를 분석하기 위해 DOC로 부터 해당 파일을 추출할 수 있어야 한다. 따라서 DOC에서 SWF 파일의 위치를 확인할 수 SWF File Format에 따라 파일을 추출한 후 Decompiling을 통해 분석하면 된다. 

실제 분석 샘플이었던 "iPhone 5 Battery.doc"의 경우 위와 같이 SWF파일이 DOC 내에 존재한다. 

SWF File Format을 바탕으로 확인해 보면 첫 3Bytes는 SWF Signature, 다음 1Byte는 File Version, 다음 4Bytes가 File의 크기가 된다. 따라서 분석 대상 샘플의 SWF 파일의 크기는 0x0000D6AD ( 54,957 Bytes ) 가 된다. 물론 압축되어 있는 형태 ( CWF ) 의 경우 위의 파일 크기를 바로 반영해서는 안된다. 그 이유는 CWF는 압축된 파일이고 이때 보여지는 Size는 압축이 해제된 이후 SWF 파일일 때의 Size이기 때문이다. 이는 다음에 추가로 설명하겠다.