연구개발 필요성 - 추진배경

Size: px

Start display at page:

Download "연구개발 필요성 - 추진배경"

원상 유
5 years ago
Views:

1 1 안드로이드보안 취약점분석과보안아키텍처확장 신인식

2 2 Android Security Architecture Android Permission & Linux GID

3 3 Android Architecture Android 는 linux 기반의모바일 OS 로, 내부적으로 linux 의 access control 메커 니즘을활용하고있음

4 4 Linux 의 access control 메커니즘 Linux 에서는 user 식별자인 UID 와 user 가속해있는 group 식별자인 GID 를기반으로 user 가 접근할수있는파일이나디렉토리자원들에대한 access control 을수행함 파일을생성한 user 가해당파일의소유주가되며, user 는소유주, 소유그룹, others 에대한권 한을설정함으로써, 다른 user 들에대한파일접근을제어할수있음 - ex) - r w x r x r root root 1024 Feb 8 13:01 bin/ 소유주 소유그룹 others 소유주 UID 소유그룹 GID

5 5 Android Architecture Android 는 linux 기반의모바일 OS 로, 내부적으로 linux 의 access control 메커 니즘을활용하고있음 - 각앱은고유한 UID를지님으로써, 다른앱들로부터각자의파일자원들을보호함 - 동일한 GID를지니는다른앱들에게는자원을공유하기도함

6 6 Android permission 하지만 Android에서 Linux UID / GID를직접활용하기에는어려움이존재 - Android에서는파일외에도다양한자원들이존재하고, 이들에대한 access control이필요 ex) App 의 service, activity - 하나의자원사용을위해다수개의 GID 가필요한경우, 이에대한매핑이필요 이를위해 Android 에서는한단계더추상화된컨셉으로 permission 을정의함

7 7 Android permission Android는여러 resource에대한 permission들을정의하고있으며, 적절한 permission을지닌앱만이해당 resource에접근할수있도록설계되어있음 - System permission: Android 플랫폼에서정의된 permission으로, 시스템자원들에대한 access control을담당 ex) 카메라, 외부저장소, SMS 메시지등에대한접근 - Custom permission: Third-party 앱들이정의한 permission으로, 앱자원들에대한 access control 을담당 ex) 앱의 Service, Content provider 등에대한접근

8 8 Android Permission List READ_CALENDAR RECORD_AUDIO READ_EXTERNAL_STORAGE WRITE_CALENDAR READ_PHONE_STATE WRITE_EXTERNAL_STORAGE CAMERA CALL_PHONE ACCESS_WIFI_STATE READ_CONTACTS BODY_SENSORS CHANGE_NETWORK_STATE WRITE_CONTACTS SEND_SMS INTERNET GET_ACCOUNTS RECEIVE_SMS NFC ACCESS_FINE_LOCATION READ_SMS SET_TIME

9 9 Linux GID mapping Android permission들은 Linux Group ID (GID) 와매핑되어있음 - 앱이 GID에매핑되어있는 permission들중하나라도얻으면해당 GID를가질수있음 - 이때, 앱은해당 GID로만접근할수있는파일들을 read/write할수있게됨 <Android Permissions> ACCESS_ALL_EXTERNAL_STORAGE <Linux GID> /sdcard 경로에있는모든파일에접근가능 READ_EXTERNAL_STORAGE sdcard_r WRITE_EXTERNAL_STORAGE

10 10 Permission management 앱이요구하는 permission 정보들은 Manifest 파일에선언되어있으며, 이정보들은앱이설치될때 Package Manager (PM) 에저장되고, 관리됨 이때, 각 permission마다다른 protection level을지니게함으로써앱이요구할수있는 permission 범위에제한을둠 Protection Level Normal Dangerous Signature / SystemOrSignature Description to obtain the Permission 사용자의명확한동의불필요 사용자의명확한동의요구됨 해당 permission 을정의한주체와동일한인증서로서명되어야함

11 11 Permission checking Android 는앱이각 resource 에접근할때마다 PM 을통해해당앱의 permission 을확인함 - 적절한 permission 이있다면해당 resource 에대한접근을허용 Application 1 Camera 요청 Camera Service 4 Access 성공 2 Permission check 요청 3 Permission granted Package Manager

12 12 Permission checking Android 는앱이각 resource 에접근할때마다 PM 을통해해당앱의 permission 을확인함 - 적절한 permission 이없다면 security exception 을일으키고, 해당접근을막음 1 Camera 요청 Application 4 Security exception Camera Service 3 Permission denied 2 Permission check 요청 Package Manager

