< FB8F0B9D9C0CF5FBFEEBFB5C3BCC1A65FB1E2B9DDC0C75FBEC7BCBAC4DAB5E55FB4EBC0C0B1E2B9FD5FBFACB1B85FC3D6C1BEBAB8B0EDBCAD2E687770>

Transcription

1 최종연구보고서 KISA-WP 모바일 운영체제 기반의 악성코드 대응기법 연구 수탁기관 : 충남대학교 산학협력단

2

3 제 출 문 한국인터넷진흥원 원장 귀하 본 보고서를 모바일 운영체제 기반의 악성코드 대응기법 연구 의 최종연구개발 결과보고서로 제출합니다. 2010년 11월 22일 수탁 기관 : 충남대학교 산학협력단 연구책임자 : 교 수 류 재 철 (충남대학교 컴퓨터공학과) 참여연구원 : 연 구 원 김 동 우 (충남대학교 컴퓨터공학과) 연 구 원 민 승 욱 (충남대학교 컴퓨터공학과) 연 구 원 이 희 경 (충남대학교 컴퓨터공학과) 연 구 원 유 성 민 (충남대학교 컴퓨터공학과) 연 구 원 정 우 탁 (충남대학교 컴퓨터공학과) 연 구 원 오 진 석 (충남대학교 컴퓨터공학과) - III -

4 - IV -

5 요 약 문 1. 제목 모바일 운영체제 기반의 악성코드 대응기법 연구 2. 연구개발의 목적 및 중요성 스마트폰은 지난 2004년 미국 내 사무직 종사자를 중심으로 열풍이 시작되어 미국 전역으로 확대 된 것에 이어 국내에도 2009년 4월부터 방 송통신위원회의 WIPI 탑재 의무화 제도 폐지가 확정되면서 표준화된 개 발 환경을 제공하는 범용 OS 기반의 스마트폰 시장이 확산될 것이라는 의견들이 지배적인 상황이다. 빠른 성장세를 보이는 국내 스마트폰 시장에 대해 모바일 브로드밴 드 시장 활성화에 크게 기여할 것이라는 환영의 목소리와 함께 임베디드 OS가 탑재되어 PC 수준의 기능을 제공하는 스마트폰의 경우 PC와 유사 한 보안 취약점이 발생할 수 있다고 보안 전문가들은 우려하고 있다. 이 는 스마트폰이 단순한 핸드폰이 아닌 다양한 네트워크 인터페이스를 가 진 컴퓨터로 현재 인터넷 환경에서 발생할 수 있는 모든 보안 위협이 스 마트폰 환경에서 동일하게 적용되기 때문이다. 또한 개인 중요 정보가 저 장되고 오픈 개발 환경의 제공으로 자유로운 프로그램 개발 및 설치가 가능하다는 점 또한 악성코드 증가의 요인으로 작용한다. 실제 2004년 카비르(Cabir)라는 웜(Worm)이 최초 발견된 이후 지금까 - V -

6 지 약 600여종의 악성코드가 스마트폰에서 발견되었다. 이들 대부분은 스 마트폰에 탑재되는 임베디드 OS의 취약점을 이용하여 동작하는 것으로, 이러한 모바일 악성코드는 정상 동작 방해, 원격 제어, 개인정보 유출, 과 금 유도, 유해 사이트 접속과 같은 공격을 수행하는 것이 대부분이었다. 특히 스마트폰의 경우 개인이 소유하며 많은 개인 정보를 담고 있다는 점에서 개인정보 유출과 같은 문제가 발생할 경우 그 피해는 매우 크고, DDoS 공격에 악용될 가능성도 존재한다. 꾸준한 증가세를 보이던 국내 스마트폰 시장은 2009년 12월 아이폰 의 도입 및 최근 갤럭시 S의 돌풍으로 인하여 사용자가 급증하는 추세를 보이고 있다. 특히 WIPI 탑재 의무화 제도가 폐지된 현재, 외국 업체뿐만 아니라 국내 업체들도 다양한 모바일 운영체제를 탑재한 제품을 출시할 예정에 있어 앞으로 스마트폰 시장은 더욱 더 커질 것이라 전망된다. 사 용자가 증가함에 따라 악성코드의 발견이 증가했던 외국의 경우처럼 국 내의 경우도 악성코드가 증가할 것이고, 국외에서 발생했던 스마트폰 보 안 문제가 국내에도 그대로 적용될 가능성이 높다. 이에 따라 본 연구에 서는 모바일 운영체제 기반의 악성코드에 대한 대응 방법에 대한 연구를 수행하여 이를 대비하고자 한다. 3. 연구개발의 내용 및 범위 대표적인 안티 바이러스 제품들의 경우 악성코드의 시그니처 수집을 통해 시그니쳐 값을 비교하여 악성코드를 탐지하는 시그니처 기반의 탐 지방법을 사용 중이다. 이러한 시그니처 기반의 탐지방법은 알려지지 않 은 새로운 악성코드나 기존의 악성코드에 약간의 수정을 가한 변종 악성 코드의 경우도 탐지가 불가능하다는 문제점이 존재한다. 반면, 특정 API 사용에 대한 모니터링을 통해 악성행위 여부를 판단하는 행위 기반 탐지 의 경우 새로운 악성코드에 대응하여 즉각적인 탐지가 가능하고 변종 악 성코드에 대해서도 탐지가 가능하여 그간 지적되어 왔던 시그니처 기반 악성코드 탐지의 문제점 해결이 가능하다. - VI -

7 이러한 행위기반의 악성코드 탐지 방법을 추가하면 특정 API의 탐지를 통해 시그니처 DB에 등록되지 않은 새로운 악성코드의 발견이 가능해지 고, 기존의 악성코드에 약간의 수정을 가한 변종 악성코드의 경우도 탐지 가 가능하다는 장점을 가진다. 따라서 본 연구에서는 기존 시그니처 기반의 악성코드 탐지 방법의 보완을 위해 시그니처 기반의 악성코드 탐지에 추가로 행위기반 악성코 드 탐지를 추가하는 방법의 결합을 통해 악성코드에 대한 대응기법을 연 구하고자 한다. 4. 연구결과 가. 모바일 OS 구조 및 보안 메커니즘 조사 분석 대표적인 임베디드 OS인 스마트폰 OS의 구조 및 각각의 OS가 가지 는 보안 메커니즘을 조사 및 분석을 수행하였다. 이러한 OS 구조 및 보 안 메커니즘에 대한 체계적인 조사 및 분석을 통하여 OS의 안정성에 대 한 평가 및 잠재적인 보안 위험 요소의 발견을 위한 자료로 쓰일 수 있 었다. 또한 OS 구조 및 보안 메커니즘에 대한 상세한 정리를 통해 차후 에 공개된 취약점을 조사 및 분석할 때에, 취약점의 원리를 소개하는 자 료로 활용이 가능하게 되었다. 나. 공개된 보안 취약점 조사 및 분석 모바일 OS 환경에서는 이미 다양한 악성코드가 발견되었고, 최근에 는 OS 자체의 취약점을 이용하는 악성코드 또한 발견되고 있다. 또한 악 성코드의 경우, 기존에 발견 되었던 악성코드가 변종 형태로 진화하여 나 타나고 있다. 따라서 본 연구에서는 각 모바일 OS별 공개된 보안 취약점 조사 및 분석을 통해, 차후에 발생될 가능성이 있는 보안 취약점 및 악성 - VII -

8 코드에 대한 대응 속도를 한 단계 향상 시킬 수 있는 계기를 마련할 수 있도록 하였다. 다. 안드로이드 기반의 행위 기반 분석 도구 개발 안드로이드 기반의 행위 기반 분석이 가능한 도구 개발을 수행하였 다. 행위 기반 분석 도구 개발을 통하여 기존 시그니처 기반의 악성코드 탐지 방법의 문제점을 보완하는 모바일 환경에 적합한 새로운 악성코드 탐지 방법의 자료로 쓰일 수 있었다. 또한 기존 시그니처 기반 악성코드 탐지 방법과 행위 기반 분석 도구를 연계한 프로토타입 구현을 통해 자 동화된 악성코드 검증 시스템의 모델을 제시하여, 웹 기반의 악성코드 검 증 시스템 구축 시 활용 가능하게 하였다. 라. 안드로이드 및 아이폰 기반의 시스템 분석 도구 개발 안드로이드 루팅 및 아이폰 탈옥을 수행한 환경에서는 시스템 레벨 에서의 악성코드 동작이 가능해진다. 이런 악성코드는 기존 어플리케이션 레벨에서의 악성코드 탐지 방법으로는 탐지가 불가능하다는 문제점이 존 재한다. 본 연구에서는 안드로이드 및 아이폰 기반의 시스템 분석 도구 개발을 통해 시스템 레벨에서 동작하는 악성코드에 대한 탐지 연구 및 도구 개발을 수행하였다. 마. 아이폰 어플리케이션 디스어셈블 아이폰 어플리케이션은 일반적으로 암호화되어 있어, 어플리케이션 분석을 위한 소스코드를 얻어내는 것이 쉽지 않다. 또한 암호화를 해제하 여 바이너리 코드를 얻어낸다고 하더라도 아이폰 어플리케이션의 특수한 구조로 인하여 분석이 어려운 실정이다. 본 연구에서는 아이폰 어플리케 이션에 디스어셈블에 대한 연구를 진행하여 아이폰 어플리케이션에 대한 - VIII -

9 정형화된 분석이 가능하도록 하였다. 5. 활용에 대한 건의 본 연구의 결과물 중 안드로이드 행위 기반 분석 도구는 안드로 이드 악성코드 분석을 위한 직접적인 활용이 가능하다. 또한 시그니처 DB 및 안드로이드 행위 기반 분석 도구로 제작된 웹 기반의 프로토타입의 경우 앱스토어 환경과 접목시킨 악성코 드 분석 시스템으로 직접적인 활용이 가능하다. 6. 기대효과 본 연구의 결과물은 안드로이드 환경에서의 행위 기반 분석을 수 행한 것으로 새로운 모바일 악성코드 분석을 위한 가이드라인 제 시가 가능하다. - IX -

10 SUMMARY 1. Title Study of malware detection based mobile OS 2. Purpose of the study The Purpose of this study is that mobile operating system-based countermeasures for malicious code to perform the study. 3. Contents and scope Add determined by monitoring the use of a particular API to traditionally used as a signature-based detection is complementing the malware check. - Determined by monitoring the use of a particular API complements the traditional approach to the study - Development of an Android-based dynamic analysis tools - Development of an Android-based static analysis tools - Implementation of mobile malware detecting system prototype - X -

11 4. Results of the study - Analysis of mobile OS constructer and security mechanism - Research and Analysis of published security vulnerability - Development of Android-based activity-based analysis tool - Development of Android and iphone-based system analysis tool - Disassembling the iphone applications 5. Expected effects and applications - For the Android malware analysis of the proposed activity-based analysis tool can be used directly. - XI -

12 목 차 제 1 장 개 요 1 제 2 장 모바일 운영체제 분석 3 제 1 절 안드로이드 3 제 2 절 아이폰 OS 15 제 3 절 심비안 21 제 4 절 블랙베리 OS 26 제 5 절 윈도우 모바일 28 제 3 장 모바일 OS 보안 취약점 조사 및 분석 23 제 1 절 보안 취약점 및 악성코드 32 제 4 장 안드로이드 악성코드 분석 도구 85 제 1 절 정적 분석 도구 60 제 2 절 동적 분석 도구 76 제 3 절 안드로이드 파일 시스템 분석 도구 83 제 5 장 아이폰 악성코드 분석 도구 69 제 1 절 아이폰 디스어셈블 96 제 2 절 아이폰 파일 시스템 분석 도구 105 제 6 장 프로토타입 구성 및 검증 109 제 1 절 프로토타입 구성 XII -

13 제 7 장 결 론 115 참고 문헌 XIII -

14 Contents Chapter 1. Introduction 1 Chapter 2. Mobile operating system analysis 3 Clause 1. Android 3 Clause 2. iphone OS 15 Clause 3. Symbian 21 Clause 4. Blackberry OS 26 Clause 5. Windows Mobile 82 Chapter 3. Mobile OS security threats and analysis 2 3 Clause 1. Security threats and malware 23 Chapter 4. Android malware analysis tool 5 8 Clause 1. Static analysis tool 06 Clause 2. Dynamic analysis tool 67 Clause 3. Android file system analysis tool 3 8 Chapter 5. iphone malware analysis tool 69 Clause 1. iphone disassemble 69 Clause 2. iphone file system analysis tool 105 Chapter 6. Implementation prototype and verification 109 Clause 1. Implementation prototype XIV -

15 Chapter 7. Conclusion 115 References XV -

16 그 림 목 차 (그림 2-1) 안드로이드 시스템 전체 구조 4 (그림 2-2) FriendTracker 와 FriendViewer 어플리케이션 구조 8 (그림 2-3) 두 어플리케이션 간 콤포넌트 관계 9 (그림 2-4) 안드로이드 보안 정책 01 (그림 2-5) SMS 메시지 수신 모니터링을 위한 퍼미션 설정 2 1 (그림 2-6) 오퍼레이션에 대한 퍼미션 설정 21 (그림 2-7) 아이폰 OS 구조 51 (그림 2-8) 아이폰 OS의 Security API 7 1 (그림 2-9) 개발자 등록 및 어플리케이션 등록 절차 91 (그림 2-10) 심비안 사인드 과정 42 (그림 2-11) 블랙베리 OS 서비스 내용 72 (그림 2-12) 블랙베리를 이용한 Push mail 서비스 내용 8 2 (그림 2-13) 윈도우 모바일 전체 구조 92 (그림 2-14) 윈도우 모바일 권한 체계 92 (그림 3-1) 심비안 악성코드 특징 3 (그림 3-2) 컴워리어 감염 화면 53 (그림 3-3) 스컬러 감염 화면 63 (그림 3-4) 카비르 웜 바이러스 감염 화면 73 (그림 3-5) 아이폰 보안 문제 타임라인 83 (그림 3-6) Ikee 웜 바이러스 감염 화면 34 (그림 3-7) Duh/Ikee.b에 대한 신문기사 44 (그림 3-8) Dutch 5 ransom 감염 화면 5 4 (그림 3-9) Iphone/Privacy.A 감염 화면 5 4 (그림 3-10) 모바일 사파리를 통한 공격에 대한 소개 64 (그림 3-11) 사파리 브라우저를 통한 아이폰 DoS 공격 6 4 (그림 3-12) JailbreakMe star 화면 XVI -

