• No results found

Adobe Flash Player AVM Verification Logic Array Indexing (CVE 2011 2110) [NSHC RedAlert Team] pdf

N/A
N/A
Protected

Academic year: 2020

Share "Adobe Flash Player AVM Verification Logic Array Indexing (CVE 2011 2110) [NSHC RedAlert Team] pdf"

Copied!
24
0
0

Loading.... (view fulltext now)

Full text

(1)

취약점 분석 보고서

Adobe Flash Player AVM Verification

Logic Array Indexing (CVE-2011-2110)

2012-06-27

(2)

목 차

1.

개 요 ... 4

1.1. 취약점 분석 추진 배경 ... 4

1.2. CVE-2011-2110 취약점 요약 ... 4

2.

CVE-2011-2110 분석 ... 5

2.1. CVE-2011-2110 취약점 개요 ... 5

2.2. CVE-2011-2110 대상 시스템 목록 ... 5

2.3. CVE-2011-2110 취약점 원리 ... 6

3.

분 석 ... 7

3.1. 공격 기법 및 기본 개념 ... 7

3.2. 공격 코드 분석 ... 10

3.3. 공격 코드 실행 ... 13

3.4. 공격 기법 분석 ... 16

4.

결 론 ... 22

5.

대응 방안 ... 23

6.

참고 자료 ... 24

6.1. 참고 문헌 ... 24

(3)

그림 목차

그림 1. 취약한 플래시 플레이어 버전 ... 5

그림 2. CVE-2011-2110 공격 개요도 ... 6

그림 3. AVM2 동작 구조 (출처 : Adobe Corporation) ... 7

그림 4. JIT 검증 프로세스 ... 8

그림 5. 함수 실행 시 동작 매커니즘 ... 8

그림 6. 검증 실패로 이어지도록 정수 삽입 ... 9

그림 7. 검증 흐름 우회 코드 ... 9

그림 8. 공격 코드 구조 ... 10

그림 9. swf 생성 부분 ... 10

그림 10. 사용자 브라우저에 따른 옵션 설정 ... 10

그림 11. 핵심 공격 코드_1 ... 11

그림 12. 핵심 공격 코드_2 ... 11

그림 13. 취약 파일과 쉘코드를 전송하는 부분 ... 12

그림 14. 공격 서버에 적용할 웹페이지 코드 ... 12

그림 15. 취약한 버전이 설치된 피해자 시스템 ... 13

그림 16. 취약점 모듈 옵션 확인 ... 13

그림 17. 모듈 옵션 설정 및 공격 서버 가동 ... 13

그림 18. 공격 당한 피해자 화면 ... 14

그림 19. Metasploit 공격 화면... 14

그림 20. 피해자 시스템 쉘 획득 ... 15

그림 21. HTTP Object list 를 이용해 전송된 파일 확인 ... 16

그림 22. 'ok.html' 파일 내용 ... 16

그림 23. SWF 디컴파일러 도구로 파일 내용 확인 ... 17

그림 24. SWF 디컴파일러 도구로 파일 내용 확인 ... 17

그림 25. SWF 디컴파일러 도구로 파일 내용 확인 ... 18

그림 26. SWF 디컴파일러 도구로 파일 내용 확인 ... 18

그림 27. exploit 함수 호출 부분 ... 18

그림 28. Flash player 버전에 따른 ROP 조정 ... 19

그림 29. ROP 를 위한 offset 조정 ... 19

그림 30. ROP 적용 후 쉘코드를 삽입하는 부분 ... 20

그림 31. XOR 수행 전 공격 서버에서 전송된 txt 파일 ... 20

그림 32. txt 파일을 XOR Decoding 한 결과 ... 21

(4)

1.

개 요

1.1.

취약점 분석 추진 배경

최근 보안 동향을 볼 때, Flash Player 취약점은 게임 계정 해킹, 개인정보 탈취 등 여러 가지 악의적인 목적으로 악용되고 있다. 특히 단순히 하나의 취약점만을 이용하지 않고, 다른 취약점들과 함께 혼합한 형태로 배포되는 경향이 다수 존재한다.

특히 해당 취약점은 일반적인 워드문서(.docx) 파일 내부에 숨겨져 SNS 나 이메일로 전파 되는 경우가 많다. 또한, 불특정 다수를 대상으로 하는 공격보다 특정 목적을 가지고 정보를 탈취하는 APT 공격에 많이 사용되는데, 그 형태가 끊임없이 변형되고 있는 추세이다.