13 13 SELinux (Security-Enhanced Linux) Android 는 4.3 버전부터 SELinux 를적용하여, 더욱더세분화된 access control 제공 SELinux vs. Linux UID / GID system Linux UID / GID SELinux Access control 방법 Discretionary Access Control (DAC) Owner 에게자유재량권부여 Mandatory Access Control (MAC) 미리정해진 rule 에따라, 오직필요한기능에대해서만사용권한부여 Access control 주체 User Role 예 : shell, init, kernel, mediaserver, system_server, appdomain 등 단위 객체 File / directory Type - Class 예 : Kernel type 의 file, dir, process, security, socket class Access permission 종류 Read / write / execute 모든종류의 operation 예 : read / / create / open / listen / lock

14 14 SELinux (Security-Enhanced Linux) SELinux vs. Linux UID / GID system ( 계속 ) - 악성앱이악의적으로 root (super user) UID 획득 ( 루팅 ) 에성공한경우, Linux UID / GID: super user 이므로, 아무런제한없이다른 user 의 data 에접근가능 악성앱 (root UID) 접근성공 User private data SELinux: super user 이더라도, OS 에서 type 에따라 access control User 임의로 type 를변경하는것은불가능 악성앱 (shell type) 접근실패 User private data (app_data_file type)

15 15 SELinux policy management SELinux policy는 source ( 주체 ) 와 target ( 객체 ) 에관한 rule들로구성됨 - SELinux policy rule 포맷 allow [SOURCE_TYPE] [TARGET_TYPE]:[CLASS] [PERMISSION]; 예 : allow shell shell_data_file:file {ioctl read write create getattr setattr lock append } - 특정 source와 target간 rule이정의되어있지않은경우, 접근이허용되지않은것으로간주 (whitelist 방식 ) SELinux policy rule들은 Android 프레임워크와함께빌드됨 - 제조사들은 device-specific rule들을추가하기위해, 해당 rule들을포함하고있는.te파일들을프레임워크와같이빌드함 - Runtime에사용자가임의로 rule을추가하는것이불가능

16 16 SELinux policy management SELinux policy는적용되는방법에따라, 두가지모드로구분됨 - Enforcing 모드 SELinux policy 에따른 access control 이적용되며, 이에대한 log 도같이남김 - Permissive 모드 SELinux policy 에따른 access control 이적용되지않지만, policy 에어긋난 operation 이수행된경우 log 를남김 - Android 는 5.0 버전부터 enforcing mode 를기본모드로사용하여보안을강화함 Enforcing -> permissive 모드로의전환또한일반사용자 (root 사용자포함 ) 에게는제한됨

17 17 Android 스마트폰보안취약점분석 Permission-GID 매핑

18 19 목표 Motivation - 각스마트폰제조사들은자신들의제품에맞게, 많은부분의안드로이드소스를수정해서사용함 - 이과정에서다음과같은이유로여러보안취약점이발생할수있음 안드로이드는그구조가매우복잡함 짧은개발기간 ( 약 6개월미만 ) 안에안드로이드를 customizing함 - 따라서제조사기기 (custom) 프레임워크와 AOSP 프레임워크간의비교를통해제조사기기에잠재되어있는보안취약점을발견할수있음 목표 - ANDDIFF: 프레임워크비교분석도구설계및개발 AOSP 와의비교를통해 custom 프레임워크에잠재되어있는보안취약점을자동으로발견및분석

19 20 타겟보안취약점들 ANDDIFF는크게두가지타입의보안취약점들을발견할수있음 V1. 이전에얻을수없었던 privileged Linux GID를 custom 프레임워크에서얻을수있는취약점 V2. 이전에접근할수없었던 App component에 custom 프레임워크에서는접근할수있는취약점 <legend> : counterparts <AOSP 프레임워크 > <Custom 프레임워크 > Security Exception privileged GID X (not acquirable) privileged GID X (acquirable) privileged file access Android system app component Y (private) Android system app component Y (public) privileged code execution

20 21 V1. 보안수준이약해진 privileged GID 분석방법 (1/4) Android permission 의 protection level - Permission 마다각각다른 protection level 을지님 Protection Level Normal Dangerous Signature, SystemOrSignature Description to Obtain the Permission 사용자의명확한동의불필요사용자의명확한동의요구됨앱은퍼미션을정의한앱과동일한인증서로서명되어야함