17 (그림 3-13) 탈옥 진행 화면 94 (그림 3-14) JailbreakMe 리다이렉트 소스 코드 9 4 (그림 3-15) 아이폰 탈옥에 사용되는 PDF 파일 05 (그림 3-16) PDF 내부에 인코딩되어 포함된 CFF폰트 0 5 (그림 3-17) PDF 파서를 사용한 디코딩 결과 화면 15 (그림 3-18) 디코딩 된 데이터 내용 15 (그림 3-19) IOSurface의 비정상적인 설정 값 2 5 (그림 3-20) 이메일을 이용한 악성 PDF 유포 35 (그림 3-21) 트위터를 이용한 악성 PDF 유포 35 (그림 3-22) 데브팀 Comex의 트위터 4 5 (그림 3-23) Frash 어플리케이션 45 (그림 3-24) 안드로이드 악성코드 65 (그림 3-25) 윈도우 모바일 악성코드 65 (그림 4-1) API 탐지를 통한 행위 기반 분석 방법 85 (그림 4-2) 안드로이드 어플리케이션 설치 과정 16 (그림 4-3) 전체 분석 과정 단계 26 (그림 4-4) undx 동작 과정 36 (그림 4-5) undx 사용을 통한.jar 파일 획득 과정 46 (그림 4-6) JAR 파일 내용 및 파일 포맷 46 (그림 4-7) IDA Pro를 이용한 JAR 파일 디스어셈블 5 6 (그림 4-8) JarAnalyzer를 이용한 JAR 파일 디스어셈블 6 6 (그림 4-9) JReversePRO 실행 화면 7 6 (그림 4-10) JReversePRO 도구를 이용한 디스어셈블 결과 화면 7 6 (그림 4-11) Java Decompiler 도구를 이용한 디컴파일 결과 화면 8 6 (그림 12) 함수 목록 분석 결과 68 (그림 4-13) 라이브러리 목록 분석 결과 96 (그림 4-14) smali 도구를 이용한 디스어셈블 결과 화면 0 7 (그림 4-15) Dedexer 도구를 이용한 디스어셈블 결과 화면 1 7 (그림 4-16) 안드로이드 정적 분석 도구 동작 과정 37 - XVII -

18 (그림 4-17) 정적 분석도구 소스 코드 및 실행 화면 47 (그림 4-18) 분석 결과를 저장하는 텍스트 파일 57 (그림 4-19) 디스어셈블 후.ddx 파일 생성 결과 화면 6 7 (그림 4-20) 안드로이드 동적 분석 도구 구성 28 (그림 4-21) 동적 분석 도구를 이용한 정보 유출 API 탐지 3 8 (그림 4-22) 펌웨어 변경 도구 58 (그림 4-23) 취약점을 이용한 루팅 도구 68 (그림 4-24) 이클립스 다운로드 78 (그림 4-25) 안드로이드 SDK 다운로드 7 8 (그림 4-26) 이클립스 Install 창 화면 8 8 (그림 4-27) Add Site 창 화면 9 8 (그림 4-28) Install Details 화면 9 8 (그림 4-29) Review License 화면 0 9 (그림 4-30) Preferense 화면 1 9 (그림 4-31) Android SDK and AVD Manager 화면 1 9 (그림 4-32) 선택 패키지 설치 화면 9 2 (그림 4-33) 안드로이드 파일 시스템 분석 도구 구현 메커니즘 39 (그림 4-34) 파일 시스템 분석 도구 9 4 (그림 4-35) 결과 파일 49 (그림 5-1) 아이폰 메모리 구조 79 (그림 5-2) 전체 흐름도 79 (그림 5-3) Spirit 도구 8 9 (그림 5-4) SBSettings를 이용한 어플리케이션 위치 정보 획득 100 (그림 5-5) otool 명령어 수행 결과 101 (그림 5-6) 프로세스 ID 정보 획득 101 (그림 5-7) ifile을 이용한 결과 파일 전송 103 (그림 5-8) 파일 로드 화면 103 (그림 5-9) 분석 결과 화면 104 (그림 5-10) 아이폰 파일 시스템 분석 도구 XVIII -

19 (그림 5-11) UI 화면 107 (그림 5-12) 아이폰 분석 결과 파일 107 (그림 6-1) 프로토타입 구성 109 (그림 6-2) 프로토타입 구현 메커니즘 12 (그림 6-3) 프로토타입 업로드 화면 13 - XIX -

20 표 목 차 [표 2-1] 심비안 운영체제 파일 시스템 2 [표 2-2] 심비안 사인에 따른 사용 가능한 권한 여부 52 [표 3-1] 컴워리어가 전송하는 MMS 예제 5 3 [표 4-1] 정보 유출 API 목록 95 [표 4-2] 코드 커버리지 기준 67 [표 4-3] 안드로이드 컴파일을 위한 도구 설치 87 [표 4-4] repo 준비 97 [표 4-5] 안드로이드 소스코드 다운로드 97 [표 4-6] Stack.c 파일 수정 08 [표 4-7] Object.c 파일 수정 08 [표 4-8] stubdefs.c 파일 수정 1 8 [표 4-9] 루팅 시 가능한 작업 목록 8 3 [표 5-1] 시디아를 통해서 설치되는 도구 및 설명 9 [표 5-2] 시디아를 통해서 설치되는 도구 및 설명 9 [표 5-3] GDB 도구를 이용한 메모리 덤프 102 [표 5-4] 복호화된 어플리케이션 파일 생성 102 [표 6-1] Apache 설치 방법 10 [표 6-2] MySQL 설치 방법 10 [표 6-3] PHP 설치 방법 10 [표 6-4] CGI 설정 방법 1 [표 6-5] 웹서버 재구동 1 - XX -

21 제 1 장 개 요 스마트폰은 음성통화, 무선인터넷 등 휴대폰 기능을 기본으로 모바일 환경에서 멀티 기능을 수행할 수 있는 유저 지향적 모바일 PC 플랫폼을 의미한다. 스마트폰은 고성능 CPU와 상용 OS를 갖추고 있어, 일반 PC의 기능인 개인정보관리, 음악과 동영상 등의 고용량 멀티미디어 컨텐츠의 저장 및 재생이 가능하고 OS의 탑재를 통해 사용자가 스마트폰에 S/W의 설치가 자유롭다는 특징이 있다. 특히 S/W의 설치가 자유롭다는 점은 확 실하게 일반 휴대폰과 스마트폰을 구분 짓는 특징으로 스마트폰의 가장 큰 장점으로 꼽힌다. 이런 장점을 통해 다양한 S/W를 다운로드 하는 앱 스토어(App Store)가 활성화 되었고, 앱스토어의 활성화를 통해 다양한 S/W가 등장했다. 아직까지 기존 휴대폰에 비해 낮은 점유율을 가지고 있는 스마트폰 시장이지만 꾸준한 증가세를 보여 왔고, 지난 2009년 12월 아이폰의 국내 출시를 기점으로 사용자가 급증하는 추세를 보이고 있다. 또한 여러 제조 사에서 다양한 운영체제 기반의 스마트폰을 출시할 예정이어서, 국내 스 마트폰 시장은 앞으로 더욱 더 커질 전망이다. 이렇게 다양한 제품의 출시로 인해 빠른 성장세를 보이는 국내 스마 트폰 시장에 대해 모바일 브로드밴드 시장 활성화에 크게 기여할 것이라 는 환영의 목소리와 함께 PC 수준의 기능을 제공하는 스마트폰이 공격코 드의 새로운 보금자리가 될 것이라고 보안 전문가들은 우려하고 있다. 이는 스마트폰이 단순한 핸드폰이 아닌 다양한 네트워크 인터페이스 를 가진 컴퓨터로 현재 인터넷 환경에서 발생할 수 있는 모든 보안 위협 이 스마트폰 환경에서 동일하게 적용되기 때문이다. 또한 개인 중요 정보 가 저장되고 오픈 개발 환경의 제공으로 자유로운 프로그램 개발 및 설 치가 가능하다는 점 또한 악성코드 증가의 요인으로 작용한다. 실제 2004년 카비르(Cabir)라는 웜(Worm)이 최초 발견된 이후 지금까 - 1 -

22 지 약 600 여종의 악성코드가 스마트폰에서 발견되었고, 현재까지 발견된 모바일 악성코드는 단순히 아이콘을 변경하는 수준부터 개인정보 유출, 과금 유도 등 실질적인 피해를 가져오는 악성코드까지 다양한 형태의 모 습으로 발견되고 있다. 모바일 악성코드 피해에 대해 비교적 안전지대라 여겨지던 국내에서 도 최근 윈도우 모바일 환경에서 국제전화를 무단으로 발신하는 악성코 드인 '트레드 다이얼(TredDial)'이 등장해 첫 피해가 발생하였다. 이렇듯 스마트폰 이용자가 증가함에 따라 모바일 악성코드도 증가하 고 있어, 모바일 악성코드 대응을 통한 스마트폰 보안 문제 해결이 가장 큰 선결과제의 하나로 부각되고 있는 실정이다. 이에 따라 모바일 환경에 서 동작하는 여러 안티 바이러스 제품이 출시되어 있지만, 현재까지 악성 코드 대응에 있어 미흡하고, 기존에 시그니처 기반의 탐지 방법만으로는 새로이 등장하는 모바일 악성코드에 대한 대응이 불가능한 경우가 많아 이에 대한 연구가 필요한 실정이다

23 제 2 장 모바일 운영체제 분석 현재 국내에 출시된 스마트폰 용 모바일 운영체제는 크게 안드로이 드, 아이폰 OS, 심비안, 블랙베리 OS, 윈도우 모바일 등 5가지로 나누어 볼 수 있고, 각각의 운영체제는 보안성의 강화를 위한 개별적인 보안 메 커니즘을 가지고 있다. 이 장에서는 모바일 운영체제 분석을 통해 각각의 운영체제가 보안성 강화를 위해 가지고 있는 보안 메커니즘에 대해서 살 펴볼 것이다. 제 1 절 안드로이드 1. 정의 및 특징 안드로이드 운영체제는 구글 社 에서 제공하는 모바일 운영체제로 전 화기를 비롯하여, 모바일 디바이스를 위한 운영체제와 미들웨어 그리고 핵심 어플리케이션을 포함하고 있는 모바일 디바이스를 위한 소프트웨어 스택(Stack)을 의미한다. 현재 오픈소스 정책을 통해 운영되고 있으며, 2009년 4월 안드로이드 1.5 버전이 출시된 이후 2010년 6월 현재 2.2 버 전까지 배포 되었다. 2. 시스템 구조 안드로이드는 (그림 2-1)과 같이 Applications, Applications Framework, System Libraries, HAL, Linux Kernel의 5가지 계층으로 구성 된다. Applications 와 Appications Framework 계층은 Java 언어로 구성되 고, System Libraries와 HAL은 C/C++, Linux Kernel은 C언어로 구성되어 있다

24 (그림 2-1) 안드로이드 시스템 전체 구조 각 계층의 특징을 살펴보면 다음과 같다. 가. Applications 이메일 클라이언트, 문자메시지 프로그램, 달력, 지도, 브라우저, 전 화번호부 등의 핵심 어플리케이션들이 설치되며 Java 언어로 작성됨 나. Application Framework 개발자들은 핵심 어플리케이션들에서 사용되는 것과 동일한 프레임 워크 API에 완벽하게 접근할 수 있기 때문에 컴포넌트의 재사용이 용이 함 다. Libraries - 4 -

25 안드로이드의 다양한 컴포넌트에 의해 사용되는 C/C++ 라이브러리 집합을 포함 라. Android Runtime 안드로이드는 Java 언어의 핵심 라이브러리에서 사용가능한 대부분 의 기능들을 포함하는 핵심 라이브러리들을 포함하며 모든 안드로이드 어플리케이션은 달빅(Dalvik)이라 불리는 안드로이드 가상 머신(Virtual Machine)내에 자신의 인스턴스(Instance)를 가지고 자신의 프로세스 내에 서 동작함 마. Linux Kernel 보안, 메모리 관리, 프로세스 관리, 네트워크 스택, 드라이버 모델 등 과 같은 핵심 시스템 서비스를 위해 리눅스 버전 에 기반 함 3. 어플리케이션 구조 안드로이드 어플리케이션은 Activity, Broadcast Receiver, Service, Content Provider 이 4가지로 구성되어 있다. 어플리케 이션에서 어떤 컴포넌트들을 사용할지 결정하였다면, 이 컴포넌트들의 목 록을 AndroidManifest.xml 파일에 기록해야 한다. 이 xml 파일은 어느 어 플리케이션에서 이 컴포넌트들을 선언했는지, 그들의 기능과 요구사항은 무엇인지를 기록하는 파일이다. 각각의 컴포넌트 모델에 관한 설명은 다 음과 같다. 가. Activity Activity는 어플리케이션에서 하나의 화면을 지칭한다. 각 Activity는 - 5 -