이번 문서에서는 가장 최근에 밝혀진 Flash Player AVM Verification Logic Array Indexing(CVE-2011-2110)' 취약점 분석을 통해 향후 발생 가능한 관련 취약점에 능동적으로 대처할 수 있는 능력을 갖추는 것이 목적이다(앞으로 취약점 이름은 CVE-2011-2110 으로 통칭한다).

1.2.

CVE-2011-2110 취약점 요약

(5)

2.

CVE-2011-2110 분석

2.1.

CVE-2011-2110 취약점 개요

취약점 이름 Adobe Flash Player AVM Verification Logic Array Indexing

최초 발표일 2011 년 6 월 14 일 문서 작성일 2012 년 6 월 27 일

위험 등급 긴급(위험) 현재 상태 패치됨

취약점 영향 원격 코드 실행 및 서비스 거부 발생

표 1. CVE-2011-2110 취약점 개요

2.2.

CVE-2011-2110 대상 시스템 목록

해당 취약점은 Windows, MAC, Solaris 운영체제 상의 Adobe Flash Player 10.3.181.26 이전 버전, 그리고 안드로이드 상에서 10.3.185.23 버전 이전에서 취약점이 발생한다. 해당 취약점이 발생하게 되면 원격 코드 실행을 허용하거나 서비스 거부 공격이 발생될 수 있다.

• Flash Player 10.3.181.23 and earlier 10.3.181.26

• Flash Player 10.3.181.23 and earlier - network distribution 10.3.181.26 • Flash Player 10.3.185.23 and earlier for Android 10.3.185.24

• Flash Player integrated with Google Chrome

(6)

2.3.

CVE-2011-2110 취약점 원리

CVE-2011-2100 은 Adobe 사의 플래시 플레이어 버전 10.3.181.23 또는 그 이전 버전에서 발생하는 취약점을 말한다. 해당 취약점은 ActionScript3 AVM2 검증 로직 안에서 발생하는 취약점을 이용한다. 특히, 이것은 임의의 값을 사용해 배열을 인덱싱 할 때 발생하는데, 이 때 메모리가 참조된 뒤 실행되는 원리이다. 또한, 다른 플래시 취약점이 힙 스프레이 기법을 사용하는 반면, CVE-2011-2110 은 swf 의 ActionScript 를 이용해 메모리를 감염시킨다. 전체적인 공격 개요도는 다음과 같다.

그림 2. CVE-2011-2110 공격 개요도

첫째, 피해자가 공격자 서버에 접속하면 swf 파일을 실행하는 코드가 담긴 웹페이지가 피해자에게 전송된다.

둘째, 취약한 swf 파일이 피해자 서버의 취약한 플래시 플레이어에서 실행된다.

(7)

3.

분 석

3.1.

공격 기법 및 기본 개념

1. JIT(Just In Time)

JIT 는 바이트 코드를 가져와 해당 시스템에 적합한 기계어로 컴파일 해주고, 재사용 가능 하도록 만드는 것을 의미한다. 만일 바이트 코드가 재사용되어야 한다면, 컴파일 된 코드가 메모리에서 추출되어 CPU 로 전달되어, 플레이어가 해당 명령을 컴파일 하는 것을 생략하게 해준다. 이는 어플리케이션 실행 속도를 높여 효율성을 향상시키는 효과를 가지고 있다.

2. AVM(ActionScript Virtual Machine) Verification Logic

AVM 은 ActionScript Virtual Machine 의 약자로, 한마디로 플래시 파일에 포함되는 Action 스크립트 소스를 처리하는 가상 머신을 의미한다. CVE-2011-2110 은 AVM2 상에서 취약점이 발생한다. 플래시 파일이 처리되고 실행되는 구조는 다음과 같다.

그림 3. AVM2 동작 구조 (출처 : Adobe Corporation)

(8)

그림 4. JIT 검증 프로세스

특정 바이트코드가 검증 프로세스로 넘어오면 코드에 대한 검증이 이루어진다. 만일 검증을 통과하지 못하면 프로세스를 종료시키고, 검증이 통과되면 생성 프로세스로 바이트코드를 넘긴다. 마지막으로 실행 프로세스로 넘어가 코드가 실행되는 원리이다. 여기서 주의해야 할 점이 하나 있다. '검증 흐름'은 단지 검증을 위한 계산 절차를 의미하며, 실제 프로그램 흐름에 해당되는 것은 '실행 흐름' 밖에 없다.

