취약점 정보
- CVE # : CVE-2012-0754
- 취약점 발생원인 : Flash(swf) mp4 파일 처리 엔진
- 상세 참고 사이트 : Contagio 블로그
분석 Back-Story
이번에 알려진 해당 취약점 공격은 “Iran’s Oil and Nuclear Situation” 이라는 제목으로 첨부된 워드 문서부터 시작되었다고 합니다.
물론, 영문서이고 제목을 보아하니 국내보다는 해외를 노린 것으로 보이지만, 관련 취약점을 이용하는 국내 악성 문서들을 종종 발견되고 있다고 하니 관심이 필요할 것 같습니다.
이번 악성 파일 속에서 사용된 쉘코드는 바로 파일 내부의 PE 데이터를 읽어서 실행하는 방식이 아니라, 또 한번의 쉘코드를 거치는 구조이며, 단순 XOR가 아니라 ROR를 여러차례 사용함으로써 좀 더 고도화된 방식을 사용한다.
간단하게 말하면, 이제 우리가 분석해야할 것들은 다음과 같은 것들입니다.
기존과 크게 다르지 않죠??
- [오피스파일 분석] 플래쉬 파일의 컨테이너로 사용되고 있는 워드로부터 분석할 파일을 꺼내기
- [플래쉬파일 분석] 악성 플래쉬 파일 분석을 통해 취약점과 쉘코드 분석하기
- [MP4파일 분석] 직접적인 취약점 원인이 되는 MP4 파일 분석하기
- [쉘코드 분석] 힙을 채우는 방식과 실제 수행되는 쉘코드를 분석하기
- [악성코드] 쉘코드를 통해 실제 실행되는 악성 실행파일 분석하기
물론, 완벽한 취약점 분석을 위해서는 위의 모든 것들을 명확히 밝혀내야 하지만 때로는 모든 것을 완벽하게 밝혀내지 못하더라도 실망하거나 좌절하지는 말자구요.. ^^….
저 또한 다음과 같은 부분을 밝히지 못한 상태입니다.. 찬찬히 베일을 벗기듯 분석해보아요…
MP4 구조 분석대략확인완료!!MP4에서 직접적으로 취약점을 발생시키는 원인(조건)확인완료!!- 코드 상에서 취약점 발생원인 지점(점프 지점 말고)
코드 상에서 크래쉬 및 점프 지점확인완료!!쉘코드 정체확인완료!!드랍하는 악성코드의 위치확인완료!!
취약점 분석
1) 악성 파일 추출
물론, 이게 무슨 파일이니깐 이 파일을 분석해~~ 라고 던져주면 쉽겠지만, 실제 분석을 하다보면 특정 파일 속에 삽입되어 있거나 해당 파일이 무엇인지 모르는 상태에서 분석해야할 경우도 많습니다. 특히, 플래쉬 파일은 사회공학적인 방법을 이용하기 위해서 오피스나 PDF 와 같은 다른 파일(일명, 컨테이너) 속에 삽입되어 있기 때문에 이를 추출할 수 있어야 합니다.
- 오피스 문서구조를 분석해주는 툴 이용 : 가장 대표적인 CFX(Compound File Explorer), 2007 이하의 버전만 사용 가능하다는 단점
- 수동으로 파일을 검색하여 추출하는 방법 : “FWS/CWS” 파일 시그니처를 검색한 후 헤더 안의 파일 크기만큼 떼어내는 방법.
취약점 SWF 파일 분석
대부분의 악성 SWF 파일은 파일 포맷 상의 버그 또는 Action Script 상의 버그가 존재한다.
따라서, 일차적으로 SWF 파일 구조 분석과 AS가 존재한다면 디컴파일/디스어셈하여 코드를 분석한다.
구조상의 오류는 아님을 확인하였고, 내부의 AS 파일을 추출하니 다음과 같은 구조를 갖는 코드가 존재한다.
XmlSwf.as = HeapAlloc(ShellCode) + 취약점 MP4파일(test.mp4) 재생 부분
참고로, 플래쉬 파일을 디컴파일하거나 디스어셈블 하기 위해 사용할 수 있는 다수의 툴이 존재한다.
최근에는 Adobe 사에서 직접 제공하는 “SWF Investigator” 라는 툴도 존재하며 이 툴은 AS 디스어셈 기능을 제공하고 있다.
일반적으로 악성 파일들의 구성은 크게 보면, “쉘코드/악성실행파일”과 “취약점 발생부분” 이다.
따라서, 정체가 불분명한 악성 파일을 분석할 경우는 두 부분을 따로 떼어서 분석하는 것도 방법이 될 수 있다.
우선 취약점이 발생되는 다음 코드만을 떼어서 간단한 PoC 형태의 플래쉬파일을 가지고 취약점 원인을 디버깅해본다.
동적 테스트 결과, 취약점은 다음의 경우에 발생하는 것으로 추정된다.
실제 크래쉬를 발생하는 MP4 파일 구조는 다음과 같다.
Tag Box - "cprt"
-----------------------------------------------------------------------------
Header BoXHeader (Box Size, Box Type) :
Version UI8 : Must be "0"
Flags UI24 : Reserved, set to 0
LanguageCode UI16 : ISO-639-2/T two-letter codes
TagString UI8[n] n : Maximum 65535
따라서, 현재까지 취약점 발생 조건은 “cprt” 태그 + Box size + “0D 이하” 이다. 하지만, Size가 0D 이고 8바이트 TagString 이 최소 존재할때 올바르게 힙지점(0C0C0CXX) 지점으로 점프한다. (단, Windows XP SP3 환경에서 )
코드 상의 분석은 아직 진행중이다.
다음으로 다음과 같은 AS 코드를 통해 쉘코드를 힙 상에 배치한다.
특히, 쉘코드를 한번 더 자체 암호화(Encrypt2) 함수를 사용해서 꼬는 방식을 취하고 있다.
손 쉽게 간단한 파이썬 코딩으로 바로 쉘코드를 뽑아낼 수 있었으나 이번에는 암호화된 코드를 한번 더 처리해야하기 때문에, 귀찮은 관계상 직접 쉘코드를 메모리 상에 올린 상태에서 디버깅하는 방법을 선택하였다.
그렇게 하기 위해서는 AS 코드부분만 따로 떼어 컴파일 하거나 악성 플래쉬 파일을 직접 실행하는 방법을 선택할 수 있다. 물론, 이번 파일의 경우는 쉘코드를 올린 후에 취약점 발생 원인을 외부로부터 얻기 때문에 네트워크이 차단된 상태에서는 쉘코드만 올려지고 취약점은 발생하지 않는다.
참으로 해피한 상태이지요.. ^^;;;
실제 메모리 상에 올려진 쉘코드는 다음과 같다.
자체 XOR 디코딩하고 나면 아래와 같이 실제 눈에 익은 코드를 발견할 수 있다.
해당 쉘코드는 파일로부터 1A06Ch(=106604) 파일 크기 즉 컨테이너 파일인 워드문서의 크기(106604 바이트)를 확인하고, 파일 포인터를 DE00 옵셋만큼 이동하여 파일 데이터를 가상 메모리를 할당하여 복사해온다.
복사한 파일 데이터를 ROR(Rotate Right)하고 XOR 하면 다시 쉘코드가 나오고 이 부분으로 점프하여 코드를 실행한다.
해당 코드는 다시 XOR 디코딩 후에 다음과 같은 온전한 어셈코드를 얻을 수 있다.
해당 코드는 ROR과 XOR 를 통해서 다음과 같이 메모밀 상의 PE(MZ) 파일을 디코딩한 후 %temp% 폴더 밑에 “us.exe”라는 파일을 생성한 후 WinExec 로 실행한다.