26 Activity base class를 상속하여 구현한 하나의 클래스이며, 사용자에게 View와 Event 응답으로 이루어진 인터페이스를 화면상에 보여주는 역할 을 한다. 화면이 오픈되면, 이전 화면은 멈추게 되며, history stack에 저 장되어 사용자는 history 내에 있는 이전 화면으로 돌아가는 것이 가능하 다. 이전 화면이 history stack 내에 저장될 필요가 없는 경우 삭제될 수 있으며, 안드로이드는 이 history stack을 home screen 으로부터 실행시킨 각 어플리케이션마다 유지하게 된다. 나. Broadcast Receiver (Intent Receiver) Broadcast Receiver 는 작성한 어플리케이션 코드 내에서 핸드폰 에 통화가 걸려오거나, 데이터 네트워크 접속이 활성화되는 것과 같은 외 부 이벤트를 처리하는데 사용된다. Broadcast Receiver는 UI(User Interface)를 그려주는 것은 아니고, NotificationsManager를 이용하여 사 용자에게 어떤 일이 발생했다는 것을 알려준다. Broadcast Receiver도 AndroidManifest.xml 파일에 등록되지만, Context.registerReceiver()를 이용 하여 코드 상에서 등록해 줄 수도 있다. 다. Service Service는 UI와 상관없이 아주 오랫동안 존재하며 실행되는 코드이 다. 음악 재생 어플리케이션에서 목록을 보여주는 UI가 아닌 노래를 재생 하는 미디어 플레이어와 같은 것을 의미한다. 만약 다른 어플리케이션이 실행되어 새로운 어플리케이션이 실행되면 미디어 플레이어의 Activity는 Context.startService()를 이용하여 Service로 실행한다. 그렇게 되면 시스 템은 음악 재생 서비스를 멈출 때까지 계속 재생할 것이다. Context.bindService() 메소드는 서비스에 연결하거나 아직 시작하지 않은 Service를 시작한다. Service에 연결이 되면 Service에 접근 가능한 인터페이스를 통해 멈춤, 다시 재생 등을 할 수 있도록 접근 이 가능하 - 6 -

27 다. 라. Content Provider 어플리케이션은 자신의 데이터를 SQLite 데이터베이스 또는 다른 방 법으로 파일에 저장이 가능하다. Content Provider 는 하나의 어플리 케이션이 가지는 데이터가 다른 어플리케이션과 데이터를 공유할 필요가 있을 때 아주 유용하다. 이 클래스는 다른 어플리케이션이 데이터를 저장 하거나, 가져오는 것과 같은 작업을 할 수 있도록 해준다. 4. 보안 메커니즘 안드로이드는 각각의 어플리케이션과 시스템 내의 각 영역들이, 자신 의 고유한 프로세스 상에서 실행되는 멀티 프로세스 시스템이다. 어플리 케이션과 시스템간의 대부분의 보안은 어플리케이션에 할당된 유저 ID나 그룹 ID와 같은 표준 리눅스 기능을 통해 프로세스 레벨에서 강제된다. 보다 섬세한 추가적인 보안 기능은 특정 프로세스가 수행할 수 있는 특 정 오퍼레이션에 제약을 부가하는 퍼미션(Permission) 메커니즘에 의해 제 공된다. 그리고 데이터의 특정 영역에 대한 임시적 접근을 부여하는 URI 별 퍼미션이 있다. 가. Security Architecture 안드로이드 보안 구조의 핵심은 기본적으로 어떠한 어플리케이션들 도 다른 어플리케이션과 운영체제, 또는 사용자에게 나쁜 영향을 미칠 수 있는 임의의 오퍼레이션을 수행할 수 있는 퍼미션을 가지지 않는다는 것 이다. 이것은 (주소록 혹은 이메일과 같은) 사용자의 개인적인 데이터에 대한 읽고 쓰기 및 다른 어플리케이션의 파일에 대한 읽고 쓰기, 네트워 크 접근, 디바이스에 대한 활성 상태 유지 등을 포함한다

28 어플리케이션의 프로세스는 각각 보안 샌드박스(Secure Sandbox) 형 태로 생성된다. 이것은 추가적인 기능들을 위해 필요한 퍼미션을 명시적 으로 선언하지 않고서는 다른 어플리케이션의 동작을 방해할 수 없음을 의미한다. 이러한 퍼미션들은 다양한 방법을 통해 운영체제에 의해 제어 될 수 있으며, 전형적으로는 인증서를 기반으로 자동으로 허용하거나, 사 용자에게 확인을 요청하는 방법에 의해 제어된다. 하나의 어플리케이션에 의해 요청된 퍼미션은 그 어플리케이션 내에 정적으로 선언되므로 그 퍼 미션은 그 어플리케이션의 설치 전에 알 수 있으며, 그 후에는 변경될 수 없다. 나. Security Policy 안드로이드 보안 정책을 설명하기 위한 하나의 예로 (그림 2-2)와 같 이 친구 찾기 동작을 수행하는 FriendTracker 어플리케이션과 이를 화면에 보여주는 FriendViewer 어플리케이션이 있다고 가정하자. (그림 2-2) FriendTracker 와 FriendViewer 어플리케이션 구조 실제 핵심적인 동작을 수행하는 FriendTracker 어플리케이션은 Activity, Service, Broadcast receiver, Content provider 의 4가지 컴포넌트로 구성되고, 친구 찾기 결과를 화면에 보여주는 - 8 -

29 FriendViewer' 어플리케이션은 데이터 저장 공간인 Content provider를 제외한 3가지 컴포넌트로 구성된다. 두 어플리케이션을 구성하는 컴포넌 트간의 관계는 (그림 2-3)과 같다. (그림 2-3) 두 어플리케이션 간 콤포넌트 관계 FriendTracker 어플리케이션은 System Server에 있는 위치 추적 을 위한 Location manager와 bind 하여 FriendTracker 서비스를 수행 한다. 이 때 생성되는 정보는 Content Provider 에 저장되고, FriendViewer 어플리케이션은 FriendTracker 의 Content Provider 를 통해 정보를 읽어와 이를 화면에 보여주게 된다. 이렇게 수 행되는 경우 안드로이드의 보안 정책은 (그림 2-4)와 같다

30 (그림 2-4) 안드로이드 보안 정책 안드로이드 보안 정책은 크게 리눅스 시스템과 안드로이드 미들웨어 로 나누어 볼 수 있다. 리눅스 시스템의 경우 리눅스 시스템에 기초한 system-level isolation을 통해 고유의 유저 ID를 배정받아 동작하도록 하 고, 안드로이드 미들웨어는 ICC(Inter Component Communication)의 동작 시 ICC reference monitor를 통해 AndroidManifest.xml에 정의된 퍼미션을 준수하는지 감시하는 정책이 함께 이루어지도록 하여 보안을 강화하고 있다. 다. Application Signing 모든 안드로이드 어플리케이션들(.apk 파일들)은 개발자가 보유한 개 인키 인증서로 서명되어야 한다. 이 인증서는 어플리케이션의 작성자를 식별하며, 공식적인 인증기관에 의해 서명될 필요가 없다. 안드로이드 어 플리케이션에서 자체적으로 서명된 인증서를 사용하는 것은, 완벽하게 허 용되며 전형적이다. 인증서는 어플리케이션들 간의 신뢰 관계를 확립하기 위해서 사용될 뿐이며, 어플리케이션이 설치될 수 있는 가에 대한 판매 통제를 위한 것이 아니다. 서명이 보안에 미치는 가장 중요한 사항들은 서명 기반의 퍼미션에 누가 접근 가능하며 누가 사용자 ID를 공유할 수 있는지를 결정하는 것이다

31 라. User IDs and File Access 디바이스 상에 설치된 각각의 안드로이드 패키지(.apk) 파일에는 그 것 자신의 고유한 리눅스 유저 ID가 부여된다. 이것은 패키지에 대한 샌 드박스를 만들며 그것이 다른 어플리케이션을 관여하는 것을 방지한다. 이 유저 ID는 어플리케이션이 디바이스에 설치될 때 할당되며, 그 디바이 스에 그것이 존속하는 동안 변하지 않고 유지된다. 보안에 대한 강제는 프로세스 레벨에서 이루어지기 때문에, 임의의 두 개의 패키지 내의 코드는 일반적으로 동일한 프로세스에서 실행될 수 없다. 따라서 그것은 서로 다른 리눅스 유저로서 실행되어야 한다. 사용 자는 그것들에게 동일한 유저 ID를 부여하기 위해, 각각의 패키지 내의 AndroidManifest.xml의 manifest 태그의 shareduserid 애트리뷰트 (Attribute)를 사용할 수 있다. 이렇게 함으로써, 보안적 측면에서 두 개의 패키지는 동일한 어플리케이션으로 간주되며 동일한 유저 ID와 파일 퍼 미션을 갖는다. 마. Using Permissions 생성된 안드로이드 어플리케이션은 기본적으로 어떠한 퍼미션도 가 지고 있지 않다. 따라서 디바이스의 보호된 기능을 사용하기 위해서는, 개발자가 AndroidManifest.xml 내에 하나 또는 그 이상의 <uses-permission> 태그를 이용하여 어플리케이션이 필요로 하는 퍼미션 을 선언해야 한다. 예를 들어 SMS 메시지 수신을 모니터링 할 필요가 있는 어플리케이 션은 (그림 2-5)와 같이 지정할 수 있다

32 (그림 2-5) SMS 메시지 수신 모니터링을 위한 퍼미션 설정 어플리케이션 설치 시점에, 어플리케이션에 의해 요청된 퍼미션은 해 당 퍼미션을 선언하고 있는 어플리케이션의 서명 확인과 사용자와의 상 호작용을 통해 패키지 인스톨러에 의해 어플리케이션에게 부여된다. 어플 리케이션이 실행되는 동안에는 사용자와의 어떠한 확인 절차도 이루어지 지 않는다. 바. Declaring and Enforcing Permissions 특정 자원에 대한 사용을 위해, 개발자는 하나 또는 그 이상의 <permission> 태그를 사용해서 AndroidManifest.xml 에 퍼미션을 정의 해야 한다. 예를 들어 누가 자신의 액티비티들 중의 하나를 시작할 수 있는 가를 제어하길 원하는 어플리케이션은, (그림 2-6)과 같은 방식으로 이러한 오 퍼레이션에 대한 퍼미션을 선언할 수 있다. (그림 2-6) 오퍼레이션에 대한 퍼미션 설정 사. Enforcing Permissions in AndroidManifest.xml 시스템이나 어플리케이션의 모든 컴포넌트에 대한 접근을 제약하는 상위계층의 퍼미션들은 AndroidManifest.xml을 통해서 적용될 수 있다. 이 를 위해 요구되는 것은 필요한 컴포넌트에 android:permission 애트리뷰트 를 포함하고, 그 컴포넌트에 대한 접근을 제어하기 위해 사용될 퍼미션

33 이름을 지정하는 것이 전부이다. o <activity> 태그에 적용된 액티비티 퍼미션(Activity Permission)은, 누가 해당 액티비티를 시작할 수 있는지를 제약한다. 그 퍼미션은 Context.startActivity()와 Activity.start ActivityForResult() 함수 내에 서 점검된다. 만약 호출자(Caller)가 필요한 퍼미션을 가지고 있지 않으면, Security Exception이 호출되는 곳에서 발생 된다. o <sevice> 태그에 적용된 서비스 퍼미션은, 누가 해당 서비스를 시 작하거나 바인드 할 수 있는가를 제약한다. 퍼미션은 Context.startService(), Contextstop Service() 그리고 Context.bindService() 함수 내에서 점검된다. 만약 호출자가 필요한 퍼미션을 가지고 있지 않다면, Security Exception이 호출되는 곳에 서 발생된다. o <receiver> 태그에 적용된 브로드캐스트 리시버(Broadcast receiver) 퍼미션은, 누가 해당 리시버에게 브로드캐스트를 발송할 수 있는가 를 제약한다. 퍼미션은 Context.send Broadcast()가 리턴된 후, 시스 템이 제출된 브로드캐스트를 주어진 리시버에 전달하기를 시도할 때 점검된다. 결론적으로, 퍼미션 실패는 호출자에게 예외 결과를 발생시키지 않는다; 다만 퍼미션 실패는 인텐트를 전달하지 못할 뿐이다. 같은 방식으로, 프로그램적으로 등록된 리시버에게 누가 브 로드캐스트를 할 수 있는가를 제어하기 위해 Context.registerReceiver()에 퍼미션을 제공할 수 있다. 다른 방법으 로 어떤 브로드캐스트 리시버 오브젝트가 브로드캐스트를 수신하는 것이 허용되는 지를 제약하기 위해, Context.sendBroadcast()를 호출 할 때 퍼미션이 제공될 수 있다. o <provider> 태그에 적용된 컨텐트 프로바이더(Content provider) 퍼

34 미션은, 누가 컨텐트 프로바이더에 있는 데이터에 접근할 수 있는 가를 제약한다. 다른 컴포넌트와 달리, 개발자가 설정할 수 있는 두 개의 별도의 퍼미션 애트리뷰트가 있다. android:readpermission 은 누가 프로바이더로부터 읽기를 할 수 있는가를 제약하며, android:readpermission은 누가 그것에 쓰기를 할 수 있는가를 제 약한다. 퍼미션은 처음 프로바이더를 얻어올 때 점검되며, 그 후 프로바이더에 대한 오퍼레이션(Operation)을 수행한다. ContenResolver.query()를 사용하는 것은 읽기 퍼미션을 가지는 것 을 필요로 하며, ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete()를 사용하는 것은 쓰기 퍼미션을 필요로 한다. 아. URI Permissions URI(Uniform Resource Identifier)는 URL(Unjform Resource Locator) 와 URN(Uniform Resource Name)의 통칭으로, 어떠한 자원을 찾아가는데 필요한 경로를 의미한다. 표준 퍼미션 시스템과는 별개로 더 세부적인 접 근 제어를 위하여 안드로이드에서는 URI 퍼미션을 제공하고 있다. URI 퍼미션은 액티비티를 시작시킬 때나 혹은 결과를 액티비티에 리 턴할 때, 그것을 호출한 곳에서 Intent.FLAG_GRANT_READ_URI_PERMISSION 및(또는) Intent.FLAG_GRANT_WRITE_URI_PERMISSION을 설정할 수 있다. 이것은 인텐트를 수신하는 액티비티가 인텐트에 대응되는 컨텐트 프로바이더 내 의 데이터 접근 퍼미션을 보유하고 있는지와 상관없이, 그 액티비티에게 그 인텐트 내의 특정 데이터 URI에 대한 접근 퍼미션을 부여한다. 이 메커니즘은 사용자 상호작용(첨부파일을 여는 것, 주소록을 리스 트에서 선택하는 것 등)이 임시로 세부적인 퍼미션을 부여하게 하는 곳에 서 일반적인 capability-style 모델을 가능하게 한다. 이것은 어플리케 이션들에 의해 필요한 퍼미션을 오직 그것들이 직접적으로 관련된 동작