3. ActionScript 취약점 발생 원리

ActionScript 취약점은 검증/생성 프로세스 도중에 발생한다. 프로그램에는 수많은 제어 흐름이 존재한다. 단적인 예로, 'JMP' 명령을 수행하게 되면 프로그램 흐름이 여러 갈래로 나뉘게 된다. 만일 수십 개의 점프 코드가 프로그램 내부에 존재하게 되면 그 경우의 수로 인해 공격자가 프로그램의 흐름을 제어할 수 있는 여지를 제공하게 된다. 간단한 예제를 통해 어떻게 취약점이 발생하는지 살펴보도록 하자.

스크립트 함수 중 trace()를 사용한다고 가정한다(함수의 기능보다 인자 값이 전달되고 함수가 실행되는 매커니즘에 초점을 맞춘다). 'trace("aaaaaaaa");' 와 같이 함수를 실행하면 다음과 같이 인식을 하게 된다.

그림 5. 함수 실행 시 동작 매커니즘

(9)

그림 6. 검증 실패로 이어지도록 정수 삽입

함수 객체가 삽입되어야 할 부분에 특정 정수를 삽입하게 되면 함수 호출 부분에서 함수 객체를 정상적으로 찾지 못하고, 검증 흐름이 실패로 이어지게 된다. 다음 그림을 보자.

그림 7. 검증 흐름 우회 코드

그림 7 에서 볼 수 있듯이, 정상적인 코드와 공격자가 원하는 코드를 동시에 삽입해 검증 흐름을 우회할 수 있다. 우선 코드가 검증 JIT 에 들어오게 되면 L1 으로 흐름이 이동하게 된다. 코드를 하나씩 점검하다가 L3 에 있는 점프를 만나게 되면 L6 로 흐름이 이동되고, 정상적으로 trace() 객체가 호출된다. L4~5 는 현재 어느 코드와도 연결되어 있지 않기 때문에, JIT 는 검증된 L3 와 L6 사이에 있는 코드를 단순한 데이터 삽입이라 간주하고 검증을 통과시키게 된다.

(10)

3.2.

공격 코드 분석

공격코드는 다음과 같이 크게 네 가지 부분으로 나눌 수 있다. 각각 항목이 어떠한 내용을 담고 있는지 자세히 분석해 보자. ( 모듈 옵션 조정은 취약점과 무관하므로 생략 )

그림 8. 공격 코드 구조

1. 취약한 swf 파일 생성 부분

그림 9. swf 생성 부분

취약점 관련 모듈이 검증되고 정식으로 모듈이 등록되면 취약점 관련 파일을 프레임워크 공간에 별도로 저장한다. 그림 4 에서 보는 것처럼 미리 저장해 놓은 취약한 swf 파일을 불러와 모듈의 공격 코드에 새롭게 써주는 것으로 취약점을 유발하는 코드 구성은 끝나게 된다.

2. 공격 대상 구분

그림 10. 사용자 브라우저에 따른 옵션 설정

(11)

그림 5 에서 보듯이, 취약점을 유발시킬 수 있는 브라우저는 Microsoft 사의 Internet Explorer 와 Mozilla 사의 FireFox 브라우저 상에서만 작동한다. 만일 사용자가 Crome 이나 Safari 같이 지원하지 않는 브라우저를 사용한다면 취약점이 작동하지 않을 것이다.

3. URI 설정 및 구성

이 부분은 공격 코드 중에서도 가장 중요한 부분으로, 실질적으로 취약점을 유발하는 코드와 매커니즘을 가지고 있는 부분이다.

그림 11. 핵심 공격 코드_1

첫째, 코드 구성을 위해 XOR 연산할 키 값과 앞서 생성했던 swf(실질적인 취약점 유발 코드를 가지고 있음)를 준비한다. 그리고 zlib 안에 포함된 'Deflate' 함수를 이용해 Metasploit 에 내장된 페이로드를 압축하게 된다. 마지막으로 페이로드를 키 값인 122 와 XOR 연산을 시켜 shellcode 에 저장한다.

그림 12. 핵심 공격 코드_2

(12)

그림 13. 취약 파일과 쉘코드를 전송하는 부분

