※ 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이기 때문이다. 이는 다음에 추가로 설명하겠다. 



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

Exploit DB :: http://www.exploit-db.com/sploits/xpl_pdf.bin


취약한 버전 :: Adobe Flash Player 10.1.85.3를 포함한 이전 버전
                    Adobe Reader 7.4.0.195를 포함한 이전 버전

중요도 :: Critical ( 시스템 권한 제공 )

문제점 :: authplay.dll

임시 해결 방법 :: authplaylib 프레임워크 해제

Fix (예정) :: 2010.11.9   - Flash Player 10.x
                    2010.11.04 - Flash Player 10.x
                              ( 단, Android Patch는 별도의 스케줄로 진행 예정 )
                    2010.11.15  - Adobe Reader 와 Adobe Acrobat 9.4와 그 이전버전

취약한 버전의 Reader Down URL :: 

< 관련 샘플 >

Update10. 2010.11.24

MAPP를 통해 지속적으로 Detection_Logic이 전달되고 있다. 해당 Logic들은 CVE-2010-3654에 대한 것 뿐만 아니라 이번 Adobe 취약점 Patch시 언급된 CVE ID에 해당하는 파일들에 대한 Detection_Logic들이다.


Update9. 2010.11.15

Adobe 취약점 정규 Patch가 이뤄졌다.

Update8. 2010.11.11

전일 의문을 품었던 부분에 대해 확인 작업을 했다.

* 의문점 :: VirtualAlloc()의 Injdex를 갖고 있다면 VirtualAlloc( )을 통한 접근시 문제가 발생하도록 Hooking을 통한
               접근시 Alert가 발생하지 않을까??
* 결론 :: Alert가 발생했다. 정확히 말하면 VirtualAlloc()을 수행할 때 Error가 발생하게 되고 그로 인해 메모리를 
             확보하지 못해 ShellCode가 정상 동작을 하지 못했다.
             즉, VirtualAlloc( )을 통해 어떤 동작을 수행할 텐데 그 시점은 이미 ShellCode가 메모리에 올라와 있으며
             ShellCode의 동작중 Ret을 통해 VirtualAlloc( )을 수행하려 했으나 Hooking으로 인해 정상 동작이 되지 않
             아 ShellCode의 동작에서 Error가 발생한다는 것이다. 이 부분을 모니터링하면 실제 ShellCode가 동작할               때의 모습을 볼 수 있을 것으로 추정된다.

< VirtualAlloc()에서 발생한 Error >


* 의문점 :: 분명 Metasploit에서는 이 기법이 DEP를 우회하는 방법이라고 언급하고 있다. 그럼 DEP를 차단하게 
               되면 동작을 막을 수 있지 않을까?
* 결론 :: 실제 모니터링을 위한 Hooking을 통해 DEP를 우회하지 못해 메모리 공간에서 실행이 차단되어 다음과 
            같은 Alert가 발생했다. 즉, 이를 통해 해당 취약점은 DEP 우회가 필수임을 알 수 있다.
< DEP Alert >


Update7. 2010.11.10

Metasploit내의 ShellCode를 확인하던 중 다음과 같은 주석을 확인할 수 있었다.
    :: 주석을 확인해 보면 BIB.dll 파일의 ret2lib를 이용해 실행된다고 되어 있다.  또한 아래의 스크린 샷을 보면 
       해당 DEP 우회 방식은 이전에 나왔던  ( adobe_libtiff 모듈 내의 ) DEP 우회 방식과 유사하다고 언급하고
       있다. 실제로 PDF 샘플을 실행하면 authplay.dll 파일에서 Crash가 발생하고 ~.exe 파일이 실행되기 바로 전
       BIB.dll 파일을 Load하는 것을 알 수 있다.


    :: call [eax] 우측의 주석에서 KiFastSystemCall - VirtualAlloc() (?)과 관련된 것으로 보인다. 실제 다른 부분들
       의 주석을 참고해 보면 해당 ShellCode는 Windows Version에 영향을 받는다고 나와있다. 그 이유는
       KiFastSystemCall에서 사용할 SSDT Index Number가 Static하게 정해져 있기 때문이다. 추측컨데,
       VirtualAlloc( )에서 사용할 Sysenter의 Index Number가 Static하게 들어가 있는 것으로 추정된다. 
       그렇다면 VirtualAlloc( )을 ( Hooking을 통한 )모니터링을 하면 문제가 발생하지 않을까?