21 22 V1. 보안수준이약해진 privileged GID 분석방법 (2/4) Android permission과 Linux Group ID (GID) 사이의매핑 - 앱이 Linux GID에매핑되어있는 permission들중하나라도얻으면해당 GID를가질수있음 - 어떤 GID를가지면해당 GID로만접근할수있는파일들을 read/write할수있음 <Android Permissions> ACCESS_ALL_EXTERNAL_STORAGE (signature) <Linux GID> /sdcard 경로에있는모든파일에접근가능 READ_EXTERNAL_STORAGE (dangerous) sdcard_r WRITE_EXTERNAL_STORAGE (dangerous)

22 23 V1. 보안수준이약해진 privileged GID 분석방법 (3/4) 발생가능한보안취약점 - customizing 과정에서특정 GID를얻을수있는 permission들의 protection level이이전보다낮게설정된다면이로인해보안취약점이생길수있음 - e.g., READ_EXTERNAL_STORAGE의 protection level을 dangerous에서 normal로낮춘경우 ACCESS_ALL_EXTERNAL_STORAGE (signature) Malicious app 은사용자동의없이 /sdca rd 경로의모든파일에접근가능 READ_EXTERNAL_STORAGE (normal) sdcard_r WRITE_EXTERNAL_STORAGE (dangerous)

23 24 V1. 보안수준이약해진 privileged GID 분석방법 (4/4) 분석목표 - protection level이낮아진 permission을탐색하고, 해당 permission으로얻을수있는 GID 파악 - GID를통해접근할수있는파일목록파악 분석방법 - 이를위해프레임워크이미지에포함된설정파일들 (.xml) 을분석 /etc/permissions/platform.xml Android permission 과 Linux GID 사이의매핑관계가정의되어있음 /framework/base/core/res/androidmanifest.xml 각 Android permission 이정의되어있으며, 어떤 protection level 로설정되어있는지알수있음 - File system 의경로별 group permission 목록추출

24 25 V2. 보안수준이약해진앱컴포넌트분석방법 (1/5) Android component의보안설정방식 - 안드로이드컴포넌트의종류 : Activity, Service, ContentProvider, BroadcastReceiver - 다음과같은보안설정을지님 exported, permission, readpermission/writepermission Any app Permission A 을지닌 apps Any app exported=false exported=true permission=a exported=true permission=nil

25 26 V2. 보안수준이약해진앱컴포넌트분석방법 (2/5) 발생가능한보안취약점 - 앱컴포넌트의보안설정이 AOSP보다다르게설정되어있는경우, 이로인해보안취약점이생길수있음 - e.g., exported 값이 false에서 true로변경된경우, 외부 malicious app이해당컴포넌트에쉽게접근하여, 특별한권한없이도컴포넌트의코드를실행시킬수있음

26 27 V2. 보안수준이약해진앱컴포넌트분석방법 (3/5) 분석목표 - AOSP 프레임워크와의비교를통해보안설정이이전보다낮게변경된컴포넌트들파악 이때, AOSP 프로임워크와 custom 프레임워크에서동일한이름을지닌컴포넌트들을매핑하여비교분석 e.g., AOSP의 ClockProvider와 custom의 ClockProvider의보안설정비교 Challenge - Customizing 과정에서많은컴포넌트들의이름이변경될수있음 e.g., AOSP 의 ClockProvider 가 custom 에서는 AlarmProvider 로개명될수있음 - 이경우, 개명된컴포넌트들까지추적하여 AOSP 프레임워크와비교분석이가능해야함

27 28 V2. 보안수준이약해진앱컴포넌트분석방법 (4/5) 분석방법 1. 컴포넌트의이름이바뀌지않은경우 해당앱의 manifest 파일 (AndroidManifest.xml) 분석 각컴포넌트의보안설정이정의되어있음

28 29 V2. 보안수준이약해진앱컴포넌트분석방법 (5/5) 분석방법 2. 컴포넌트의이름이바뀐경우 AOSP 프레임워크에서동일한컴포넌트를찾기위해컴포넌트들의코드유사도비교 만약두컴포넌트들간의코드가비슷하다면두컴포넌트들이동일할가능성이높다고가정함 최대이분매칭알고리즘을사용하여최대유사도를지닌컴포넌트매핑을찾음 이후매핑된컴포넌트들에대해 manifest 파일의보안설정분석 AOSP co mp a AOSP co mp b AOSP co mp c Custom co mp x Custom co mp y Custom co mp z Custom co mp w x y z w a b c 행렬로표현한각노드사이의가중치 ( 유사도 )