셋째, 이전 단계에서 구성한 페이로드와 취약한 파일(swf)를 공격자 서버에 접속한 피해자 시스템에 전송하는 부분이다. 피해자 시스템 요청값에 들어가 있는 문자열(swf 또는 txt)에 따라 해당 부분을 실행시켜 준다.

그림 14. 공격 서버에 적용할 웹페이지 코드

(13)

3.3.

공격 코드 실행

1. 테스트 환경 설정 ( Microsoft WIndows XP SP2 / Flash Player 10.3.181.23 )

그림 15. 취약한 버전이 설치된 피해자 시스템

2. Metasploit 모듈 로딩해 옵션 확인

그림 16. 취약점 모듈 옵션 확인

모듈 옵션은 그림 1 에서 보는 것과 같다. 공격자가 조정해야 할 부분은 SRVHOST 와 SRVPORT 부분으로 서버 방식으로 리스닝을 하고 있는 상태에서 공격자가 접속하면 취약점을 발생시키게 된다. 그림 1 에서는 공격 대상이 'Automatic'으로 설정되어 있지만, 수동으로 대상 시스템에 맞추어 줄 수도 있다.

(14)

그림 2 와 같이 옵션을 설정 후 'exploit' 명령을 수행하면 모듈이 실행되고, 'http://옵션에서 지정한 주소:8080/ok'로 서버가 가동된다.

4. 피해자 컴퓨터에서 공격자 서버로 접속

그림 18. 공격 당한 피해자 화면

그림 3 에서 보듯이 피해자 측 브라우저에는 공격에 대한 어떤 징후도 찾을 수 없다. 만일 피싱 사이트나 일반적인 문서 파일과 결합된다면 공격이 발각될 가능성이 더욱 감소하게 된다.

5. Metasploit 공격 내역

그림 19. Metasploit 공격 화면

(15)

6. 취약점 유발 성공 후 쉘획득

그림 20. 피해자 시스템 쉘 획득

(16)

3.4.

공격 기법 분석

7.1.1

동적 분석을 통해 분석대상 파일 추출

1. 와이어샤크로 취약점 관련 파일 추출

브라우저를 통해 실행되는 취약점이므로, 공격 과정을 와이어샤크로 캡쳐한다. 그 후 와이어샤크의 'HTTP Object list'를 수행한 결과 다음과 같은 파일을 공격자와 피해자가 주고받는 것을 확인할 수 있다. 각각의 파일이 취약점과 어떠한 관련이 있는지 살펴보자.

그림 21. HTTP Object list 를 이용해 전송된 파일 확인

공격자 서버에서 ok.html, BdOUZu.swf, tBM.txt 순서로 피해자 시스템에 파일이 전송된다. 각각의 파일이 어떤 역할을 하는지 분석한다.

7.1.2

추출 파일 분석

1. 'ok.html' 파일 분석

그림 22. 'ok.html' 파일 내용

그림 8 에서 보는 것처럼 해당 파일은 복잡한 매커니즘을 가지고 있지 않다. 가장 중요한 부분은 BdOUZu.swf 파일을 'info'라는 인자와 함께 실행시키는 부분이다. 앞서 생성한 'swf' 파일이 취약점을 유발하게 되므로 자세한 분석을 통해 어떠한 방식으로 취약점이 발생하는지 자세하게 살펴본다.

2. 'BdOUZu.swf' 파일 분석

(17)

그림 23. SWF 디컴파일러 도구로 파일 내용 확인

파일이 동작하는 부분을 보면 우리가 분석해야 할 부분이 Main 함수 밖에 없다는 것을 확인할 수 있다. 메인 함수 안에서 제공하는 내부 함수는 다음과 같다.

- Main - hexToBin - exploit

각각의 기능들이 어떻게 작동하는지, 취약점과 어떤 관련이 있는지 살펴보도록 한다.

(18)

- swf 의 인자로 설정했던 info 파라미터 값을 받아와 hexToBin 함수를 수행한다. - hexToBin 함수에서 헥스값을 바이너리로 변환해 준다.

- 각각 항목을 키 값인 122 와 XOR 연산해 준다.

- ExternalInterface 클래스를 통해 특정 값이 호출되는데, 자바 스크립트의 'eval' 함수를 호출해 상대방 시스템을 얻어낸다(navigator.userAgent 이용)