Update6. 2010.11.05

  - 패치된 Flash 버전 :: 10.1.85.3 ▶ 10.1.102.64
  - 금일 Patched 취약점
     - CVE-2010-3636 , CVE-2010-3637 , CVE-2010-3638 , CVE-2010-3639 , CVE-2010-3640 , CVE-2010-3641
        CVE-2010-3642 , CVE-2010-3643 , CVE-2010-3644 , CVE-2010-3645 , CVE-2010-3646 , CVE-2010-3647
        CVE-2010-3648 , CVE-2010-3649 , CVE-2010-3650 , CVE-2010-3652 , CVE-2010-3654 , CVE-2010-3976
   - 다운로드 센터
     - 패치 ( Upadte Center ) :: http://get.adobe.com/kr/flashplayer/
     - 패치가 적용된 제품 다운로드 :: http://kb2.adobe.com/cps/406/kb406791.html


Update5. 2010.11.04

* Adobe 취약점 Patch일정 수정 :: 

< 추가 분석 내용 >
PDF파일내의 데이터를 확인했다. 정확히 확인한 일자는 2010.11.03 이지만 확인하지 못했던 부분 ( ASEC에서 
언급되었던 구조와 내가 확인한 구조와의 상이함 ) 때문에 내용 추가가 늦었다. ASEC에서 공개한 파일의 
구조와 아직 조금 차이점이 있지만 우선 1차적으로 다음과 같은 구조로 되어 있음을 언급한다.

< 1차 확인한 PDF 구조 >

  :: 현재까지 확인된 PDF 파일의 구조는 위와 같다. 
      ShellCode와 SWF File Name , Flash File은 모두 동일하게 Java의 Inflate( )를 통해서 Decoding이 가능한 형
      태였다. 또한 ShellCode는 다음 그림과 같은 형태를 띄고 있다. 하지만 ShellCode2Exe를 통해 실행파일로
      변경해서 분석을 시도해 보았으나 Memory Violation 이 발생했다. 이는 특정 메모리 공간에서 동작할 것으로
      계산해 입력한 주소값에 대한 접근을 시도하기 때문에 발생한 것으로 보인다.

< PDF내에 삽입된 ShellCode >


< PDF 파일의 전체 동작 시나리오 (일부) >
 :: 위의 그림은 해당 PDF 파일이 동작했을 때 발생하는 전체 동작 시나리오의 일부이다. 
      즉, 취약점을 이용해 ShellCode가 동작하면 PDF 파일내의 EXE와 PDF 데이터가 VirtualAlloc( ) (?)에 의해
      메모리에 올라간 후 CreateFileA( )을 통해 파일로 생성된다. 이때 생성된 EXE파일은 위와 같은 동작을 거쳐
      최종 동작을 위한 DLL을 Drop하게 되고 아직 위치가 확인되진 않았지만 batch파일을 실행시켜 PDF와 관련된
      프로세스를 종료시킨 후 추가로 생성된 PDF 파일을 실행시켜 사용자에게 보여주게 된다. 

Update4. 2010.11.03

   -  샘플을 통한 확인 결과  Adobe Reader의 언어별 ( Kor? EN? )로 동작하는 형태가 조금 다른 것을 확인했다.
      1) EN :: 알려진 동작 모두 수행 
              ㄱ. ~.exe 파일 생성 ( Drop ) ▶ 동작
              ㄴ. ~Temp.bat 파일 생성 ( ?? ) ▶ Acrobat.exe / AdobeRd32.exe 프로세스 종료 
              ㄷ. NewRelease.pdf 파일 생성 ( Drop ) ▶ View
              ㄹ. swf 파일 ( 미확인 / ASEC에서는 두종류의 swf가 있는 것으로 보고함 )
      2) Kor :: 정상 동작이 이뤄지지 않음
              ㄱ. ~.exe 파일 생성 ( Drop ) ▶ 동작
              ㄴ. ~Temp.bat 파일 생성 ( ?? ) ▶ Acrobat.exe / AdobeRd32.exe 프로세스 종료 
              ㄷ. NewRelease.pdf 파일 생성 ( Drop ) ▶ View
              ㄹ. swf 파일 
    - 위의 분석을 바탕으로 볼 때 해당 취약점은 언어에 따라 그 동작이 상이한 것을 알 수 있음
      < 차이점 >
       ㄱ. 최초 NewRelease.pdf 파일에 의해 Drop된 ~.exe 파일이 동작하지 않았다.
       ㄴ. 최초 NewRelease.pdf 에 의해 Drop되어 사용자에게 보여줄 NewRelease.pdf 파일이 Drop되지 않았다.
       ㄷ. ~Temp.bat 파일이 동작시킬 것으로 예상되었던 프로세스 강제 종료 과정이 최초 NewRelease.pdf 에 
            의해 동작한 것으로 보인다.