35 에만 국한하는 핵심 설비가 될 수 있다. 제 2 절 아이폰 OS 1. 정의 및 특징 아이폰 OS는 애플 社 에서 개발한 아이폰과 아이팟 터치를 위한 비공 개 모바일 운영체제이다. 애플의 PC 용 운영체제인 Mac OS X를 기반으 로 제작되었고, 2008년 7월에 아이폰 OS 2.0 버전이 최초 릴리즈 된 이후 현재 아이폰 OS 4.1 버전까지 출시되었고, 아이폰 OS 4.2 버전이 릴리즈 될 예정에 있다. 아이폰 OS 4.0 이전의 버전까지는 전화와 멀티미디 어 기능인 ipod 이외의 기능에 대해서는 멀티태스킹(Multi-tasking)을 지원 하지 않으며 운영체제에 대한 철저한 비공개 정책으로 보안성을 높이고 있다. 2. 구조 (그림 2-7) 아이폰 OS 구조

36 아이폰 OS는 (그림 2-7)과 같이 Application, Cocoa Touch, Media, Core Services, Core OS 의 5개의 레이어로 구성된다. 이 중 보안에 관련된 서비스는 Core Services 레이어 내부에 존재하 고 보안 서비스(Security Service)를 위한 API들이 존재한다. 3. 보안 메커니즘 아이폰 OS의 보안 메커니즘은 크게 내부적인 보안 메커니즘과 애플 에 의한 정책적인 보안 메커니즘으로 나누어 볼 수 있다. 가. 내부적 보안 메커니즘 내부적인 보안 메커니즘은 아이폰 OS 자체에 존재하는 보안 메커니 즘으로 크게 Security Server Daemon 과 Security APIs 로 구성된 다. (1) Security Server Daemon 몇 가지 보안 프로토콜(Access to keychain items, root certificate trust management)로 구현되며 아이폰 OS 보안에 있어서 매우 중요하다. 아이폰 OS에서 Security Server는 퍼블릭(public) API를 가지지 않는 대신, 어플리케이션은 키체인 서비스 API(Keychain Services API)와 인증서 그리 고 신뢰 서비스(the Certificate, Key, and Trust Services) API를 사용하여 Security Server와 통신하게 된다. 이는 Mac OS X 와는 달리 별도의 Security Server에 접근하기 위한 인터페이스가 존재하지 않기 때문이다. (2) Security APIs

37 아이폰 OS의 Security API는 (그림 2-8)과 같이 Core Services 레이어 내부에 존재하며 각각의 특징은 다음과 같다. (그림 2-8) 아이폰 OS의 Security API (가) KeyChain o 패스워드, 키, 인증서 그리고 다른 비밀 정보를 저장하는 용도로 사 용 o KeyChain은 cryptographic 함수 (비밀 정보의 암호와와 복호화에 사 용되는 함수)와 data storage 함수 (파일 안에 비밀 정보와 관계된 데 이터를 저장하는데 사용되는 함수)를 통해 구현 되므로, KeyChain 서 비스는 Common Crypto danamic library를 호출하게 됨 (나) CFNetwork o 안전한 접속을 보장하는 보안 서비스의 기본 API o 어플리케이션이 secure data stream을 생성 유지하도록 하고 전송하는 메시지에 인증 정보를 추가하는 역할을 수행 o High-level API (다) Certificate, Key and Trust Services

38 o 인증서 제작, 관리, 읽기 수행 o Keychain에 인증서를 추가 o 암호화 키를 생성 o 암호화와 복호화 수행 o 데이터의 사인(Sign)을 수행하고 시그니처(Signature)가 유효한 지 검사 o Trust policies 관리 o 이 모든 서비스를 위해서, API는 Common Crypto dynamic library와 other Core OS-level services를 호출해야만 함 (라) Randomization Services o 암호학적으로 안전한 난수발생을 위한 서비스 o 난수는 컴퓨터 알고리즘을 통해 생성하며, 난수 생성을 위해 Randomization Services는 Core OS Layer에 있는 난수 발생기를 호출함 나. 정책적 보안 메커니즘 아이폰 OS는 OS에 대한 세부적인 사항을 공개하지 않는, 폐쇄적인 정책과 더불어 정책적인 보안 메커니즘 적용을 통하여 보안성을 강화하 고 있다. 정책적 보안 메커니즘의 대표적인 예로는 어플리케이션 간 데이 터 공유 금지와 앱스토어에 어플리케이션 등록 시 강력한 어플리케이션 검증 과정을 들 수 있다. 각각에 대하여 살펴보면 다음과 같다. (1) 어플리케이션 간 데이터 공유 금지 아이폰 OS에서 동작하는 어플리케이션은 기본적으로 어플리케이션 간에 데이터 공유가 금지되어 있다. 이는 보안성을 높이기 위한 하나의 방법으로, 어플리케이션간의 데이터 공유 금지를 통하여 악성코드 감염 시에도 악성코드가 다른 어플리케이션 내부의 데이터에 접근이 불가능하 게 설계되어 보안성을 높일 수 있다는 장점이 있다

39 (2) 강력한 어플리케이션 검증 과정 현재 애플의 앱스토어(App Store)는 (그림 2-9)와 같이 어플리케이션 등록 시에 애플의 검증과정을 거치도록 되어 있으며, 이 검증 과정이 통 과 되어야만 앱스토어에 어플리케이션 등록이 가능하게 된다. (그림 2-9) 개발자 등록 및 어플리케이션 등록 절차 애플의 검증 과정은 자체 심의로 이루어지는데 이는 매우 형식적이 다. 먼저 심의 기준이 외부에 공개되어 있지 않고, 어떠한 과정을 거치는 지를 알 수 없기 때문에 개발자들은 개발 도중에 기준을 맞추기가 어렵 다는 단점이 존재한다. 또한 개발자가 개발한 컨텐츠가 등록대기에 들어 가고 얼마 후에 등록이 확정되는지를 알 수가 없으며, 심지어 애플 심사 와 관련해 애플의 수익성을 해할 것이라 판단되는 어플리케이션들의 경 우 결코 등록되지 않는다. 이에 대한 대표적인 예로 모바일 웹 브라우저 인 애플의 사파리를 위협하는 오페라 미니 모바일 이 등록을 거절당 한 사례가 있었다. 이에 대해 애플은 지난 아이폰 3.0 컨퍼런스를 통해 등록을 요청한

40 어플리케이션 중 약 96%가 등록되고 있다고 밝히고 등록되는 어플리케이 션 중 98%가 7일 이내에 등록되고 있다고 밝혔다. 하지만 여전히 자체 심의 기준은 공개되어 있지 않고 있다. 어플리케이션 검증 시 정확한 심의 기준은 공개되어 있지 않지만, 현 재까지 개발자들의 경험을 통하여 알려진 어플리케이션 등록 거절 사유 는 다음과 같다. o 진동 기능이 들어갈 때 아이팟에서 처리를 하지 않는 경우 o 어플리케이션 기능이 부실한 경우 o 아이콘과 리뷰 화면에 수영복 등장 o 기능 미 구현 o 기기의 고유 번호나 핸드폰 번호를 화면에 노출 o 무형의 컨텐츠를 애플 결제 시스템 외에 다른 방식(사파리)을 통한 결제 o 표준으로 지원하지 않는 API를 사용하여 개발 o 스크린샷으로 인한 거절(저작권, 상표권, 초상권, 성인/폭력 등) o 사용법이 어렵다고 판단되는 경우 o 아이폰, 아이팟, 아이팟 용 이어폰과 유사한 이미지를 사용하는 경우 o 폴라로이드 사진을 연상할 수 있는 이미지를 사용(저작권 침해) o 컨텐츠 중에 특정 업체에 대한 비방이 존재하는 경우 o 특정 이미지를 표절하여 유사하게 사용하고 있다고 판단되는 경우 o 알림창을 사용자의 입력을 받을 수 있도록 변경한 경우 o 여성의 가슴골이 보이는 경우 o 성적으로 자극할 수 있는 내용이 존재하는 경우 o 어플리케이션 소개에 어플리케이션 판매 수익금을 기부하겠다는 내 용이 존재하는 경우 o 소개글에 이런 기능은 애플 SDK 정책상 불가능 합니다 라고 쓰여 져 있는 경우 o App name과 Product name이 다르게 표시되는 경우

41 o 탭 바에 별 아이콘이 즐겨찾기 메뉴가 아닌 다른 메뉴로 변경된 경우 o Play, Pause 버튼을 미디어 플레이어와 슬라이드 외에 사용한 경우 o 웹 뷰로 웹 페이지를 불러올 때, 로딩 이미지를 구현하지 않은 경우 o 패러디 이미지를 사용한 경우 o 게임 스코어 및 내용을 아이폰에서 서버로 전송할 때, 사용자의 동의 를 받지 않은 경우 o 어플리케이션 테스트 시 다운 현상이 발생하는 경우 o 스티브 잡스 사진 및 패러디 사진을 사용하는 경우 o 비속어 단어를 사용하는 경우 o 설명문과 실제 기능이 다른 어플리케이션인 경우 o 프로그램 설명이나 이미지 등에 가격 정보를 적는 경우 제 3 절 심비안 1. 정의 및 특징 심비안은 노키아 社 에서 제공하는 모바일 운영체제로 스마트폰 운영 체제 시장의 50% 정도의 점유율을 가지는 가장 대표적인 운영체제이다. 심비안은 전화와 기타 정보 서비스에 무선으로 접근할 수 있는 소형 휴 대용 컴퓨터 전화기를 위해 설계된 EPOC 운영체제를 2001년도에 심비안 v6으로 명징을 변경하면서 탄생했다. 심비안 운영체제는 SDK가 발전하면 서 보안성을 고려하여 설계되었다. 심비안의 주요 특징은 다음과 같다. 가. ERK2 커널 o 멀티프로세싱 및 쓰레드 지원 (선점형 멀티태스킹) o 메모리 보호 o 리얼타임 지원

42 나. 클라이언트 서버 구조의 마이크로 커널 다. 단일 사용자 시스템 o 로그인과 로그아웃이 없음 2. 구조 심비안 운영체제의 파일 시스템은 일반 PC와 같이 C, D, E, Z의 네 개의 드라이브 구조를 가지며 각각에 대한 설명은 [표 2-1]과 같다. [표 2-1] 심비안 운영체제 파일 시스템 드라이브 특징 및 역할 C 쓰기가 가능하여 폰 메모리가 저장 D RAM이 예약한 임시 영역 E 쓰기 가능한 메모리 카드 영역 Z 펌웨어와 운영체제가 존재하는 영역으로 일반적인 접근 불가 3. 보안 메커니즘 심비안 보안 메커니즘은 크게 내부적인 보안 메커니즘과 정책적인 보 안 메커니즘으로 나누어 볼 수 있다. 가. 내부적 보안 메커니즘 심비안 운영체제에는 확장자가 SIS(Software Installation System)인 파 일이 존재하는데 이를 이용하면 일반 사용자가 실행 가능한 코드를 심비 안 운영체제를 이용하는 스마트폰으로 임포트(Import)가 가능하다..sis 파

43 일은 실행 가능 코드, 라이브러리, 데이터 등을 포함할 수 있기 때문에 대부분의 심비안 웜 바이러스는 바로.sis를 이용하여 악성코드를 설치하 는데 사용한다. 버전 8.1 이전의 초창기 심비안 운영체제에서는.sis 파일이 지니는 위험성에 대해서 아무런 보안 메커니즘을 가지고 있지 않았기 때문에, 이 를 악용하는 웜바이러스가 급격히 증가되는 양상을 보였다. 이러한 문제 를 해결하기 위해 현재 버전 9.x는 이와 같은 위험성을 방지하면서 전체 적인 보안을 고려하여 설계되었고, 대표적인 보안 메커니즘은 다음과 같 다. (1) 권한 제어 o 자원에 대한 직접적인 사용보다는 API 기반의 제한된 권한하의 사용 o 런타임(Runtime) 동안에는 구성을 변경할 수 없음 o DLL 코드는 해당 실행 프로세스의 권한 하에서 실행됨 o 코드에 대한 컨트롤은 심비안 운영체제 개발자에게만 허용됨 (2) 실행 영역 보호 o 실행 프로그램과 라이브러리를 데이터로부터 분리 o \sys\bin 디렉토리에서만 프로그램이 실행될 수 있음 o \private\<app UID> 디렉토리에서만 프로세스 데이터가 저장됨 나. 정책적 보안 메커니즘 심비안은 2005년 앱스토어를 통한 악성코드 전파를 방지하기 위하여 심비안 사인드(Symbian Signed)라고 불리는 강력한 코드 사이닝(Code Signing) 정책을 시행하고 있다. 코드 사이닝이란 개발자가 스마트폰 제조 사로부터 개발자 키(Key)를 부여 받고 자신이 제작한 어플리케이션을 사 인(Sign)한 후 오픈 마켓에 등록하면 오픈 마켓 측에서는 해당 어플리케 이션의 개발자 신분을 확인하고 어플리케이션의 무결성 및 보안성 등을