- 받아온 정보로 상대 시스템에 대한 조건식을 수행한다. 브라우저 종류와 64 비트 프로세스를 체크해 에러메시지를 출력해 준다.

그림 25. SWF 디컴파일러 도구로 파일 내용 확인

'info' 값을 XOR 연산한 결과를 URL 요청값으로 설정해 공격자 서버에 특정 요청을 수행한다. 이를 통해 피해자 시스템은 'tBM.txt'를 전송 받게 된다. 또한 EventListener 에 의해 요청된 txt 파일이 아래와 같은 매커니즘에 의해 XOR 연산 처리된다.

그림 26. SWF 디컴파일러 도구로 파일 내용 확인

(19)

2) exploit

취약 플래시 플레이어 상에서 swf 을 실행시켜 취약점을 유발시키기 위해 공격코드 내부에는 버전별로 상이한 ROP 코드가 담겨 있다.

그림 28. Flash player 버전에 따른 ROP 조정

피해자 시스템의 플래시 버전이 10.3.181.23 이므로 위 그림처럼 ROP 가 작동하게 된다. ROP 는 크게 두 가지 부분으로 나눌 수 있다.

첫째, 버전별로 상이한 ROP 부분이다. 여기에 사용되는 가젯(Gadget)들은 모든 버전이 같지만 베이스 레지스터 계산을 프로그램 버전에 맡게 조정해 준다.

둘째, 계산된 베이스 레지스터를 기준으로 위에서 사용한 가젯을 이용해 ROP 공격을 수행한다. 인자를 위한 오프셋 조정은 EAX 레지스터를 이용한다.

그림 29. ROP 를 위한 offset 조정

(20)

그림 30. ROP 적용 후 쉘코드를 삽입하는 부분

3. 'tBM' 파일 분석

tBM.txt 를 헥사 에디터로 열어보면 다음과 같이 알 수 없는 값들이 입력되어 있다.

(21)

swf 파일의 동작 중 이 파일을 XOR 연산시킨 뒤 실행하므로, 디코딩 도구를 이용해 122 와 XOR 연산을 수행하면 다음과 같은 파일이 생성된다.

그림 32. txt 파일을 XOR Decoding 한 결과

(22)

4.

결 론

CVE-2011-2110 은 논리적 결함이 있는 플래시 플레이어를 이용해 공격자가 원하는 코드를 실행시키거나, 악성코드를 다운받는 등 악의적 공격 수행을 가능하게 하는 취약점이다. 특히 사용자가 모르는 사이에 사용자 컴퓨터를 점령할 수 있다는 점에서 잠재적 위험성을 가지고 있다.

플래시 플레이어 취약점은 최근 들어 다른 취약점들과 함께 많이 악용되고 있다. 다수의 사용자들은 멀티미디어 프로그램에 대한 보안 위협을 인지하지 못하고 업데이트를 소홀이 한다. 하지만 웬만한 브라우저에는 플래시 플레이어가 다 지원이 되고 설치가 되어있는 만큼 공격 대상에 대한 선택의 폭이 넓다고 할 수 있다. 특히 최근에는 게임 계정 및 정보 탈취에 많이 악용되는 추세이다.

(23)

5.

대응 방안

사용자들은 주기적으로 해당 프로그램 업데이트를 수행해야 하며, 새로운 보안 패치가 발표되면 지체하지 말고 패치를 적용해야 한다. Adobe 공식 사이트를 방문하면 새로운 보안 패치에 대한 정보나, 이에 관련한 패치 파일을 다운로드 할 수 있다.

(24)

6.

참고 자료

6.1.

참고 문헌

- ActionScript 3.0 and AVM2 Performance Tuning by Adobe - Analyzing an Adobe Flash MALWARE by +NCR/CRC!

- Understanding and Exploitating Flash ActionSCript Vulnerabilities by Haifei Li

6.2.

참고 웹 문서

- http://cleverdj.tistory.com/46

- http://community.websense.com/blogs/securitylabs/archive/2011/06/17/cve-2011-2110-for-adobe-flash-player-being-exploited-in-the-wild.aspx

http://cleverdj.tistory.com/46 http://community.websense.com/blogs/securitylabs/archive/2011/06/17/cve-2011-2110-for-adobe-flash-player-being-exploited-in-the-wild.aspx http://blog.ahnlab.com/asec/554 http://sinun.tistory.com/141

References

Related documents