< 1차 분석 내용 - PDF 바이너리 분석 >
-  동작 시나리오는 대략 다음과 같다.
  1. 메일을 통해 악성 PDF파일인 NewRelease.pdf 파일이 전달된다.

  2. Victim이 취약한 버전의 Adobe Reader로 해당 PDF 파일을 Open한다.

  3. 해당 PDF 파일은 취약점을 공격해 ~.exe / ~Temp.bat  / NewRelease.pdf 등을 생성 ( Drop )
    한다.

  4. ~.exe에 의해 악성동작을 수행하고 ~Temp.bat 파일은 실행중이던 Adobe Reader를 강제 종료한
     이후 Drop한 NewRelease.pdf 파일을 실행해 사용자에게 보여준다.

- 바이너리 파일에서 XOR Encoding 되어 있는 Drop 파일에 대한 정보를 획득했다
  Algorithm :: XOR
  Decoding Key :: 0x7B

   < Encoding 되어 있는 ~.exe >
  
 < Encoding 되어 있는 NewRelease.pdf >
 
  < En/Decoding 샘플 비교 - ~.exe >

   < En/Decoding 샘플 비교 - NewRelease.pdf >

* Metasploit을 이용해 해당 취약점을 공격하는 PDF 생성 과정이 Youtube에 공개되었다.
  - 실제 제작 테스팅 블로깅 :: http://ghostkei.tistory.com/13

Update3. 2010.11.02

ASEC Threat Research :: http://blog.ahnlab.com/asec/429

* 샘플 수집 후 분석 중
   - Test 환경 :: Windows XP SP3 (Kor) + Adobe Reader 9.3.4 ( EN )
                      Windows XP SP3 (Kor) + Adobe Reader 9.4.0 ( Kor )
 
   - 추가 분석을 수행해야 하겠지만 해당 취약점은 EN에서는 정상 동작하지만 Kor에서는 정상동작이 이뤄지지 않는
      것으로 추정됨

Update2. 2010.11.01

Drop된 파일에 대한 분석 리포트


원격지 연결 후 동일한 요청 데이터가 전송된다. ( authrootseq.txt 파일 참조 )


함께 첨부된 .stl 파일은 인증서 신뢰 목록으로 디지털 서명 ( MS )이 포함되어 있는 형태였다. 
정확한 동작은 알 수 없으나 원격지로 부터 해당 파일을 다운받고 다운받은 .stl파일을 IE등에 추가하는
형태를 띄지 않을까 추정된다. ( 악성 사이트 접근 통제 우회 목적 ?? )

숙주와 Drop된 파일에 의한 Traffic 파일 


샘플 파일에서 발생한 Violation Log 파일


Fortinet 분석 정보 :: 

Update1. 2010.10.29



US-CERT :: http://www.us-cert.gov/current/index.html#adobe_releases_security_bulletin_for10
분석 내용 :: 

< 해당 사이트 번역 >
※ 그림 및 관련 내용은 Bugix-Security의 관련 Blog내용을 참고하였음을 알립니다.
신규 버그는 최신 Adobe Reader 9.4.0.195 와 Flash Player 10.1.85.3를 포함한 이전버전에서 동작한다.
원격 공격이 가능하다.

버그는 authplay.dll에 존재한다.

이미 취약점은 널리 확산되어 있다.
(샘플 악성 파일이거나 또는 생성되는 파일로 추정 )
PDF 크기는 241,679Bytes
SWF 크기는 22,946Bytes

디컴파일된 SWF는 다음과 같다.

이건 curvedPolygon으로 다음 사이트를 참고하기 바란다.

Exploit은 JS Heap Spray를 사용한다.
Slide 0x58585858

Exploit은 이미지에서 보여주는 것처럼 메모리를 채운다.
은 메모리 마지막에 복사된 ShellCode를 위해 ROP Technic을 사용했다.

ShellCode는 동작시 %temp% 디렉토리에 ~.exe , ~temp.bat , PDF파일과 같은 이름의 PDF를 Drop한다.

Drop된 파일은 하위 URL을 참고하기 바란다. ( 암호 :: infected )


( 추가로 분석된 내용은 나중에 기재한단다.... )
Posted by GhostKei
,