티스토리 뷰

 

 

    # CVE Number :CVE-2013-3893 

    # MS Advisory :MS13-086

    # 취약점 종류 :IE Use-After-Free 코드 실행 취약점     




취약점원인(PoC) 분석

Use-After-Free 취약점은 이미 해제된 메모리를 참조하는 것으로 인하여 발생하는 취약점이다. 따라서, 취약점 분석은 원인이 되는 메모리의 생성(Create), 해제(Free), 참조(Use) 흐름을 분석한다.


본 분석에서는 Windbg 디버거와GFlag 가 사용된다.


>>  취약점 PoC코드 <<


해당 PoC 코드를 디버거를 이용하여 실행해보면, 다음과 메모리 참조 오류로 인하여 크래쉬가 발생한다.

이때, GFlag 설정을 통해 해제된 메모리의 Call Stack을 참고하면, 분석 시나리오를 설계할 때 BreakPoint(BP) 지점의 힌트를 얻을 수 있다.


>>개체 생성(Create)<<


원인이 되는 메모리번지 0033a320는 실제 참조에 앞서 다음과 같이mshtml!CTreeNode::CTreeNode() 클래스 생성자를 통해서 생성된다. 실제 Windbg에서 찍어본 로그 정보를 통해 할당된 메모리에는 mshtml!CBodyElement::`vftable' 정보가 담겨져 있다.



정상적인 경우, 이렇게 생성된 메모리는 해당 메모리에 담긴 vtable을 참조해서 Function을 호출하기 위한 다음 코드에서 참조가 이루어진다.



>>개체 해제(Free)<<

앞서 Call Stack 에서 확인된 바대로, 다음 스크립트 코드를 수행하면 앞서 생성된 개체가 존재하는 메모리 번지가 해제된다.


해당 메모리가 실제 해제되는 지 전/후의 디버그 로그를 통해 확인해보자.



>>개체 참조(Use)<<

이렇게 이미 해제되어 버린 메모리를 정상적인 경우처럼 참조하기 때문에 다음과 같이 메모리 참조 오류가 발생한다.


지금까지는 POC를 통해서 취약점 발생 부분을 분석해보았다.


이제 특별한 코드를 추가해서 사용자 입력을 통해 프로그램 흐름(EIP)을 변경할 수 있는 지 확인해보자.


>> EIP 변경 코드 <<


변경된 코드를 다시 실행해 보면, 해제된 메모리 부분에 삽입된 코드로 인하여 새로운 개체가 생성되어 재사용 되는 것을 확인할 수 있다.


삽입된 코드로 인하여 최종적으로 호출되는 CALL의 지점이 변경되는 것을 알 수 있다. 이때, 이미 해제된 메모리는 재사용되어 다음과 같이 Free 가 아닌 Busy 상태이다.


자, 이제 사용자 입력을 통해 프로그램 흐름(EIP)을 변경할 수 있다는 확인하였다.


실제 일본과 대만을 타겟으로 한 공격코드(Exploit)에서는 참조하는 메모리를 12121202 로 맞추고, 힙스프레이 코드를 통해 메모리 상에 올려진 페이로드(Payload)를 실행하도록 구성되어 있다.



공격코드(Exploit) 분석


해당 공격코드는 시스템 환경을 체크해서 Windows XP와 Windows 7에서 동작한다. 

단, Windows 7의 경우, Office 버전이 존재하지 않으면 실행하지 않는다.



 



공격코드에서는 다양한 언어, 플랫폼, 오피스 등의 조건에 맞게 ROP 가젯(gadget)과 쉘코드(shellocde)로 구성된 페이로드를 선택하여 힙 스프레이 기술을 이용하여 메모리 상에서 로드한다. (functioninit())



취약점이 발생하고 실제 페이로드(Payload)로 점프하는 코드는 다음이다.




77bc5ed5 의 코드를 실행하고 나면 다음과 같이 CALL 스택의 변경되고, 이후 순차적으로 ROP 가젯의 코드를 수행하게 된다.



최종적으로,  쉘코드는 악성코드를 특정 사이트에서 다운로드하여 실행(c:\Documents and Settings\vmuser\Local Settings\Temp\runrun.ex)한다.



   



- 끝 -


댓글
댓글쓰기 폼