29 32 V1. 보안수준이약해진 privileged GID 결과 (1/3) ZTE Kis3 max ZTE Blade G THL W200 Protection level 이낮아진 Permission ACCESS_MTK_MMHW ACCESS_LOCATION_API ACCESS_MTK_MMHW 획득가능한 GID system media camera system qcom_oncrpc net_raw qcom_diag gps media camera

30 33 V1. 보안수준이약해진 privileged GID 결과 (2/3) 결과분석 - system GID (ZTE Kis3 max & ZTE Blade G) ZTE Kis3 max /data/system/locksettings.db --> 잠금화면패턴인증초기화 /data/system/packages.xml --> 안드로이드퍼미션획득및악성앱신분위조 /dev/block/mmcblk0 --> 플래시메모리 (emmc) 내의모든정보유출 /dev/block/mmcblk0boot0 --> 플래시메모리 (emmc) 내의모든정보유출 ZTE Blade G ACCESS_LOCATION_API에대한실제정의부분이존재하지않아서 system GID를획득할수없음 또한 ACCESS_LOCATION_API에매핑되어있는다른 GID들역시획득할수없음 qcom_oncrpc, net_raw, qcom_diag, gps

31 35 V2. 보안수준이약해진앱컴포넌트결과 ZTE Kis3 max ZTE Blade G THL W200 Activity 개명되지않은컴포넌트 Service ContentProvider BroadcastReceiver Activity 개명된컴포넌트 Service ContentProvider BroadcastReceiver 총합