44 검토해서 안전한 어플리케이션일 경우에만 배포를 하는 일련의 과정을 의미한다. 이러한 과정을 통해 오픈 마켓을 통한 악성코드의 확산을 방지 할 수 있는 장점을 가진다. 심비안 사인드 정책은 (그림 2-10)과 같은 과 정을 통해 이루어진다. (그림 2-10) 심비안 사인드 과정 개발자가 응용프로그램 개발 후 심비안 사인드에 요청하면, 심비안 사인드는 제 3의 검증 기관(NSTL, SOGETI, MPHASIS)에 검증을 요청하게 된다. 검증 기관에서는 검증 과정 완료 후, 심비안 사인드로 다시 보내고 심비안 사인드는 검증이 완료 되었다는 전자 서명을 한 뒤, 개발자에게 전자 서명이 완료된 응용프로그램을 전송하게 된다. 이러한 심비안 사인드 정책의 시행 이후, 상당수의 악성코드가 감소 하는 효과를 얻을 수 있었고, 현재도 시행 중이다. 또한 심비안 사인드 정책은 크게 4가지로 분류되는데, 코드 사이닝의 종류에 따라 사용 가능한 권한의 차등을 두고 있다. 심비안 사인에 따른 사용 가능한 권한 여부는 [표 2-2]와 같다

45 [표 2-2] 심비안 사인에 따른 사용 가능한 권한 여부 Process Open Signed Online Open Signed Offline Express Signed Certified Signed Status Account Publisher Independent IMEI Login ID Test House Restrictions required Available No No No Yes Available Yes Yes No Yes Available Yes Yes No No Available Yes Yes Yes No 각각의 사인 방법 및 특징에 대해 살펴보면 다음과 같다. (1) 오픈 온라인 사인 o 무료로 이용할 수 있으며 개인 IMEI를 이용해서 코드 사인을 수행함 o 이메일을 통해 제작한 어플리케이션 바이너리를 전송 o 이 후 사인된 어플리케이션 바이너리를 다운받을 수 있는 경로를 제 공 받음 (2) 오픈 오프라인 사인 o 오픈 온라인 사인보다 적은 권한이 부여됨 o 개발 툴에서 직접 사인 (3) 익스프레스 사인 o Publisher ID를 이용해서 SignSIS 혹인 MakeSIS 도구를 통한 어플리케 이션 사인 수행 후에 사인된 어플리케이션을 포탈(portal)로 보내 인

46 증을 요청 (4) 서티파이드(Certified) 사인 o 모든 권한을 부여 받음 o Publisher ID를 이용해서 SignSIS 혹은 MakeSIS 도구를 통한 어플리케 이션 사인 수행 후에 사인된 어플리케이션을 Test House로 보내 인 증 요청 제 4 절 블랙베리 OS 1. 정의 및 특징 블랙베리 OS는 캐나다 RIM(Research In Motion) 社 에서 개발한 비공 개 모바일 운영체제로 운영체제에 관한 자세한 스펙은 공개되어 있지 않 다. 블랙베리 OS는 (그림 2-11)과 같이 이메일, 주소록, 메신저 서비스 등 을 제공하고 이에 최적화 되어 있다. (그림 2-11) 블랙베리 OS 서비스 내용 2. 구조 및 보안 메커니즘

47 블랙베리 OS의 구조 및 내부적인 보안 메커니즘은 현재 비공개이며, 국내 블랙베리 스마트폰을 통한 보안 메커니즘만이 공개된 상태이다. 국 내 블랙베리 스마트폰을 통한 모든 통신은 (그림 2-12)와 같이 음성통화 는 SK텔레콤을 통해 이루어지며 데이터는 캐나다의 RIM의 인프라를 경 유하여 고객사의 블랙베리 및 이메일 시스템을 통해 전달된다. 모든 데이 터는 블랙베리 스마트폰과 서버 단에서 3DES 혹은 AES 모드의 암호화가 이루어진다는 특징이 있다. 또한 푸쉬(Push) 이메일 서비스라고 해서 블 랙베리 스마트폰 자체에 이메일 주소가 지정되어 있어, 블랙베리 사용자 간의 이메일을 주고받는 것이 편리하며 송수신되는 메일이 블랙베리 스 마트폰에 저장된다. (그림 2-12) 블랙베리를 이용한 Push mail 서비스 내용 제 5 절 윈도우 모바일 1. 정의 및 특징 윈도우 모바일은 마이크로소프트 社 에서 개발한 비공개 모바일 운영 체제로, 임베디드용 운영체제인 윈도우 CE를 기반으로 하고 있고, 윈도우

48 CE의 기본적인 기능에 휴대전화 기능이 추가되어 있는 형태로 구성이 된 다. 현재 버전 6.5까지 출시되었으며, 7 버전의 출시를 기다리고 있는 상 황이다. 2. 구조 및 보안 메커니즘 (그림 2-13) 윈도우 모바일 전체 구조 PC에서 사용 중인 Windows 운영체제를 기반으로 제작된 윈도우 CE 를 기반으로 하고 있으므로, 전체적인 구조는 Windows 운영체제와 유사 하다. (그림 2-13)과 같이 크게 User Space와 Kernel Space로 나누어져 있으며, User Space에서 Kernel Space로의 접근은 권한 명시가 없는 경우 에는 불가능 하도록 설계 되었다. 윈도우 모바일에도 퍼미션이 존재하는 데, 퍼미션은 (그림 2-14)와 같이 Privileged, Normal, Blocked의 세 가지 로 분류 된다

49 (그림 2-14) 윈도우 모바일 권한 체계 대다수의 운영체제에서 각각의 접근하는 리소스별로 다른 권한 체계 를 가지는 반면 윈도우 모바일은 복잡도를 줄이기 위한 구조를 가지고 있다. 각각에 대한 설명은 다음과 같다. 가. Privileged 모든 리소스에 대한 접근 권한을 가지며 미리 지정된 매우 적은 어 플리케이션만이 이 권한을 가질 수 있다. 모든 API에 대한 접근과 보호되 는 레지스트리에 쓰기 권한 또한 가지며, 시스템 파일에 쓰기 권한도 가 지고 있다. 즉, 시스템의 전권을 가지는 리눅스 시스템의 루트(root)와 유 사한 개념이라 할 수 있다. 나. Normal 대다수의 어플리케이션이 가지는 접근 권한이다. 어플리케이션마다 제한된 리소스의 접근이 가능하고, 시스템 파일에 직접적으로 접근하여 쓰기 권한 또한 없다. 즉, 시스템의 사용자인 리눅스 시스템의 유저(user) 와 유사한 개념이라 할 수 있다

50 다. Blocked 윈도우 모바일의 어느 리소스에 대해서도 접근 권한이 없는 퍼미션 을 의미한다. 어떠한 어플리케이션도 가질 수 없는 권한으로 실행 자체가 불가능한 퍼미션을 의미한다

51 - 31 -

52 제 3 장 모바일 OS 보안 취약점 조사 및 분석 대표적인 모바일 OS인 스마트폰 OS 환경에서 현재까지 공개된 OS 자체의 보안 취약점은 거의 존재하지 않는다. 발견된 악성코드의 경우에 도 OS 자체의 보안 취약점을 이용하는 것이 아닌 어플리케이션 개발을 위해 공개된 API를 사용하여 악성행위를 시도하는 것이 대부분이다. 블랙 베리 OS를 제외한 안드로이드, 아이폰 OS, 심비안, 윈도우 모바일의 경우 악성코드가 존재하고, 실제 이로 인한 피해사례도 생겨나고 있다. 본 장 에서는 각 OS 별로 현재까지 발견된 악성코드에 대한 내용과 추가로 발 견된 보안 취약점에 대해 설명할 것이다. 제 1 절 보안 취약점 및 악성코드 2004년 카비르(Cabir)라는 웜(Worm)이 최초 발견된 이후 지금까지 약 600 여종의 악성코드가 발견되었다. 발견된 악성코드 중 심비안을 대상으 로 하는 악성코드가 약 95%를 차지하며, 나머지 5%는 윈도우 모바일, 팜 OS 환경 등에서 동작한다. 각각의 스마트폰 OS 환경에서 발견된 악성코 드에 대해서 살펴보면 다음과 같다. 1. 심비안 심비안은 현재까지 가장 많은 악성코드가 발견되었다. 최초의 모바일 웜인 카비르를 포함하여 러시아에서는 스마트폰 웹 브라우저인 것처럼 가장해 특정인의 스마트폰에 침투해 불법 과금을 유도하는 레드 브라 우저(Red Browser) 라는 악성코드가 발견되었으며, 사용자의 스마트폰이 수신 및 발신하는 단문 문자 메시지 서비스(SMS)를 특정 번호로 전송하

53 는 올카노 가 발견되었다. (그림 3-1)와 같이 심비안에서 발견된 악성 코드는 원격제어, 정상 동작 방해, 개인정보 유출, 과금 유도, 유해 사이 트 접속과 같은 동작을 수행하여 피해를 발생시켰다. (그림 3-1) 심비안 악성코드 특징 심비안 악성코드가 대다수를 차지하는 데에는 심비안이 지니는 특징 을 악용하는 경우가 많으며, 다음과 같은 악성 행위를 한다는 특징이 있 다. 가. Overwriting ROM Applications 만약 C:\에 원본 Z:\에 있는 어플리케이션과 동일한 이름의 어플리케 이션이 있고 경로를 Z:\로 조작한다면 심비안은 Z:\의 어플리케이션을 실 행하는 대신에 C:\의 어플리케이션을 실행하게 된다. 이 취약점은 이미 수많은 웜 바이러스가 자신의 공격 코드를 먼저 실행시키키 위해 사용한 방법이다. 나. Extensive Set of APIs 심비안에서는 GUI, SMS, MMS, 블루투스(Bluetooth), 파일 시스템, 주 소록 등에 관련된 개발을 위해 많은 API를 제공하지만 웜 바이러스는 이 와 같은 API를 이용해서 오히려 공격 코드의 동작을 손쉽게 구현하게 된 다. 그 예로 카비르 웜 바이러스는 블루투스 API를 사용하여 공격코드를

54 다른 스마트폰으로 전파 하였다. 다. Tampering existing SIS files 웜 바이러스는 심비안에 존재하는 정상적인 SIS 파일을 찾아서 SIS 파일 내에 공격코드를 실행하는 SIS 파일을 삽입함으로써 악의적인 행동 을 감추는데 사용한다. 라. Autostart Capability 심비안에는 크게 5개의 파일 확장자를 지원한다. app는 어플리케이 션 메뉴에서 선택해서 실행할 수 있는 실질적인 어플리케이션을 의미하 며, exe는 GUI 어플리케이션에서 사용하는 유틸리티이다. mdl은 부팅 시 혹은 메모리 카드가 삽입 되었을 때 자동으로 실행하는 파일이다. rsc는 리소스 파일이며 gdr은 폰트이다. 웜 바이러스는 심비안 OS에 설치되는 악성코드를 포함하는.app와.exe를 포함해서.mdl로 등록한다. 이렇게 함으로써 스마트폰을 재부팅 하더라도 공격코드를 지속적으로 실행시킬 수 있다. 심비안에서 발견된 특징적인 악성코드에 대한 설명은 다음과 같다. (1) 컴워리어(CommWarrior) 컴워리어는 스마트폰 주소록의 전화번호로 MMS 메시지를 전송하는 최초의 스마트폰 웜 바이러스로 알려져 있으며 MMS 메시지를 무차별적 으로 전송하기 때문에 불법적인 과금을 발생시킨다. 또한 블루투스를 통 해 전파되며 감염 시에는 (그림 3-2)와 같은 메시지가 감염된 스마트폰 화면에 출력되면서 [표 3-1]과 같은 MMS 수신된다

55 (그림 3-2) 컴워리어 감염 화면 [표 3-1] 컴워리어가 전송하는 MMS 예제 Subject: Symbian security update Message: See security news at Subject: SymbianOS update Message: OS service pack #1 from Symbian inc. Subject: Virtual SEX Message: Virtual SEX mobile engine from Russian hackers! Subject: WWW Cracker Message: Helps to *CRACK* WWW sites like hotmail.com (2) 스컬러(Skuller) 스컬러는 말레이시아에서 처음 발견되어 현재 50여종의 변종이 발견 되었으며, 다른 어플리케이션 프로그램을 정지시키고 (그림 3-3)과 같이 프로그램의 아이콘을 고의적으로 조작하는 행위를 한다

56 (그림 3-3) 스컬러 감염 화면 (3) 카비르 (Cabir) 카비르는 29A라고 불리는 바이러스 제작 그룹에 의해 작성되었으며, SIS 파일 구조를 프로그래밍적으로 완성한 특징을 지니, 실제 카비르 웜 에 감염되면 피해를 발생하지 않으나 스마트폰 웜 바이러스 개발이 가능 함을 알리는 첫 번째 사례로써 매우 큰 의미를 가진다. 카비르는 스마트폰의 블루투스 기능을 이용해서 스캐닝 작업을 통해 블루투스 기능이 활성화 된 스마트폰을 탐색한 후 웜 바이러스 코드가 담긴 SIS 파일을 전송해서 강제로 설치를 시도한다. 카비르 웜 바이러스 에 감염된 결과는 (그림 3-4)와 같다

57 (그림 3-4) 카비르 웜 바이러스 감염 화면 카비르는 만약 블루투스 스캐닝(Scanning) 결과 주변에 블루투스 기 능이 켜진 심비안이 탑재된 스마트폰이 존재할 경우 해당 주소로 OBEX Object Push 프로파일을 이용해서 파일을 전송하는 기능을 수행한다. 이 와 같이 타겟 스마트폰을 감염시키는 블루투스 공격은 지금까지의 스마 트폰 웜 바이러스가 지니는 가장 대표적인 특징이다. (4) Sexy View Sexy View 악성코드는 최근 심비안 오픈마켓으로부터 사인을 받은 사실로 이슈화 되었다. 심비안 오픈마켓에서는 시그니처 기반의 안티 바 이러스(Anti Virus)에 의해 1차적인 검증이 이루어지고, 이 후 랜덤하게 선택된 어플리케이션이 관리자에 의해 2차적인 보안 검증이 이루어진 후 위험성이 존재하지 않을 경우 사인된다. 따라서 시그니처가 등록되어 있 지 않고 랜덤하게 선택되지 않을 경우 이와 같이 악성코드가 사인을 받 는 경우가 발생될 수 있다. Sexy View 악성코드는 Sexy Space 악성코드의 변종으로 가장 큰 특 징은 SMS를 통해 전파된다는 것이다. 감겸된 스마트폰의 주소록에 등록 된 모든 사용자들에게 SMS 문자를 보내서 성인물로 가장된 악성코드 URL 경로를 보내게 되며, 이를 수신한 사용자들이 해당 경로를 클릭한

