티스토리 뷰



"Adobe PDF 제로데이 취약점(CVE-2010-2883)이 발표된 지 채 일주일도 지나지 않아 

또 다른 제로데이 취약점 발견..." ...

"안드로이드 상에서도 영향을 줄 수 있다..."

 

한 동안 트위터가 떠들썩 했었다. 


이미 추석연휴를 지나는 지난 9월 20일에 패치가 배포되었지만, 

아직은 해당 취약점에 대한 명확한 분석정보를 찾을 만한 곳이 없다..  

본 쥔장도 연휴 내내 딩가딩가~ 놀다가 이제서야 정리해서 오픈해본다.. ^^;;;;

 

늘 그렇지만 플래쉬 파일의 분석은 좀 까다롭고 난해하다..... 

파고.. 파고.. 또 파면 희미하게 답이 보이는 것...

그 희미한 불빛을 보았을 때의 쾌감이 아마두 분석의 묘미가 아닌가 싶다....


이번 취약점을 이용하는 실제 악성 플래쉬 파일(SWF)는 전체적으로 다음과 같이 도식화해 볼 수 있겠다.

 

악성 Flash 파 일
(SWF)

Heap_spray(쉘코드)

SWF(XOR)

SWF(취약점발생)

 


위의 구조는  플래쉬 파일이 실행 시 추가적으로 SWF 파일 2개을 생성하여 동적으로 실행한다.

이 중 하나의 SWF 파일 안에는 취약점을 발생시키는 직접적인 코드가 포함되어 있고

실제 악의적인 행위을 수행하는 쉘코드는 악성 플래쉬 파일의 본체에 포함되어 있는 ActionScript 코드를 통해 기존의 Heap_Spray 방식으로 메모리에 채워지게 된다. 


해당 파일을 swfdump와 같은 툴로 내부를 확인해보면 DoABC 태그가 존재하고,

이 DoABC 구조체 안에 포함되어 있는 Bytecode들을 ActionScript로 변환해서 확인해보면

그 안에 바로 우리가 찾고 싶은 모든 것들이 들어있다. ^^

 

쉘코드 (heap_spray) 코드 부분

 

앞서 언급한 대로 쉘코드는 다음과 같이 Actionscript(bytecode)를 통해 기존의 Heap_srapy 기법과 마찬가지로...... 실제 Heap 영역의 공간을 채운다.



 


채워진 쉘코드 또한 기존의 쉘코드와 마찬가지로 XOR 인코딩으로 코드를 난독화했고,

이를 풀어 확인하면 특정 URL로부터 파일을 다운받아 실행하도록 제작되어 있다.

그러나, 해당 쉘코드에는 사용하는 API들에 후킹코드가 존재하는 지를 체크하는 코드가 포함되어 있다. 

스마트한 시대에 스마트한 쉘코드~~~ ^^;;; 

물론, 이처럼 후킹을 고려한 쉘코드는 나타난지 좀 됐다는......

 

- 0x0E2h XOR(byte) 로 디코딩하기

- 악성 다운로드 URL :  hxxp://[생략].184.70/mm913.exe

    hxxp://[생략]91.com/web.exe(코드는 동일하되 다운로드 URL만 변경)

 

 

 

이제 남겨진  2개의 SWF 파일....

 

내부의 Action Script 코드에는 다음과 같이 "외부의 SWF 파일이나 이미지 파일을 동적으로 로딩할 수 있는" 코드를 이용하여 추가적으로 SWF 파일을 하위로 로딩하고 있다. 

 

 * child_01.swf , child_02.swf 명칭은 쥔장이 임의로 명명한 것임..


- Action Script -

250   nop                     

     251   pushstring              "435753090…. (중간생략)….."  …. ß- Child_01.swf 파일

     253   setlocal                  8

    

325   nop                     

     326   pushstring              "4357530A2….(중간생략)…."  … <- Child_02.swf 파일

     328   setlocal                  12

330   findpropstrict          flash.display::Loader

      332   constructprop         flash.display::Loader (0)

      335   setlocal                 13

      337   findpropstrict         flash.system::LoaderContext

      339   pushfalse             

      340   constructprop         flash.system::LoaderContext (1)

 


첫번째 swf 파일 Child_01.swf은 다음과 같이 XOR 루틴을 갖는데 아직 역할을 찾지는 못했다.. ==;;  

 

function funcXOR1():*          /* disp_id 1*/

    {

      // local_count=2 max_scope=0 max_stack=2 code_len=1081

      0     pushint               1016107152            // 0x3c909090

      2     pushint               1016107152            // 0x3c909090

      4     bitxor                

             

          …중간생략….

 

두번째 swf 파일 Child_02.swf 에서 드디어 실제 취약점의 원인으로 추정되는 부분을 발견한다.

해당 파일은 정상적인 동작 시 다음과 같이 폭포수를 표현하도록 제작된 플래쉬 파일이지만

아마도 내부에 잘못된 "NextName"  코드의 사용으로 취약점을 발생시키는 것으로 추정한다.

 


 

실제 해당 플래쉬 파일에는 "NextName"이 다수개 사용되었지만 다른 부분과 달리 마지막 코드 사용에서만 오브젝트(array)와 index(int) 값이 잘못 사용된 것으로 보인다.

 

해당 SWF 파일을 실행하게 되면 Flash10i.ocx 의 다음 CALL에서 쉘코드가 존재하는 heap 주소로 EIP가 점프하게 된다.


 

 

해당 취약점은 플래쉬 파일 뿐만 아니라, 취약한 swf 파일을 브라우저를 통해서 로딩하는 방식을 통해 기존의 Heap_srpay 코드와 결합하여 웹 취약점 공격으로도 이용될 수 있다.

이러한 방식은 분석할 때에도 활용하면 도움이 된다는... ^^

 

 

 
 
 
-----------------------------------------------
요즈음 조금 헷갈린다..
취약점 분석을 왜 하는 걸까???
어디까지가 분석의 끝인가???
해서 무에다 쓸꼬~~???
분석하면 할 수록 레벨업이 되고 있긴 한 건가....
나는 지금
계단과 계단 사이 평평한 면에  
서  ... 있나보다...
 
^^*
 여러분은 행복하세요~
-----------------------------------------------
 
 
댓글
댓글쓰기 폼