32 37 다섯범주의공격방식과공격예제 공격방식 예시공격 A1. 플래시메모리의정보유출안드로이드내부저장소 (/data/data/*) 에있는시스템데이터베이스파일확인 A2. 안드로이드퍼미션획득 signature protectionlevel 의 REBOOT 시스템퍼미션획득 A3. 악성앱신분위조악성앱의유저 ID 를크롬 (Chrome) 의것으로위조, 크롬데이터에접근 A4. 잠금화면패턴인증초기화 PIN, 패턴인증등의사용자인증방식무력화 A5. 스마트폰모듈제어 WiFi 모듈을비활성화하는서비스거부공격

33 38 <Demo 1> A1. 플래시저장소내의모든정보유출 악성앱이 ACCESS_MTK_MMHW 퍼미션을요구하여 system GID를획득 system GID가있으면플래시메모리를관리하는디바이스드라이버에접근가능하며, 이를통해플래시메모리에저장된사용자의다양한개인정보를획득할수있음 - 웹브라우저의쿠키와히스토리 - 클라이언트앱이다운로드한이메일들의내용 - 핸드폰에있는연락처 emmc (binary, around 8GB) ext4 reader/parser database files of preloaded apps Web browsing history Contacts Calendar...

34 41 <Demo 3> 잠금화면패턴초기화 악성앱이 ACCESS_MTK_MMHW 퍼미션을요구하여 system GID를획득 system GID가있으면잠금화면패턴을저장해놓은파일인 /data/system/locksettings.db에접근가능 이파일을삭제하면잠금화면패턴을초기화할수있음

35 Mobile Platform Security FlexDroid: Enforcing In-app Privilege Separation (NDSS 2016) Jaebaek Seo*, Daehyeok Kim*, Donghyun Cho*, Taesoo Kim, Insik shin* * KAIST Georgia Institute of Technology 43

36 3 rd -party libraries become popular on Android Application Ad, Analytics, Game engine, Billing, Social Host code 3rd-party libraries Can we trust them?

37 Unit of Trust on Android Host applicati on Application 1 3rd party li b Application 2 Resources The unit of trust in Android is an app All components including third-party libraries in an app have the same permissions to acces s resources

38 Over-privileged Third-party Libraries Permissions used by popular third-party libraries Required Optional Undocumented

39 Undocumented Permissions Required Optional Undocumented From XXXBank: Facebook (Social) Your One-Time Password is Flurry (Analytics) Valid for 5 mins. Paypal (Billing) InMobi (Ad) Chartboost (Ad)

40 Threat Model Third-party libraries are potentially malicious Their code and logic are not directly visible to app developers ( e.g., obfuscated) Can use dynamic features of the Java language (e.g., JNI, reflect ion, multi-threading) App developers explicitly know what third-party libraries a re for Given high-level functional description, app developers should be able to adjust the manifest and seamlessly integrate them w ithout compromising usability

41 Goal Separating the privilege of third-party library from the privil ege of its host application Preventing third-party libraries from accessing resources out of its pr ivilege

42 Overview of FLEXDROID Specifying the package name and its permissions in AndroidManifest.xml <uses-permission...location> <uses-permission...contacts> App Location com.ad.sdk Deny Contacts <flexdroid android:name= com.ad.sdk > <allow Location> </flexdroid>

43 Challenges Control-flow and data dependency Between host application and third-party libraries Dynamic runtime behavior JNI, reflection, multi-threading Java language techniques used in third-party lib raries.

44 Related Works Protecting apps from privacy-unaware third-party libraries. o Running ads in separate processes or system services o Drawback: unable to handle control-flow & data dependency between host and library AdSplit[1], AdDroid[2] Detecting in-app security/privacy risks. o Static and dynamic analysis to detect resource access o Drawback: unable to detect malicious behavior of dynamically generated code Brahmastra[3], Livshits et al.[4] [1] S. Shekhar, M. Dietz, and D. S. Wallach. Adsplit: Separating smartphone advertising from applications. In Presented as part of the 21st USENIX Security Sympo sium, [2] P. Pearce, A. P. Felt, G. Nunez, and D. Wagner. AdDroid: Privilege separation for applications and advertisers in android. In Proceedings of the 7th ACM Sympo sium on Information, Computer and Communications Security, [3] R. Bhoraskar, S. Han, J. Jeon, T. Azim, S. Chen, J. Jung, S. Nath, R. Wang, and D. Wetherall. Brahmastra: Driving apps to test the security of third-party compon ents. In 23rd USENIX Security Symposium, Aug [4] B. Livshits and J. Jung. Automatic mediation of privacy-sensitive resource access in smartphone applications. In Presented as part of the 22 nd USENIX Security Symposium, 2013.

45 Dynamic Permission Adjustment When executing the host 3 rd -party application s lib s code code App Permissions App Permissions Permissions of host application Location Contacts Permissions of third-party library Location Dynamically adjusting the permission of an app based on the current context

46 Identification of Executed Code 1. Identify the principal using stack inspection 2. Apply the stack inspection to Android 3. Protect the integrity of call stack information against various attacks such as - JNI - Reflection - Multi-threading 54

47 Stack Inspection in Security Context Process of determining the permissions allowed to the current thread according to principals shown in the call stack P Call stack A com.a.functiona B com.b.functionb C com.c.functionc Perm = Perm(A) Perm(B) Perm(C) 55

48 Inter-process Stack Inspection Permission Checker App Location Manager PM Dalvik Dalvik Dalvik User Space Kernel Space File Sysm Internet SD Card Permission Checker 56

49 Inter-process Stack Inspection Permission Checker App Stack Dalvik Tracer Location Manager Dalvik PM Dalvik User Space Kernel Space File Sysm Internet SD Card Stack Transmission Channel 57

50 Potential Attack Surface Reflection Multi-threading App Location Manager PM JNI Stack Dalvik Tracer Dalvik Dalvik User Space Kernel Space Stack Transmission Channel 58

51 Potential Attack Surface Compromising stack tracer JNI Manipulating Dalvik call stack JNI, Reflection, Multi-threading Hijacking the control data JNI e.g., code injection on Dalvik functio ns, manipulating code pointers 59

52 Protecting Integrity of Call Stack JNI Sandbox Defense mechanism against attacks via reflection Defense mechanism against attacks via multi-threading 60

53 Protecting Integrity of Call Stack JNI Sandbox Defense mechanism against attacks via reflection Defense mechanism against attacks via multi-threading 61

54 Defense Against Native Code Execution Hardware based Fault Isolation FlexDroid enforces JNI to be executed in an isolated area under the same process When JNI accesses memory out of its domain, a fault occurs Dalvik VM Code section JNI Stack tracer Dalvik Stack

55 Performance Evaluation Experiment environment: Nexus 5 / Android / Kernel % overhead according to Antutu benchmark

56 Conclusion FlexDroid is a first mobile system that provides in-app privilege separation against JNI and dynamic runtime behavior e.g., reflection, multi thread, runtime code loading However, FlexDroid cannot prevent a malicious third-party library from accessing data without access control

보안공학연구회

보안공학연구회 보안공학연구논문지 (Journal of Security Engineering), 제 10권 제 2호 2013년 4월 효율적인 안드로이드 애플리케이션 검수를 위한 견고한 퍼미션 기반 악성 애플리케이션 여과 기법 전 철 1), 장준혁 2), 김봉재 3), 정진만 4), 조유근 5) A Robust Permission-Based Malicious Application