58 후 설치에 동의할 경우 감염된다. 2. 아이폰 OS 아이폰은 심비안과 같이 다수의 악성코드가 보고되지는 않았으나, (그림 3-5)와 같이 2007년 이후로 다양한 보안 문제가 제기되어 왔다. (그림 3-5) 아이폰 보안 문제 타임라인 아이폰 보안의 문제는 크게 Root exploits, Personal data harvesting, Worms 의 세 가지로 나누어진다. 각각에 대해 살펴보면 다음과 같다. 가. Root Exploits (1) Libtiff 2007년 7월에 발견 되었으며, TIFF(Tagged Image File Format) 파일 을 읽고 쓰기 위한 라이브러리인 Libtiff에 문제가 있음이 지적되었다. Tavis Ormandy가 애플의 ImageIO 프레임워크를 사용하는 Libtiff 버전에

59 서의 다양한 BOF(Buffer Over Flow) 취약점을 발견하고, 이를 발표하였 다. 그 뒤를 이어 Rik Farrow가 조작된 TIFF 이미지를 읽는 것만으로 숨 겨진 코드를 실행할 수 있음을 시연하여 널리 알려지게 되었다. 이 후 아 이폰 OS 버전으로 업데이트 되면서 패치가 이루어졌다. (2) SMS fuzzing 2009년 7월에 발견 되었으며, 조작된 SMS를 통한 문제가 있음이 지 적되었다. Charlie Miller와 Collin Mulliner가 블랙햇 USA 2009에서 발표 및 시연을 하면서 알려지게 되었다. 이 후 아이폰 OS 버전에서 패 치가 이루어졌다. 나. Personal data harvesting Personal data harvesting은 크게 Pulled out from AppStore, Lawsuits, Analytics의 세 가지로 분류된다. 각가에 대해 살펴보면 다음과 같다. (1) Pulled out from AppStore (가) Aurora Feint 2008년 7월에 발견되었으며, 아이폰 용 게임 어플리케이션인 Aurora Feint에서 문제가 지적되었다. 이 Aurora Feint 어플리케이션은 동작하면 서 임의로 아이폰 내에 저장된 주소록을 개발자의 서버로 전송하도록 하 였다. 이 점이 문제가 되어 앱스토어에서 퇴출되었다. 이에 따라 Aurora Feint는 내부 정보 유출 문제로 인하여 앱스토어에서 퇴출된 최초의 어플 리케이션으로 기록되었다. (나) MogoRoad 2009년 9월에 발견 되었으며, MogoRoad라는 스위스 도로 교통 어플

60 리케이션에서 문제가 지적 되었다. MogoRoad 어플리케이션은 임의로 어 플리케이션이 설치된 아이폰의 전화번호를 유출하여, 이를 회사 측에 판 매를 통해 금전적인 수익을 얻었고, 회사 측은 획득한 전화번호로 스팸 전화 및 문자를 발송하여 사용자들에게 피해를 입혔다. 이 후, 이 어플리 케이션은 앱스토어에서 퇴출되었다. (2) Lawsuits (가) Storm8 2009년 11월에 발생한 사건으로 캘리포니아 법정이 아이폰 게임 제 작자였던 Storm8을 고소하였다. 이유는 Storm8이 제작한 게임이 암호화 과정 없이 설치된 사용자의 휴대폰 번호를 무단으로 수집하도록 작동하 여 프라이버시 침해의 문제가 있다고 판단하였기 때문이다. 이 후 Storm8 은 법적인 제제를 받게 되었다. (3) Analytics (가) PinchMedia Concerns 2009년 7월에 제기된 문제로, 많은 아이폰 개발자들이 사용하는 무료 분석 프레임워크인 PinchMedia에 대한 내용이다. PinchMedia는 분석을 통 해 다양한 정보를 수집하게 되는데, 이러한 PinchMedia로 인한 사용자의 프라이버시 침해 가능성이 주장되었다. 실제로 PinchMedia는 다음과 같은 정보를 수집한다. A unique hardware identifier The model of your phone and OS The applications name and version The result of a check to see if the device has been jailbroken The result of a check to see if the application has been stolen

61 The length of time the application was run If the user explicitly agrees to share it, the user's location If the application uses Facebook Connect, the gender & age of the user 다. Worms 아이폰 OS 환경에서의 웜 바이러스는 탈옥(Jailbreaking) 환경에서만 동작할 수 있다. 탈옥이란 아이폰 OS에서 사용자가 임의로 실행이 불가 능하도록 인가된 기능을 펌웨어(Firmware)의 수정을 통해 기기에서 사용 가능하도록 허용하는 것을 의미한다. 탈옥을 수행하면 애플의 앱스토어 이외에 Cydia store와 같은 오픈마켓에서 크랙(Crack)된 버전의 어플리케 이션의 다운로드가 자유롭게 되고, 4.0 이전의 OS 버전에서도 멀티 태스 킹이 가능해진다는 장점을 가지고 있다. 현재까지 전 세계 아이폰과 아이 팟 터치 제품의 8.5%가 탈옥된 제품으로 예측이 되고 있다. (Jay Freeman, Cydia 설립자) 이러한 탈옥은 2007년 7월 10일 iphone Dev Team에 의해 최초로 수 행되었다. iphone Dev Team은 당시에 사용자가 임의로 제작한 벨소리를 아이폰에서 사용하기 위하여 이러한 탈옥을 시도하였다. 이 후 애플의 폐 쇄적인 정책에 반발하여 탈옥은 지속적으로 이루어졌으며, 이러한 영향을 받아 애플도 펌웨어의 버전 업을 하면서 기능을 점차 개방하였다. 이렇게 탈옥된 환경에서는 제한되었던 자유로운 멀티태스킹이 가능 해지면서 백그라운드 작업이 가능해진다. 이를 이용하여 아이폰 OS 환경 에서도 악성코드가 동작 가능해졌고 실제로도 발견되었다. 각각의 악성코 드에 대해 살펴보면 다음과 같다. (1) ikee 2009년 11월에 발견된 최초의 웜 바이러스로, 호주에서 발견되었다

62 탈옥 후 설치하는 프로그램 중 Open SSH와 MobileTerminal과 같은 어플 리케이션 설치 후, 기본 패스워드를 변경하지 않는 취약점을 이용하여 공 격했다. 현재까지 ikee 웜 바이러스가 최초 발견된 후, ikee.b 변경 웜 바 이러스가 발견되었고, 이 후 ikee.d, POC-BBOT 웜 바이러스가 발견된 상 태이다. 최초에 발견된 ikee 웜 바이러스의 경우 정확하게 말하자면 ikee 웜 바이러스 C 형으로 분류되며, cydia의 파일 경로와 혼동하게끔 유사한 파 일 경로를 가진 ikee 웜 바이러스 D형이 잇따라 나왔다. 이 C형과 D형의 제작자 ikex는 애플 社 의 아이폰 보안 취약점을 드러내기 위해 악성코드 를 제작했다고 발표하였다. ikee 웜의 경우 원래는 클로즈드(closed) 소스였지만, 오픈 소스 형태 로 소스가 공개됨으로 인해 현재 해커들에게도 모두 공개된 상태이다. 이 후, 이에 대한 소스 코드를 분석한 해커들이 ikee.b 형 웜 바이러스를 만 들어 내게 되었다. 현재 알려진 바로는 해커들이 제작한 ikee.b 바이러스 는 초기의 C형을 개조한 것이라고 한다. ikee 웜 바이러스에 대한 증상은 다음과 같다. (가) ikee (ikee 웜 바이러스 C형) Ikee는 감염되면 (그림 3-6)과 같이 바탕화면을 80년대 인기 가수 Rick Astley의 사진으로 변경하고 ikee is never going to give you up 이라는 문구를 출력하도록 하였다. 즉, 아이키는 절대 너를 포기하지 않을 것이다 라는 뜻으로 2차 공격을 암시하도록 하였으며, 실제로 그 후에 D형이 배포되기도 했다

63 (그림 3-6) Ikee 웜 바이러스 감염 화면 (나) ikee 웜 바이러스 D형 C형과 동일한 증상으로 추정되며, C형과는 달리 D형에 대한 자료는 거의 없다. C형과의 차이점은 시디아(Cydia) 파일 경로와 웜의 파일 경로 를 유사하게 설정하여 눈속임을 한 정도이다. (다) Duh/iKee.B (ikee 웜 바이러스 B형) Duh/ikee.B는 네덜란드 해커들에 의해 제작되었다. 이는 (그림 3-7)과 같이 Dutch ING online banking 정보를 대상으로 하여 ING 사이트를 공 격자가 제작한 카피캣(Copycat) 사이트로 이동하게 하여 수집된 정보를 원격 서버로 전송하도록 하였다. C형의 접속 방식을 모방 하였으며, C형 과는 달리 바탕화면을 바꾸지 않는다. 동작은 수퍼바이저(Supervisor) 루 트의 비밀번호를 탈옥 후 ssh 접속을 위한 기본 비밀번호인 alpine 을 ohshit 으로 바꾸며, PC 기반의 봇넷(botnet)을 이용하여 정보를 수집 후 리투아니아에 있는 의 중앙서버로 전송된다.전송되는 정보로는 몇몇 은행의 SMS 기반 승인코드, 폰번호 등(추정)이다

64 (그림 3-7) Duh/Ikee.b에 대한 신문기사 실험적인 웜 바이러스로 사용자에게 별다른 피해를 주지 않았던 ikee C형과 D형과는 다르게 사용자에게 직접적인 피해를 주는 웜 바이러스이 다. 정보 유출 이외에 이는 실시간으로 SMS를 감시하기 때문에 시스템에 서 메모리 점유율이 높다. 그 외에 인터넷을 작동시키면 가짜 웹 사이트 를 띄워 개인정보를 입력하게 한다는 설이 있지만, 이는 전문 보안업체의 랩(lab)에서는 언급되지 않았다. (2) Dutch 5 ransom 네덜란드에서 발견된 웜 바이러스로, 사용자가 5 를 해커의 페이팔 (Paypal)로 지불하기 전까지 (그림 3-8)과 같이 스크린을 잠그고, Your iphone's been hacked because it's really insecure! Please visit doiop.com/ihacked and secure your iphone right now!" 메시지를 출력하 도록 하였다

65 (그림 3-8) Dutch 5 ransom 감염 화면 (3) iphone/privacy.a 네덜란드에서 발견된 웜 바이러스로, (그림 3-9)와 같이 숨겨진 상태 로 개인 정보를 수집하고 이를 유출하여 사용자로 하여금 실질적인 피해 를 받도록 하였다. (그림 3-9) Iphone/Privacy.A 감염 화면 또한 2010년 3월에는 아이폰 용 웹 브라우저인 모바일 사파리의 취

66 약점이 공개되었다. 이는 (그림 3-10)과 같이 BOF와 DoS(Denial of Service) 공격이 가능하다고 알려져 있으며, 현재는 DoS 공격만을 위한 소스코드가 공개되어 있다. (그림 3-10) 모바일 사파리를 통한 공격에 대한 소개 공개된 소스코드를 이용한 사파리 브라우저를 통한 아이폰 DoS 공격 은 (그림 3-11)과 같은 방법으로 수행된다. (그림 3-11) 사파리 브라우저를 통한 아이폰 DoS 공격

67 (가) 공격을 위한 가상의 웹 페이지를 제작한다. 이 때, 자바스크립트 코 드를 사용하면서 공격 코드를 삽입하여 제작한다. (나) 아이폰에 내장된 사파리 브라우저를 통해 공격자가 제작한 웹 페이 지에 접근한다. (다) 웹 페이지 접근 시 공격 코드가 수행되면서, 아이폰에 DoS 공격을 시도한다. 아이폰 사파리 브라우저는 웹킷(Web-Kit) 기반의 브라우저로 웹킷 기반의 기본 브라우저를 사용하는 안드로이드 환경에서 테스트 시에도 동일한 취약점이 발견 되었고, 이와는 다르게 웹킷 기반의 웹 브라우저가 아닌 윈도우 모바일의 모바일 익스플로러 브라우저의 경우에는 해당되지 않았다. 웹킷 기반의 웹 브라우저를 통하는 경우 이와 같은 문제가 발생 하는 이유는 자바스크립트 코드를 읽어 들여 그 내용을 웹 브라우저가 파싱(Parsing) 하는 과정에서 제대로 처리하지 못하여 발생하는 문제로 분석 되었다. 이처럼 기존에 등장했던 악성코드와는 달리 웹 브라우저를 통해 공 격을 시도하는 방법의 경우, 단순 어플리케이션 레벨에서 동작하는 것이 아닌 보안 샌드박스의 우회를 통해 공격을 시도하게 된다. 이러한 경우 어플리케이션 상에서 동작하는 악성코드 탐지를 위한 백신을 무효화 시 키고, 실제 시스템 파일에 접근이 가능하게 되어 더욱 더 큰 보안 문제를 야기할 수 있다. 실제로 2010년 8월에는 이러한 모바일 웹의 취약점을 이용하여 탈옥 을 시도하는 탈옥툴인 JailbreakMe 2.0 'star'가 공개되었다. 7월 말 미국 정부가 아이폰 탈옥에 대해서 불법으로는 볼 수 없다고 발표한 뒤에 공 개된 것이라 사람들의 주목을 받았다. 해당 툴은 아이폰 OS 4.X, 3.X 버 전을 설치한 아이패드, 아이폰4, 아이폰 3GS, 3G와 같은 모든 단말기에서 사용할 수 있다

68 이번에 공개된 탈옥툴은 지난 탈옥 방식들과는 달리 아이폰의 웹 브 라우저인 모바일 사파리(Safari) 브라우저로 JailbreakMe 사이트 ( 접속하는 것으로 간단히 탈옥이 가능하다. (그림 3-12)는 모바일 사파리 브라우저를 이용해서 JailbreakMe 사이 트에 접속한 화면이다. 이 화면에서 슬라이드를 오른쪽으로 밀면 탈옥이 시작된다. (그림 3-12) JailbreakMe star 화면 탈옥이 시작되면 (그림 3-13)과 같은 화면이 출력되면서 탈옥을 수행 한다. 탈옥이 완료되면 이전의 탈옥 환경과 마찬가지로 Cydia 어플리케이 션이 설치된다

69 (그림 3-13) 탈옥 진행 화면 JailbreakMe 사이트는 USER-AGENT 값을 확인하여 모바일 사파리 브라우저로 접속하였는지 확인하고, (그림 3-14)와 같은 자바스크립트를 통해서 각각의 아이폰, 아이팟, 아이패드 펌웨어 버전에 해당하는 PDF 파일로 이동한다. (그림 3-14) JailbreakMe 리다이렉트 소스 코드 실제로 접속하여 확인하면 (그림 3-15) 와 같이 펌웨어 버전 별로 만들어진 PDF 파일을 확인할 수 있다

70 (그림 3-15) 아이폰 탈옥에 사용되는 PDF 파일 이번에 탈옥에 사용된 방법은 FreeType2 폰트 엔진이 PDF 내부에 포함되어 있는 CFF 폰트를 처리하는 과정에서 발생하는 취약점과 IOSurface 속성 처리과정에서 발생하는 두 가지 취약점을 이용한다. 탈옥에 사용되는 iphone3.1_4.0.pdf 파일을 대상으로 관련된 내용 을 살펴보면 (그림 3-16)과 같다. 인코딩된 CFF 폰트(Type1C) 스트림은 PDF 파일 내부의 13번째 오브젝트에 위치해 있다. (그림 3-16) PDF 내부에 인코딩되어 포함된 CFF폰트

71 이러한 아이폰 환경에서의 PDF 파일 취약점은 사용자에게 피해를 주는 악성코드의 형태로 악용될 가능성이 높다. 실제로 이를 분석한 내용 은 다음과 같다. 먼저 (그림 3-17)과 같이 PDF 파일의 13번째 오브젝트를 PDF 파서를 사용하여 디코딩을 수행한다. (그림 3-17) PDF 파서를 사용한 디코딩 결과 화면 디코딩 된 데이터에서 탈옥과 관련된 많은 정보를 얻을 수 있다. 또 한 (그림 3-18)과 같은 화면에서 탈옥 진행에 필요한 wad.bin 파일과 탈 옥과 관련된 문자열들을 발견할 수 있다. (그림 3-18) 디코딩 된 데이터 내용

72 이외에도 (그림 3-19)와 같이 IOSurfaceBytesPerRow, IOSurfacePixelFormat, IOSurfaceHeight, IOSurfaceWidth 설정 값들이 비정 상적으로 크게 설정되어 있음을 확인할 수 있다. (그림 3-19) IOSurface의 비정상적인 설정 값 해당 취약점을 이용하여 악성코드 제작자는 (그림 3-20)과 같이 악의 적인 PDF 파일을 제작하고, 이를 메일에 첨부하여 발송하거나 SMS 메시 지의 링크를 통해 사용자에게 악성 PDF 파일을 실행하도록 유도할 수 있다

73 (그림 3-20) 이메일을 이용한 악성 PDF 유 포 이외에도 (그림 3-21)와 같이 트위터와 같은 SNS(Social Network Service)에 악성 PDF 파일로 연결되는 단축 URL을 남기는 등의 사회 공 학적인 방법을 이용해 사용자의 접속을 유도할 수 있다. (그림 3-21) 트위터를 이용한 악성 PDF 유포 2010년 8월 11일 애플 社 에서는 PDF 파일을 열어볼 때, 발생할 수 있는 보안상의 문제점을 해결한 아이폰 OS 버전을 발표하였다. 사 용자들은 아이튠즈 업데이트 기능을 이용해 업데이트 받아 보안 취약점 에 대한 패치가 가능하도록 하였다

74 이러한 PDF 취약점을 이용한 탈옥 툴을 개발한 데브팀의 Comex는 (그림 3-22)와 같이 이번 아이폰 탈옥 소스파일을 자신의 트위터를 통해 공개했다. (그림 3-22) 데브팀 Comex의 트위터 탈옥툴을 개발한 Comex는 탈옥한 아이폰에서 플래쉬(Flash)를 사용 할 수 있도록 만들어주는 (그림 3-23)과 같은 프레쉬(Frash)라는 어플리케 이션도 개발했다. 모바일 사파리 브라우저는 플래쉬를 사용할 수 없지만, 안드로이드용 플래쉬 플레이어를 아이폰 OS에 맞게 포팅하여 사용할 수 있게 만들었다. (그림 3-23) Frash 어플리케이션

75 아직까지 해당 PDF 취약점을 이용한 악성코드의 유포 사례는 발견 되지 않았다. 하지만, 실제 소스 코드 공개 후 다양한 변종을 만들어 냈 던 ikee 웜 바이러스처럼, 탈옥툴을 개발한 Comex가 소스파일을 공개 하여 이를 악용한 또 다른 공격이 우려되고 있다. 3. 안드로이드 및 윈도우 모바일 안드로이드는 실제 안드로이드 OS를 탑재한 스마트폰 보급률이 현재 까지는 타 OS 기반의 스마트폰에 비해 낮아 악성코드의 발견 사례가 보 고되고 있지 않다. 하지만 2009년 구글 정식 앱스토어인 구글 마켓 (Google market)을 통해 악성코드가 배포되는 사례가 발생하여 보안에 대 한 문제점이 지적되었다. 이 사례는 09Droid라는 개발자가 다수의 모바일 뱅킹 프로그램으로 위장된 어플리케이션을 업로드 하고 이를 사용자들이 다운로드 받아 정보가 유출되는 문제가 발생하였다. 업로드 된 어플리케 이션은 (그림 3-24)와 같이 정상적인 모바일 뱅킹 프로그램으로 위장하여 백그라운드 작업을 통해 사용자의 개인 정보와 계좌 정보를 수집하도록 동작하였다. (그림 3-24) 안드로이드 악성코드

76 또한 최근에는 안드로이드 스마트폰 유저들의 대부분이 사용하고 있 는 Wallpaper 의 제작자 by Jackeey Wallpaer 의 어플이 중국에 서버를 두고 사용자들의 개인 정보를 빼가하는 스파이웨어라고 밝혀졌다. by Jackeey Wallpaper' 어플리케이션을 설치하게 되면 핸드폰에 저장된 전화번호와 메일, 비밀번호, 검색기록, 문자 메시지, 심지어는 USIM 칩에 심어진 정보까지도 빼내어, 중국 서버에 설치된 웹사이트 ' 로 데이터를 전송하도록 동작하였다. 이 후, 이러한 어플리케이션들은 구글 마켓에서 퇴출 되었으나, 구글 에서 적극적으로 이에 대한 방지 대책을 세우지 않아 앞으로도 이러한 사고가 발생할 여지를 남겨두었다. 윈도우 모바일 환경에서의 악성코드는 현재까지 다수가 발견 되었으 나, 국내에는 발견된 사례가 존재하지 않았다. 하지만 2010년 4월 국제전 화를 무단으로 발신하는 악성코드가 국내에서 처음으로 발견되었다. 이 악성코드는 운영 프로그램의 보안 취약점을 이용하여, (그림 3-25)와 같 이 3D 안티 테러리스트 액션 이라는 스마트폰 게임에 국제전화를 무 단으로 발신하는 악성코드가 포함되어 동작하도록 하였다. 이 악성코드가 동작하면 해외의 Premium-rate number에 국제 전화를 시도하여 과금이 부가 되도록 하였다. (그림 3-25) 윈도우 모바일 악성코드

77 - 57 -

78 제 4 장 안드로이드 악성코드 분석 도구 기존에 출시된 안티 바이러스 제품들의 경우, 시그니처 수집을 통해 시그니처 값을 비교하여 악성코드를 탐지하는 시그니처 기반의 탐지 방 법을 사용 중이다. 이러한 시그니처 기반의 탐지 방법은 알려지지 않은 새로운 악성코드나 기존의 악성코드에 약간의 수정을 가한 변종 악성코 드의 경우도 탐지가 불가능하다는 문제점이 존재한다. 이를 보완하기 위 하여 (그림 4-1)과 같이 특정 API의 사용에 대한 모니터링을 통해 악성행 위 여부를 판단하는 행위 기반 탐지를 수행하는 분석도구를 필요로 한다. (그림 4-1) API 탐지를 통한 행위 기반 분석 방법 안드로이드 운영체제에서 사용되는 다양한 API 중 프로그램에서 사 용 시 문제가 되는 정보 유출 API는 크게 15개 정도이고, 이러한 API 목 록과 그에 대한 설명은 [표 4-1]과 같다

79 [표 4-1] 정보 유출 API 목록 API getdeviceid getsubscriverid OpenFileOutput openfileinput iswifienabled getlatitude, getlongitude getcontentresolver openconnection setrequestmethod sendtextmessage getmessagebody setlatesteventinfo getintalledapplications Build$VERSION.RELEASE Build.MODEL 설명 IMEI(기기 고유 번호) 값을 가져옴 IMSI(가입자 식별 번호) 값을 가져옴 파일을 열고 쓰는 함수 파일을 열고 읽는 함수 현재 기기가 Wi-Fi에 접속되어 있는지 확인 GPS 정보를 가져오는 함수 컨텐트 프로바이더 접근관련 함수 인터넷 연결 요청 함수 인터넷에 연결 요청 시, 어떠한 방식을 사용할지 설정하는 함수 SMS 전송을 수행하는 함수 저장된 SMS를 읽어오는 함수 Notification 쓰기 함수 현재 스마트폰에 설치된 어플리케이션 확인 제품의 버전 정보를 추출하는 함수 제품의 모델명을 추출하는 함수

80 악성코드 행위기반 탐지를 위해서는 실제 어플리케이션 코드 분석 과정을 필요로 하고 분석 과정은 크게 정적 분석과 동적 분석으로 나뉜 다. 정적 분석 방법이란 실제로 어플리케이션을 실행해보지 않고 실행 파 일을 직접 분석하는 방법으로 분석 가능한 소스코드가 존재하는 경우에 가능한 방법이다. 정적 분석을 수행하면 프로그램이 구현된 코드의 전체 적인 관계 파악이 가능하다는 장점이 존재한다. 그리고 동적 분석 방법이 란 어플리케이션을 실제로 실행하여 어플리케이션을 분석하는 방법으로, 코드 커버리지(Code Coverage) 측정이 가능하다는 장점을 가진다. 코드 커버리지에 대한 자세한 설명은 제 2 절 동적 분석 도구에서 다루어진다. 실제 어플리케이션 분석을 위해서는 각각의 장단점을 지니는 정적 및 동적 분석 과정을 모두 거쳐야만 악성코드 여부를 판단할 수 있기 때 문에 두 가지 분석 과정을 모두 필요로 한다. 또한 최근 안드로이드 스마트폰 사용자들이 행하는 루팅(Rooting)된 환경의 경우 시스템 레벨에서 동작하는 악성코드 제작이 가능한데, 기존 에 알려진 시그니처 기반의 악성코드 탐지 혹은 행위기반 탐지 방법으로 는 이러한 악성코드에 대한 탐지가 불가능하다. 따라서 루팅된 환경에서 의 악성코드 탐지를 위해서는 시스템 분석 도구 또한 필요하다. 본 장에서는 안드로이드 기반의 악성코드 탐지를 위한 정적 및 동적 분석 도구 개발 및 파일 시스템 분석 도구에 대해 설명한다. 제 1 절 정적 분석 도구 1. 배경 지식 가. 달빅 가상 머신 (Dalvik Virtual Machine) 달빅 가상 머신은 레지스터 머신 형태의 가상 머신이다. 댄 본스타인 이 다른 구글 엔지니어들의 도움 하에 설계/구현하였고, 현재 안드로이드

81 휴대 전화 플랫폼에 탑재된다. 달빅 가상 머신은 적은 메모리 요구 사양 에 최적화 되어 있다. 밑에 깔린 프로세스 아이솔레이션(process isolation), 메모리 관리, 스레딩 지원 등 운영체제의 지원에 의존하나 여 러 개의 달빅 VM 인스턴스가 동시에 돌 수 있다. 안드로이드에 설치되는 어플리케이션은 커널 레벨이 아닌 이 달빅 가상 머신 상에서 구동되며,.dex라는 파일 형태로 구동된다. 나. APK 파일 정의 및 어플리케이션 설치 과정 APK 파일이란 안드로이드 패키지 파일로 안드로이드 플랫폼에 어플 리케이션을 설치 시 사용하게 된다. APK 파일은 압축 파일 형태로 존재 하며, 일반적으로 권한 명시를 위한 AndroidManifest.xml 파일과 실제적인 실행 파일인.dex 파일, 그 외에 리소스 파일인 resource.arsc, res(folder), META-INF(folder)로 구성된다

82 (그림 4-2) 안드로이드 어플리케이션 설치 과정 (그림 4-2)와 같이 먼저 안드로이드 어플리케이션 개발 환경을 통하 여 APK 파일을 생성하고, 이를 안드로이드 환경에 설치하면 압축이 풀리 게 된다. 이 중 실제 실행 파일인.dex 파일이 안드로이드 어플리케이션 동작을 위한 가상 머신인 달빅 VM(Virtual Machine)에서 동작하게 된다. 2. 전체 분석 과정 악성코드는 디바이스에 설치되어야만 동작을 수행한다. 따라서 일반 적으로 설치파일 내부에 존재하며, 설치 시 악성행위를 수행하게 된다. 안드로이드 환경에서는 안드로이드 패키지 파일인 APK가 설치 역할을 수행하게 된다. 따라서 악성코드 분석을 위하여 설치 파일인 APK 파일의 분석을 (그림 4-3)과 같이 시도하였다

83 (그림 4-3) 전체 분석 과정 단계 APK 파일은 압축된 형태의 파일로 이를 해제하여, 실제 실행파일인 DEX 파일을 추출할 수 있다. 추출된 DEX 파일의 분석을 위해 크게 디컴 파일(Decompile)하는 방법과 디스어셈블(Disassemble)하는 방법이 존재하 는데, 분석 방법에 따라 서로 다른 분석도구와 과정을 통하여 분석을 수 행하게 된다. 가. DEX 디컴파일을 이용한 분석 방법 DEX 디컴파일을 이용한 분석 방법은 APK 파일로부터 추출된 DEX 파일을 디컴파일 도구를 이용하여,.jar 파일을 생성하고 이를 다시 디스 어셈블 및 디컴파일 과정을 통하여 프로그램에 사용된 API를 추출하는 방법이다. 과정은 다음과 같다. (1) undx 도구를 이용하여 디컴파일을 수행

84 (그림 4-4) undx 동작 과정 undx 도구는 (그림 4-4)와 같이 DEX 파일을 이전 압축파일 형태인.class/.jar 파일로 복구시켜주는 역할을 한다. undx를 이용하여 (그림 4-5) 와 같이 APK 파일로부터 추출된 DEX 파일을 다시 압축파일의 형태인.jar 파일로 복구를 수행한다. (그림 4-5) undx 사용을 통한.jar 파일 획득 과정 (2) 애플릿 구성 요소가 복구된.jar 파일을 획득 undx 도구를 이용하면 결과물로.jar 형태의 파일을 획득할 수 있다. JAR 파일이란 (그림 4-6)과 같이 압축 파일 포맷(ZIP)을 가지는 파일로, 애플릿을 구성하는 모든 클래스 파일과 데이터 파일을 포함한다. 실제 분 석 과정에서 undx 도구를 사용하여 DEX 파일을 JAR 파일의 형태로 복 구 하였는데, 이는 JAR 파일이 클래스 정보와 여러 데이터 등 많은 정보 를 담고 있어, 행위 기반 탐지 시 필요한 API의 추출이 용이할 것이라 판단했기 때문이다

85 (그림 4-6) JAR 파일 내용 및 파일 포맷 (3) JAR 파일 분석 이전 과정에서 복구된 JAR 파일의 분석을 수행한다. 분석에는 디스 어셈블과 디컴파일 과정을 모두 거친다. 순서는 디스어셈블러를 통한 분 석을 먼저 시도하고 이후 디컴파일러를 통한 분석을 시도하였다. 분석에 사용된 도구는 다음과 같다. (가) 디스어셈블러 1) IDA Pro IDA Pro는 가장 유명한 분석 도구로서, 역공학을 수행하는 분석가들 에게 널리 사용되고 있다. 다른 도구들과 달리 윈도우의 PE, Mac OS X Mach-O, Linux ELF 실행파일과 같이 서로 다른 프로세서와 운영체제의 실행파일 분석을 지원하고, Java 환경에서 사용되는.jar/.class 파일 또한 분석이 가능하다. 실제로 (그림 4-7)과 같이 이전 과정에서 얻어진 JAR 파일을 디스어셈블 된 코드로의 분석이 가능하다. 현재 5.6버전까지 출시 되어 있으며, 유료로 배포되고 있다

86 (그림 4-7) IDA Pro를 이용한 JAR 파일 디스어셈블 2) jaranalyzer JarAnalyzer는 JAR 파일에 포함되어 있는 라이브러리들을 분석해 주 는 도구로 바이너리 분석이 아닌 단순 라이브러리만의 출력이 필요한 경 우 매우 유용한 도구이다. jaranalyzer를 이용하면 (그림 4-8)과 같이 JAR 파일을 분석하여 프로그램에 실제 사용된 패키지 및 라이브러리의 확인 이 별다른 파싱 과정 없이 바로 확인이 가능하다. 현재 무료로 배포 중이 다

87 (그림 4-8) JarAnalyzer를 이용한 JAR 파일 디스어셈블 3) JReversePRO Jreverse PRO는 자바 언어로 쓰여진 모든 프로그램에 대상으로 하는 디컴파일러/디스어셈블러이다. (그림 4-9)와 같은 실행화면을 가지고, 100% 자바 언어로 쓰여진 프로그램이라면,.class파일의 디스어셈블을 통 해 (그림 4-10)과 같은 거의 완벽한 형태의 JVM(Java Virtual Machine) 바 이트 코드를 생성하는 것이 가능하고 현재 무료로 배포 중이다. (그림 4-9) JReversePRO 실행 화면

88 (그림 4-10) JReversePRO 도구를 이용한 디스어셈블 결과 화면 (나) 디컴파일러 1) Java Decompiler Java Decompiler는 자바 언어의 압축파일 형태인.jar/.class 파일에서 실제 구현된 자바 코드와 유사한 형태의 바이트 코드를 생성하는 도구이 다. 이를 이용하여 (그림 4-11)과 같은 결과를 얻어낼 수 있다. 현재 무료 로 배포 중이다. (그림 4-11) Java Decompiler 도구를 이용한 디컴파일 결과 화면

89 이와 같은 분석도구를 이용한 분석 결과로, 프로그램에 사용된 (그림 4-12)와 같은 함수 목록과 (그림 4-13)과 같은 라이브러리를 확인할 수 있다. (그림 12) 함수 목록 분석 결과 (그림 4-13) 라이브러리 목록 분석 결과 이와 같이 DEX 디컴파일을 통한 분석 과정은 바이너리 코드를 추출

90 해내는 디스어셈블 과정에 비해 가독성 면에서 뛰어나고, 만족스러운 결 과를 보여주었다. 하지만 이 방법에는 한 가지 문제점이 존재했다. 바로 JAR 파일로 디컴파일 시 일부 코드들이 누락되는 경우가 발생하는 문제 였다. 이유는 undx 도구를 통하여 디컴파일을 수행할 때에, undx 도구는 DEX 파일을 완벽한 JAR 파일로 복구 하지 못했기 때문이다. 따라서 이 러한 문제를 해결하기 위해 DEX를 디스어셈블을 통한 분석을 시도하였 다. 나. DEX 디스어셈블을 통한 분석 과정 DEX 디스어셈블을 통한 분석 과정은 DEX 파일을 도구를 통해 디스 어셈블을 수행하여, 그 결과 얻어진 바이너리 코드의 분석 작업을 통하여 프로그램에 사용된 API를 추출하는 방법이다. 과정은 다음과 같다. (1) 도구를 이용한 디스어셈블 수행 디스어셈블러를 이용하여 분석할 APK 파일로부터 추출된 DEX 파일 에 대하여, 디스어셈블을 수행한다. 이 방법은 DEX 파일의 디컴파일을 통하여 분석하는 방법과는 달리, DEX 파일을 직접 디스어셈블 하고 이를 분석하기 때문에 분석 과정의 간소화와 디컴파일 과정 부재로 인하여 코 드의 누락이 최소화 된다는 장점이 존재한다. DEX 디스어셈블을 위해 사용되는 디스어셈블러는 smali 혹은 Dedexer 가 존재한다. 각각의 도구에 대하여 살펴보면 다음과 같다. (가) 디스어셈블러 1) smali smali와 baksmali는 달빅 VM에서 사용되는 DEX 파일에 대해 각각

91 어셈블러(assembler)와 디스어셈블러(disassembler)의 역할을 수행하는 도 구이다. smali를 실행하면, (그림 4-14)와 같이 어셈블리어와 유사한 형태 의 코드로 분석 결과를 보여준다. 현재 무료로 배포중이다. 2) Dedexer (그림 4-14) smali 도구를 이용한 디스어셈블 결과 화면 Dedexer는 smali와 같은 역할을 수행하는 디스어셈블러로, DEX 파일 을 디스어셈블 해준다. DEX 파일 분석 시 널리 사용되고 있으며, smali에 비하여 높은 안정성을 가진다는 장점이 존재한다. Dedxer도 smali와 마찬 가지로 (그림 4-15)와 같은 코드를 생성해준다. 현재 무료로 배포중이다

92 (그림 4-15) Dedexer 도구를 이용한 디스어셈블 결과 화면 실제 분석 시, DEX 파일 디스어셈블을 위하여 Dedexer 도구를 사용 하였다. Dedexer 도구를 선택한 이유는 smali 도구에 비하여 더 많은 사 용자가 존재하고 널리 사용되고 있어 더 높은 안정성을 가지는 장점이 있기 때문이다. (2) 분석 가능한 데이터 도출 DEX 파일을 디스어셈블러를 통하여 디스어셈블을 수행하면, 실제 분 석 가능한 데이터를 도출할 수 있다. DEX 파일을 디컴파일 하는 과정과 는 달리 이 분석 가능한 데이터는 일반적으로 사람이 한 눈에 알아보기 힘든 어셈블리어 코드와 유사한 형태로 존재한다. 따라서 이를 알아보기 쉬운 형태로 변환하는 과정을 필요로 한다. 이 과정은 실제 도구에서 파 싱(Parsing) 과정을 통해 해결하게 된다. 3. 도구 구현 구현 완료된 안드로이드 정적 분석 도구는 DEX 디스어셈블을 통한 분석 방법을 이용하였고, 스크립트 언어인 파이썬(Python) 기반으로 제작

93 되었으며, 완성 후 윈도우 환경 및 리눅스 환경에서 테스트를 수행하였 다. 가. 구현 메커니즘 안드로이드 정적 분석 도구는 (그림 4-16)과 같이 입력 값으로 분석 할 프로그램(APK 파일)을 넣어주면, 순차적으로 변환 및 분석 과정을 통 해 결과물(텍스트 파일)을 생성하도록 설계되었다. 실제적으로 사용자가 APK 파일 분석 시 확인할 수 있는 도구의 모습은.py 포맷을 가지는 파 이썬 기반의 도구 하나이지만, 내부적으로는 DEX 파일 디스어셈블을 위 하여 외부에 존재하는 디스어셈블러인 Dedexer를 호출하도록 설계되었 다. (그림 4-16) 안드로이드 정적 분석 도구 동작 과정 분석 도구의 동작 과정은 다음과 같다. (1) 안드로이드 정적 분석 도구(.py)에 분석 대상 파일(.apk)을 넣어줌

94 (2) 압축파일 형태인 APK 파일의 압축을 해제 (3) 실제 실행파일인 DEX 파일을 추출 (4) Dedexer 도구를 이용하여 디스어셈블 수행(.ddx 파일 생성) (5) 디스어셈블 코드를 분석자가 알아볼 수 있는 형태로 파싱(Parsing) (6) 파싱된 결과를 텍스트 파일(.txt)로 폴더(파일명_report)에 저장 나. 결과물 (1) 정적 분석 도구 정적 분석 도구는 (그림 4-17)과 같이 파이썬으로 구현되어 있으며, 별도의 UI(User Interface)는 구현되어 있지 않다. 도구의 실행 방법은 윈 도우 커맨드 창에서 code.py 입력파일.apk 의 명령어를 실행 시키면 입력 파일에 대한 분석을 수행하여 미리 정의된 15가지 정보 유출 API를 탐지하고 분석하여, 분석된 결과를 텍스트 파일 형태로 저장하게 된다. (그림 4-17) 정적 분석도구 소스 코드 및 실행 화면 (2) 분석 결과(.txt)

95 분석 결과 생성되는.txt 파일은 프로그램에서 정보 유출 API가 사용 된 내역을 담고 있다. 저장된 정보는 (그림 4-18)과 같이 프로그램에서 사용된 함수명과 함수에 대한 간단한 설명, 그리고 그 함수가 코드의 몇 번째 줄에서 수행되었는지에 대한 결과 까지 보여준다. 이를 통해 분석가 는 실제 어떠한 API의 사용을 통해 정보의 유출 여부를 판단할 수 있고, 이 프로그램이 원래의 목적과는 다르게 동작하고 있음을 판단하여 악성 코드로의 분류가 가능해진다. (그림 4-18) 분석 결과를 저장하는 텍스트 파일 (3) Dedexer 도구에 대한 입력 값으로 주어지는 APK 파일의 압축 해제 결과 생 성되는 DEX 파일을 (그림 4-19)와 같이 외부에 존재하는 Dedexer 도구를 통해 디스어셈블을 수행하게 된다. 디스어셈블 된 결과는.ddx 파일의 형 태로 존재하게 되며, 특정 위치에 저장된다. 실제 디스어셈블 수행 결과 생성된.ddx 파일의 내용을 파이썬 도구에서 파싱하는 과정을 갖게 된다

96 (그림 4-19) 디스어셈블 후.ddx 파일 생성 결과 화면 제 2 절 동적 분석 도구 동적 분석은 실제로 프로그램을 실행하여 분석하는 방법으로써 정적 분석에서는 할 수 없는 코드 커버리지(Code Coverage) 측정이 가능하다 는 장점을 가진다. 코드 커버리지는 소프트웨어 테스트 시 사용되는 측정 기준 중에 하나로, 이는 코드가 테스트 된 정도를 나타낸다. 코드 커버리 지 기준은 [표 4-2]와 같이 5개 기준이 존재하며, 특정 테스트 케이스 (Test Case)를 어느 기준을 적용하여 수행하느냐에 따라 커버리지 비율이 달라진다. [표 4-2] 코드 커버리지 기준 종류 Function coverage 설명 소프트웨어 내에 정의된 Function이 호출되는 정도 Statement coverage 소프트웨어 내에 기술된 Statement가 수행되는 정도