Paper Summary on Mobile Security in 2014

Paper Summary on Mobile Security in 2014

Transcript

1. Paper Summary on Mobile Security in 2014 Bob Mingshen Sun January 13, 2015
2. Conference Coverage IEEE S&P USENIX Security ACM CCS NDSS ACSAC Bob Paper Summary on Mobile Security in 2014 January 13, 2015 2 / 55
3. Outline 1 Conference Coverage 2 IEEE S&P 3 USENIX Security 4 CCS ’14 5 ACSAC ’14 6 NDSS ’15 Bob Paper Summary on Mobile Security in 2014 January 13, 2015 3 / 55
4. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating 1 Take-away Message: The authors found a new type of vulnerabilities of system upgrading, called Pileup flaws in Package Management Service of Android. 1Luyi Xing and Xiaorui Pan (Indiana University Bloomington), Rui Wang (Microsoft Research), and Kan Yuan and XiaoFeng Wang (Indiana University Bloomington) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 4 / 55
5. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating Motivation: System upgrading mechanism is closely related to app sandbox, privilege escalation. Design mistakes can make the whole security systems collapse. Bob Paper Summary on Mobile Security in 2014 January 13, 2015 5 / 55
6. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating Background: Android updating Over the Air (OTA) bootloader.img and image patches (radio.img.p) recovery mode for image patching replace old image and old apps Package Manager Service (PMS) will help for app installing, upgrading configuring and removing apps PMS will register permissions, shared UID, activities, intent, filters, actions and services TOO COMPLICATED! Bob Paper Summary on Mobile Security in 2014 January 13, 2015 6 / 55
7. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating Attacks 1 permission harvesting and preempting 2 shared UID grabbing 3 data contamination 4 denial of services Bob Paper Summary on Mobile Security in 2014 January 13, 2015 7 / 55
8. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating 1. Permission Harvesting and Preempting The new dangerous permissions have never been identified by the system before the updating Malware can request these permission on the old system and wait until a system upgrading. For latest information regarding the vulnerabilities and the SecUp (Secure Update Scanner) app, please visit our official website http://SecureAndroidUpdate.org. system before the updating and are thus never known to the user. Exploiting this weakness, a malicious app can “harvest” permissions (i.e., requesting them on the old system) and wait until an update to get them. Note that this attack can only get the app dangerous level permissions, since signature and system permissions declared by system apps cannot be granted to the third-party app and an attempt to get them will be identified during permission registration. However, there is a way to get the permissions at sig- nature and system level: the malicious app can preempt the permissions from the new system and simply define them when it is installed. Again, since there is no such permissions on the old system, the OS just lets the app declare them, which includes specification of the permissions’ protection levels and descriptions. This process does not need the user’s intervention at all, as all these permissions are used to protect the sources that come with the app. During an update, PMS reads all existing permissions (on the old system) into the list mSettings.mPermissions. When it registers a new permission defined by a new system package, it first goes through the list: once this permission has been found on the list and the package that first defines it (on the old system) and the call log on Android 4.0 and 4.1 respectively. Permission Name Protection Level Android Version Description (allows to) Mount format FileSystems signature OrSystem 1.5 format removable storage Use credentials dangerous 2.0 request authentication tokens GoogleVoice.SMS dangerous 4.0 receive Google Voice messages Retrieve window content signature OrSystem 4.0 retrieve content of entire active window except passwords Send sms no Confirmation signature OrSystem 4.0 send SMS messages without confirmation Start any activity signature 4.1 start any activity, ignore permission or exported state Grant permissions signature 4.1 grant specific permissions for apps Plus.Picasa dangerous 4.2 access photos in Google Photos Across users signature OrSystem 4.2 violate protection between users Access notification signature OrSystem 4.3 retrieve and clear notifications including those of other apps TABLE I. SELECTED PREEMPTED PERMISSIONS As another example, we preempted the permission for Google Cloud Messaging (GCM) [7] to intercept its Push messages. GCM is a service that helps developers send data from their servers to their Android apps. The messages deliv- Bob Paper Summary on Mobile Security in 2014 January 13, 2015 8 / 55
9. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating 2. Shared UID Grabbing Apps with same shared UID should have same signature. Install an app claimed with shared UID com.google.android.calendar in Android 2.3.6. After upgrading, calendar will be blocked because of the different signature. Install an malicious calendar app to steal privacy. has a shared UID. When installing a system app, PMS creates a class instance pkgSetting that holds the app’s setting information. The content of the data structure normally comes from the app itself. However, when PMS looks up the list mSettings and finds a conflict in package name (an existing app with an identical package name from the old OS), it will look at both packages’ shared UID settings: if they use the same shared UID (including empty ones), the structure pkgSetting will be loaded from the existing app. Then in the case of non-empty share UIDs, PMS verifies their app signatures to check whether they are signed by the same party. When this is not true, the new system app will not be installed so the existing one could be installed later. Presumably, this treatment is meant to be conservative, as Google and other vendors have no idea whether the existing app and its data is useful to the user. Note that on the same device, by no means two apps signed by different parties should share their UIDs, which will completely open them to each other in terms of their individual information assets. However, this conservative treatment can be exploited by the adversary, who can craft an app bearing the same package name and shared UID as the system app from a higher-version OS. During upgrading, the app can block the installation of the system app. This can have serious consequences, which we will discuss later. This problem was first discovered through a manual check of the code, which had motivated this research. Later, when we ran our Pileup detection tool (Section IV) on PMS, it turned out that the package name is unnecessary for the attack. events to the calendar. This malicious calendar can be made to have the same user interface as the official calendar app. Note that should the official calendar app still be there, the user would be notified that two apps were monitoring the same intents and asked to choose one of them, while in our case, our app was the only one expecting the events and therefore such a notification did not come out. We have a video demo posted online [14] to show how our app stealthily gets private user events and schedules. The same exploit can also work on other Android system apps, as illustrated in Table II. sharedUID Package Name Device Model Carrier/ Country Android Version uid.nfc com.sec.surfsetprop SGH-T869 TMB/US 4.0.4 uid.platform com.sec.widget GT-P7300 SER/Russia 4.0.4 uid.graphics com.samsung.reader GT-P6800 SER/Russia 4.0.4 vmware.mvp vmware.mvp SCH-I535 VZW/US 4.1.2 uid.widget sec.app.launcher GT-I8160 LUX/Luxemburg 4.1.2 com.c chinaunicom.cloud EK- GC100 CHU/China 4.1.2 scloud.sync sCloud.datasync sCloudSyncBrowser sCloudSyncContacts GT-I9300 CHU/China 4.1.2 TABLE II. EXPLOIT OPPORTUNITIES OF SHARED UID GRABBING ON SAMSUNG DEVICES C. Data Contamination All the precautions made by PMS during an update are for the purpose of avoiding any potential damage to the device user’s existing assets, particularly her data. Indeed, Bob Paper Summary on Mobile Security in 2014 January 13, 2015 9 / 55
10. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating 3. Data Contamination PMS will reuse the old data for the same UID when upgrading. Android 2.3 -> Android 4.0: com.android.browser -> com.google.android.browser. browser’s databases, such as cookies, security configurations and bookmarks. login cross-site request forgery (CSRF) attacks tampered with the browser’s built-in bookmarks list (Google, Yahoo, Facebook) tampered with the browser’s built-in bookmark list. On the lis are a set of website-URL pairs, which we modified to point to the sites under our control. For example, we replaced the URL for Google, Yahoo, Facebook, Twitter, etc. with the links to our sites. Note that this bookmark list can also include wha the user sets on her 2.3.6 device. As the result of this exploit whenever the user uses her bookmarks, she is always directed to our websites. Video demos of the attacks are here [14]. Again, such attacks are not limited to browser. Table II illustrates some of the other opportunities we found from Google Nexus and Samsung devices. Update Version Package Name Update Version Package Name 2.3 -4.0 android.exchange android.keychain google.gsf.login google.apps.plus 4.0 -4.1 com.dropbox samsung.gmail 4.1 -4.2 sec.safetyassurance samsung.accesscontrol TABLE III. OTHER EXPLOIT OPPORTUNITIES FOR DATA CONTAMINATION D. Denial of Services As discussed in Section III-A and Section III-B, the Pileup flaws within PMS lend a malicious app an elevated capability to deny a mobile system new resources added through an Bob Paper Summary on Mobile Security in 2014 January 13, 2015 10 / 55
11. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating 4. Denial of Services Android 2.3 -> Android 4.0 Google Play Service Many apps and services are based on Google Play Service (e.g., Google Cloud Messaging is based on Google Play Service) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 11 / 55
12. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating Proposed Solution & Evaluation SecUP system to find the flaw apps. detecting update flaws finding exploit opportunities pileup scanner measurement studies of vulnerability opportunities Bob Paper Summary on Mobile Security in 2014 January 13, 2015 12 / 55
13. Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating Directions Review codes for key components in Android to discover vulnerabilities. Bob Paper Summary on Mobile Security in 2014 January 13, 2015 13 / 55
14. The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations2 Take-away Message: The vulnerabilities of wrong mode of driver device files in the customized firmwares. 2Xiaoyong Zhou, Yeonjoon Lee, and Nan Zhang (School of Informatics and Computing, Indiana University, Bloomington), Muhammad Naveed (Department of Computer Science, University of Illinois at Urbana-Champaign), and Xiaofeng Wang (School of Informatics and Computing, Indiana University, Bloomington) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 14 / 55
15. The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations Idea driver device file under /dev directory user group other execute (x): 1, write (w): 2, read (r): 4 660: rw-rw—- TABLE V. LCFS DETECTED BY RISK IDENTIFIER Device Nexus 4 Galaxy SII Galaxy ACE 3 Galaxy GRAND /dev mod owner /dev mod owner /dev mod owner /dev mod owner camera video0(rear) 660 system:camera video0(front) 666 system:root video0 660 system:camera vchiq 666 system:system video1(front) 660 system:camera video1(rear) 666 system:camera video1 660 system:camera vc-cam 666 system:system input input/event* 660 root:input input/event* 666 root:input input/event* 660 root:input input/event* 660 root:input framebuffer graphics/fb* 660 root:graphics graphics/fb* 660 root:graphics graphics/fb* 666 system:graphics graphics/fb* 660 root:graphics to directly work on it. Following we describe our end-to-end attack on this vulnerability. To communicate with the camera device, we first tried the operation sequence specified by the V4L2 standard [17] as Again, our attack does not need any camera-access permis- sions, and nor does it demonstrate any visual effects during picture taking (such as showing preview in a normal use of the camera). Therefore, it is completely stealthy to the phone user. A video demo of the attack is here [1]. This problem Bob Paper Summary on Mobile Security in 2014 January 13, 2015 15 / 55
16. From Zygote to Morula: Fortifying Weakened ASLR on Android3 Take-away Message: The authors design attacks capable of bypassing weakened ASLR and executing return-oriented programming on Android. 3Byoungyoung Lee (Georgia Institute of Technology), Long Lu (Stony Brook University), Tielei Wang (Georgia Institute of Technology), Taesoo Kim (Massachusetts Institute of Technology), and Wenke Lee (Georgia Institute of Technology) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 16 / 55
17. From Zygote to Morula: Fortifying Weakened ASLR on Android Idea 1. Activity Manager (AM) request new app 2. fork Zygote process and create a browser process 3, 4. warm-init and specialize stages: load the actual app information, call the main method of this activity thread Android’s address space layouts for running apps directly inherited from the zygote process; the shared library such as libc.so or libssl.so are located identically among all running apps Init (pid=1) Zygote AM Music Browser ① request new app ② fork() … Shared libraries ③ warm-init libc.so libdvm.so libssl.so ④ specialize (e.g.,) ... Fig. 1. Zygote process creation model with memory layout representation when launching a browser app. AM represents Activity Manager. The gra region displays a snapshot of the Android’s address space layouts for runnin apps, directly inherited from the Zygote process; each pattern represents shared library, such as libc.so or libssl.so, which is located identical among all running apps. Bob Paper Summary on Mobile Security in 2014 January 13, 2015 17 / 55
18. From Zygote to Morula: Fortifying Weakened ASLR on Android Address Space Layout Randomization (ASLR) protect buffer over flow attacks prevent an attacker from reliably jumping to a particular exploited function in memory randomly arranging the positions of key data areas of a program including stack, heap, and libraries Bob Paper Summary on Mobile Security in 2014 January 13, 2015 18 / 55
19. From Zygote to Morula: Fortifying Weakened ASLR on Android Attacks on real apps remote coordinated attacks 1. a malformed html file exploiting the information leak vulnerability 2. leaked memory layout information 3. URI intent 4. a malformed video file exploiting the control-flow hijack vulnerability which bypass ASLR 10 20 30 40 50 60 70 Shared Libraries in Zygote (sorted in a size) libchromium net.so dvm.so libc.so libssl.so each shared library’s executable section in the Zygote epresents the indices of the shared libraries and the y-axis t section size, at logarithmic scale. ① ② ③ ④ Attacker’s web server Victim’s Android VLC player Chrome Fig. 3. A remote coordinated attack for the Chrome browser and V Media Player on Android. Each numbered step represents: 1) a malform html file exploiting the information leak vulnerability, 2) leaked mem Bob Paper Summary on Mobile Security in 2014 January 13, 2015 19 / 55
20. From Zygote to Morula: Fortifying Weakened ASLR on Android Proposed Solution Morula instance pool having random memory layouts ahead of time transformed into the browser Evaluation: effectiveness, device boot performance measurement and compatibility tests (the evaluation part is pretty good) Init (pid=1) Zygote AM Morula … Shared libraries ③ cold-init ② fork() & exec() Morula Pool of Morula instances ① request prepare when idle (a) A preparation phase Init (pid=1) Zygote AM Browser … Shared libraries Morula ② send app info ③specialize ① request new app (b) A transition phase Bob Paper Summary on Mobile Security in 2014 January 13, 2015 20 / 55
21. Summary for IEEE S&P ’14 [UPDATING] vulnerability of updating process attacks to updating process proposed a system to automatically finding these vulnerabilities [DRIVER] vulnerability of Linux device driver attacks to vulnerable device driver proposed a system to automatically finding these vulnerabilities [MORULA] vulnerability of Android ASLR mechanism attacks to Android ASLR mechanism proposed a solution (system) to harden the ASLR weakness. General Process/Paper Layout vulnerability -> attack -> system Bob Paper Summary on Mobile Security in 2014 January 13, 2015 21 / 55
22. On the Feasibility of Large-Scale Infections of iOS Devices4 Take-away Message: security risks in connecting iOS devices to compromised computers 4Tielei Wang, Yeongjin Jang, Yizheng Chen, Simon Chung, Billy Lau, and Wenke Lee, Georgia Institute of Technology Bob Paper Summary on Mobile Security in 2014 January 13, 2015 22 / 55
23. On the Feasibility of Large-Scale Infections of iOS Devices Background: Jekyll Jekyll can be instructed to carry out malicious tasks by reordering and rearranging benign functionalities. Apple’s vetting process cannot prevent malicious apps. Jekyll apps did not get a lot of downloads. proactively deliver malicious apps to iOS devices at scale Bob Paper Summary on Mobile Security in 2014 January 13, 2015 23 / 55
24. On the Feasibility of Large-Scale Infections of iOS Devices Attack Vector: PC <-> iPhone backup, restore, syncing, upgrade and charging install or remove apps access data in mobile devices Key#Observation:#iTunes#Syncing# syncing iTunes#with#Apple#ID#A iOS#device#with#Apple#ID#B After#syncing,#apps#purchased#by#Apple#ID#A#can# also#run#on#the#iOS#device iTunes#can#authorize#an#iOS#device#with#a# different#Apple#ID#to#run#its#apps Bob Paper Summary on Mobile Security in 2014 January 13, 2015 24 / 55
25. On the Feasibility of Large-Scale Infections of iOS Devices Attack I: the man-in-the-middle syncing 'ID'B /sync/afsync.rs /sync/afsync.rs.sig erate' ir/sync/afsync.rq ir/sync/afsync.rq.sig iTunes'with' Botmaster's'Apple'ID'A iOS'device'with' Apple'ID'B 1.'Send'sync'request'(Keybag) 6.'Store' /AirFair/sync/afsync.rs /AirFair/sync/afsync.rs.sig 3.'afsync.rq'and'afsync.rq.sig'' 3b.'Generate' afsync.rs 5.'Upload'afsync.rs'and'afsync.rs.sig 2.'Generate' /AirFair/sync/afsync.rq /AirFair/sync/afsync.rq.sig 7.'Send'MetadataSyncFinish'request Bot'client' (victim's'computer) 3a.'afsync.rq''' 3c.'afsync.rs''' 4.'Generate' afsync.rs.sig Bob Paper Summary on Mobile Security in 2014 January 13, 2015 25 / 55
26. On the Feasibility of Large-Scale Infections of iOS Devices Attacks the man-in-the-middle syncing delivery of attacker-signed apps stealing credentials Attack#III:#Stealing#Credentials# •  However,#from#a#USB#connection,#a#host# computer#has#access#to#the#contents#of#all# apps 18" Bob Paper Summary on Mobile Security in 2014 January 13, 2015 26 / 55
27. On the Feasibility of Large-Scale Infections of iOS Devices Measurement: to estimate how many users would connect iOS devices to compromised PCs Datasets: DNS query dataset from two large ISPs in the US labeled C&C domains from a security company The#Goal#of#the#Measurement •  To#quantitatively#estimate#how#many#users#wo connect#iOS#devices#to#compromised#PCs Compromise" PCs" iOS"Devices" Bob Paper Summary on Mobile Security in 2014 January 13, 2015 27 / 55
28. On the Feasibility of Large-Scale Infections of iOS Devices iOS device population iTunes heartbeat DNS queries between iOS and PCs around 25% measure the number of iOS devices that can be poten- tially infected using the MitM attack described in Sec- tion 2, with five days of DNS query data. The results are summarized in Table 7. On average, we identified 459,326 bots daily. For 30% of bots, there exist iOS de- Botnet Size Setbots ∩SetiOS ∩SetiTunes Percentage α 287,055 75,714 26.38% β 69,895 12,517 17.91% γ 49,138 10,216 20.79% δ 16,236 3,232 19.91% ε 13,732 2,662 19.39% ε 5,024 1,182 23.53% ζ 4,554 944 20.73% η 4,377 929 21.22% θ 4,231 834 19.71% ϑ 4,067 806 19.82% Table 6: Statistical analysis of the top 10 botnets with highest number of infected CIDs on 10/12/2013. vices used from the same CID; and for 23% of all bots, there are both Windows iTunes installed and an iOS de- vice used. Statistics for individual botnets as tracked by Damballa are presented in Table 6. For example, if the botmaster of botnet α bundled our attacks into their pay- load, there would be 75,714 potential victims in 13 cities, within the networks we monitor. α 287,055 75,714 26.38% β 69,895 12,517 17.91% γ 49,138 10,216 20.79% δ 16,236 3,232 19.91% ε 13,732 2,662 19.39% ε 5,024 1,182 23.53% ζ 4,554 944 20.73% η 4,377 929 21.22% θ 4,231 834 19.71% ϑ 4,067 806 19.82% Table 6: Statistical analysis of the top 10 botnets with highest number of infected CIDs on 10/12/2013. vices used from the same CID; and for 23% of all bots, there are both Windows iTunes installed and an iOS de- vice used. Statistics for individual botnets as tracked by Damballa are presented in Table 6. For example, if the botmaster of botnet α bundled our attacks into their pay- load, there would be 75,714 potential victims in 13 cities, within the networks we monitor. Date Setbots Setbots ∩SetiOS Setbots ∩SetiOS ∩SetiTunes 10/12 473,506 142,907 (30.63%) 112,233 (23.70%) 10/24 452,003 134,838 (29.83%) 104,225 (23.06%) 10/27 442,399 134,271 (30.35%) 104,075 (23.53%) 10/28 461,144 138,793 (30.10%) 105,056 (22.78%) 10/30 467,579 141,242 (30.21%) 102,795 (21.98%) Table 7: Measurement results summary, October 2013. Bob Paper Summary on Mobile Security in 2014 January 13, 2015 28 / 55
29. ASM: A Programmable Interface for Extending Android Security5 Take-away Message: The authors propose an Android Security Modules (ASM) framwork, which provides a programmable interface for defining new reference monitors for Android. 5Stephan Heuser, Intel CRI-SC at Technische Universität Darmstadt; Adwait Nadkarni and William Enck, North Carolina State University; Ahmad-Reza Sadeghi, Technische Universität Darmstadt and Center for Advanced Security Research Darmstadt (CASED) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 29 / 55
30. ASM: A Programmable Interface for Extending Android Security Motivations: diverse goals, but use similar security hooks and mechanisms Table 1: Classification of authorization hook semantics required by Android security enhancements Android Package Sensors / Fake System Content File Network Third Party System ICC Manager Phone Info Data Providers Access Access Extension MockDroid [6] XManDroid [7] TrustDroid [8] FlaskDroid [9] CRePE [10] Quire [12] TaintDroid [14] Kirin [15] IPC Inspection [18] AppFence [19] Aquifer [22] APEX [23] Saint [24] SEAndroid [29] TISSA [37] cently, Google adopted the UNIX-level portion of the SEAndroid [29] project into AOSP. However, Android security is significantly more complex than simply medi- ating UNIX system calls. Nearly all application commu- nication occurs through Binder IPC, which from a UNIX The Package Manager Service (PMS) is also frequently modified to customize application permissions. Per- missions are also occasionally customized by modify- ing the interfaces to device sensors and system content providers containing privacy sensitive information (e.g., Bob Paper Summary on Mobile Security in 2014 January 13, 2015 30 / 55
31. ASM: A Programmable Interface for Extending Android Security Proposed System Hook Invocation 9/26/2014 ASM - Android Security Modules 10 Applications Linux Kernel ASM User ASM Provider ASM Enterprise System ContentProviders (e.g. contacts) Query Callback Protection Event (query contacts) Hook ASM Bridge 3rd Party App WhatsApp ASM LSM SELinux LSM Android OS Bob Paper Summary on Mobile Security in 2014 January 13, 2015 31 / 55
32. ASM: A Programmable Interface for Extending Android Security Example Use Case (published in ASIACCS ’14) ConXSense Context Aware Access Control 9/26/2014 ASM - Android Security Modules 17 • Goal: Context-aware access control • Context-aware access control enforcing policies by user context profiling • Includes access control on sensors (e.g., GPS and camera), sensitive information (e.g., contacts) and apps • ASM based implementation: ConXSense ASM Context Profiler User Interface ASM Callback Service Location Info BT Sensing User Input WiFi Sensing System ContentProviders ActivityManager Service CameraService LocationManager Service Hook Hook Hook Hook ConXSense [ASIACCS 2014] Bob Paper Summary on Mobile Security in 2014 January 13, 2015 32 / 55
33. Driving Apps to Test Third-Party Component Security6 Take-away Message: The system leverages the structure of Android apps to improve test hit rate and execution speed. 6Ravi Bhoraskar, Microsoft Research and University of Washington; Seungyeop Han, University of Washington; Jinseong Jeon, University of Maryland, College Park; Tanzirul Azim, University of California, Riverside; Shuo Chen, Jaeyeon Jung, Suman Nath, and Rui Wang, Microsoft Research; David Wetherall, University of Washington Bob Paper Summary on Mobile Security in 2014 January 13, 2015 33 / 55
34. Driving Apps to Test Third-Party Component Security Motivation: is this app vulnerable to Facebook access token attack [Wang13] navigate through the app to open Face login page provide login credentials and click “Log in” examine network messages between the app, the app server and Facebook server Monkey? code coverage semantical input custom controls and UI elements are note visible in the current screen crashing apps by overly stressing the UI Bob Paper Summary on Mobile Security in 2014 January 13, 2015 34 / 55
35. Driving Apps to Test Third-Party Component Security Android apps’ structure static path pruning dynamic node pruning directed self-execution Brahmastra vs. Monkeys A 1 E 1 E 2 E 3 E 4 E 5 A 2 A 3 A 4 P 12 P 34 Brahmastra vs. Monkeys E 4 E 5 A 3 A 4 P 34 A 3 Brahmastra vs. Monkeys E 4 E 5 A 3 A 4 P 34 A 3 Bob Paper Summary on Mobile Security in 2014 January 13, 2015 35 / 55
36. Peeking into Your App without Actually Seeing It: UI State Inference and Novel Android Attacks7 Take-away Message: Android GUI frameworks by design can potentially reveal every UI state change through a newly-discovered public side channel - shared memory. Demos: https://sites.google.com/site/uistateinferenceattack/demos 7Qi Alfred Chen, University of Michigan; Zhiyun Qian, NEC Laboratories America; Z. Morley Mao, University of Michigan Bob Paper Summary on Mobile Security in 2014 January 13, 2015 36 / 55
37. Peeking into Your App without Actually Seeing It: UI State Inference and Novel Android Attacks UI State Inference Attack unprivileged apps can infer the foreground activity in real time no permission request Underlying Causes Android GUI framework design leaks UI state changes through a publicly-accessible side channel shared-memory side channel affects all popular OSes: Android, iOS, MacOS, Windows Bob Paper Summary on Mobile Security in 2014 January 13, 2015 37 / 55
38. Peeking into Your App without Actually Seeing It: UI State Inference and Novel Android Attacks Attack general steps A'single'bit'' of"information" Attack"General"Steps 10" Activity' transition' detection Activity' inference UI'state' hijacking NewlyQdiscovered' SharedQmemory'' side'channel Other'side'channels' (e.g.,'CPU,'network' activity) UI'state'based'attacks: Camera' peeking Bob Paper Summary on Mobile Security in 2014 January 13, 2015 38 / 55
39. Peeking into Your App without Actually Seeing It: UI State Inference and Novel Android Attacks Finding: shared virtual memory size changes are correlated with Android window events. •  Finding:"shared"virtual"memory"size"changes" are"correlated"with"Android"window"events 11" Shared"virtual" memory"size" in"public"file" /proc/pid/statm Proportional' to'window' size Window' popQup Window' close Bob Paper Summary on Mobile Security in 2014 January 13, 2015 39 / 55
40. Peeking into Your App without Actually Seeing It: UI State Inference and Novel Android Attacks Finding: activity signature and activity transition graph Activity"Inference •  Activity'signature"+"Activity'transition'graph 14" Training*phase*(offline): Attacking*phase*(online): Trigger'Activity' transition' automatically Activity' transition' graph' Collect' transition' feature'data' Trigger'Activity' transition Transition' model Activity' signature Activity' inference'result' Collect' transition' feature'data' Bob Paper Summary on Mobile Security in 2014 January 13, 2015 40 / 55
41. Summary of USENIX Security ’14 [iOS]: vulnerability [ASM]: protection framework [BRAHMASTRA]: automate detection method [UI INFER]: attacks Bob Paper Summary on Mobile Security in 2014 January 13, 2015 41 / 55
42. TOC 1 Conference Coverage 2 IEEE S&P 3 USENIX Security 4 CCS ’14 5 ACSAC ’14 6 NDSS ’15 Bob Paper Summary on Mobile Security in 2014 January 13, 2015 42 / 55
43. OAuth Demystified for Mobile Application Developers8 Take-away Message: study the OAuth protocol documentation that aims to identify what might be ambiguous or unspecified for mobile developers study over 600 popular mobile apps to understand how well developers fulfill the authentication and authorization goals in practice what can go wrong? different redirection mechanisms (304 and intent) lack of application identity client-side protocol logic 8Eric Chen, Yutong Pei, Shuo Chen, Yuan Tian, Robert Kotcher and Patrick Tague (CMU) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 43 / 55
44. Semantics-Aware Android Malware Classification Using Weighted Contextual API Dependency Graphs9 Take-away Message: to battle transformation attacks, we extract a weighted contextual API dependency graph as program semantics to construct feature sets. 9Mu Zhang, Yue Duan, Heng Yin and Zhiruo Zhao (Syracus) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 44 / 55
45. TOC 1 Conference Coverage 2 IEEE S&P 3 USENIX Security 4 CCS ’14 5 ACSAC ’14 6 NDSS ’15 Bob Paper Summary on Mobile Security in 2014 January 13, 2015 45 / 55
46. Scippa: System-Centric IPC Provenance on Android10 Take-away Message: The paper design an extension to the Android IPC mechanism (Binder), which established IPC call-chains across application process to defend againse confused deputy attacks and intent hijacking. System API Deputy Requester Requester Notify() Send Text Send Text Figure 1: Permission re-delegation attack. The requester does not have the text message permission, but the deputy does. The deputy also defines a public interface with a Notify method, which makes an API call requesting to send a text message. When the requester calls the deputy’s Notify method, the system API will send the text message because the deputy has ty of Provenance Information. Due to mes- hing, provenance information is currently only app components that are executed in the con- iving IPC thread. Thus, the first requirement hensive solution is to extend Android’s app pagate IPC provenance information to all app A particular challenge to be addressed in this identify the correct IPC context of each thread. hread, for instance, usually handles workloads y multiple IPC threads. Hence, its current IPC nds on the IPC thread it is currently serving. System-Centric IPC Call-chains. By de- provides apps with the UID of their direct ver, when considering the indirections in An- -based ICC, this information is insu cient for ntify the initiator of incoming requests. This econd requirement: it is necessary to establish App A App B App C trans#1 = {payload, chain=[A]} trans#2 = {payload, chain=[A,B]} reply#2 = {payload} reply#1 = {payload} *reply#1 One-way pseudo reply Two-way reply Figure 5: Call-chains during recursive Binder IPC calls. Binder Kernel Module Transaction #1 *from_parent *to_parent *from_thread *to_thread callchain = [A] App A Binder Data Binder Thread #A1 *transaction_stack *proc Binder Proc A *tsk Linux Tasks Task A NULL NULL 10Michael Backes, Saarland University and MPI-SWS; Sven Bugiel, Saarland University, CISPA; Sebastian Gerling, Saarland University, CISPA Bob Paper Summary on Mobile Security in 2014 January 13, 2015 46 / 55
47. Android Security Framework: Extensible Multi-Layered Access Control on Android11 Take-away Message: The paper introduces the Android Security Framework (ASF), a generic, extensible security framework for Android that enables the development and integration of a wide spectrum of security models in form of code-based security modules. BOB: remember ASM: A Programmable Interface for Extending Android Security in USENIX Security ’14? App System Service/App User-space Virtual Filesystem Api Discretionary Access Control LSM Hook Private/Public Resource Privileged Resource API Permisson check Privileged Functionality Kernel space syscall syscall Dex (DVM) Native Code Binder IPC Middleware Framework Middleware API Middleware Sub-Module Middleware Hook checkAccess Inlined RM Kernel API Kernel Sub-Module checkAccess Proprietary self-contained channel (e.g., sysfs, socket, ...) LSM Framework Module Front-end App(s) callModule(Bundle args) Security Framework Reference Monitor Stock Android Security Security Module Figure 2: Android Security Framework architecture. di erent layers of Android’s software stack. LSM and the BSD MAC Framework, for instance, as part of the kernel, 11Michael Backes, Saarland University and MPI-SWS; Sven Bugiel, Saarland University, CISPA; Sebastian Gerling, Saarland University, CISPA; Philipp von Styp-Rekowsky, Saarland University, CISPA Bob Paper Summary on Mobile Security in 2014 January 13, 2015 47 / 55
48. Towards a Salable Resource-driven Approach for Detecting Repackaged Android Applications12 Take-away Message: This system uses spectral clustering and k-means to classify repackaged malware. The features are based on static resources. statistical features structural features activity layout feature event handler feature Coarse-grained Processing Fine-grained Processing Repackaged Apps Android Applications Market 2 Market n Market 1 ... Statistical Features Structural Features Feature Extraction Identifying Major Packages Extracting Statistical Features Extracting Structural Features Core Resources Repackaging Verification Potential Repackaging Groups Checking & Processing Hardened Apps Figure 2: The procedure of our resource-driven approach. We define 15 statistical features, which can be easily re- each dimension ranges in [0, 1]. We calculate F(i) j using the following function: v 12Yuru Shao; Xiapu Luo; Chenxiong Qian; Pengfei Zhu; Lei Zhang (The Hong Kong Polytechnic University) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 48 / 55
49. Morpheus: Automatically Generating Heuristics to Detect Android Emulators 13 Take-away Message: Using such heuristics, an application can check the presence or contents of certain artifacts and infer the presence of emulators. This paper proposes a framework called Morpheus that automatically generates such heuristics. Table 2: Top 10 File, API, and Property Heuristics Artifact Token Type F1 /proc/misc “network throughput” E F2 /proc/ioports “0ff\0:” E F3 /proc/uid stat D F4 /sys/devices/virtual/misc/ cpu dma latency/uevent “MINOR=5” E F5 /sys/devices/virtual/ppp D F6 /sys/devices/virtual/switch D F7 /sys/module/alarm/parameters D F8 /sys/devices/system/cpu/ cpu0/cpufreq D F9 /sys/devices/virtual/misc/ android adb D F10 /proc/sys/net/ipv4/ tcp syncookies E A1 isTetheringSupported() “false” E A2 getAuthenticatorTypes() “AuthenticatorDescription D Table 4: E TP F1 9 F2 9 F3 9 F4 9 F5 9 F6 9 F7 9 F8 9 F9 9 F10 9 A1 9 A2 7 A3 5 A4 7 A5 7 13Yiming Jing; Ziming Zhao; Gail-Joon Ahn (Arizona State University); Hongxin Hu (Clemson University) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 49 / 55
50. TOC 1 Conference Coverage 2 IEEE S&P 3 USENIX Security 4 CCS ’14 5 ACSAC ’14 6 NDSS ’15 Bob Paper Summary on Mobile Security in 2014 January 13, 2015 50 / 55
51. Information Flow Analysis of Android Applications in DroidSafe14 We present DroidSafe, a static information flow analysis tool that reports potential leaks of sensitive information in Android applications. DroidSafe includes an analysis to statically resolve dynamic inter-component communication linkage mechanisms, enabling DroidSafe to precisely track intent- and message- and RPC-mediated information flows that traverse multiple Android components. 14Michael I. Gordon, Deokhwan Kim, and Jeff Perkins (MIT CSAIL), Limei Gilham (Kestrel Institute), Nguyen Nguyen (unaffiliated), and Martin Rinard (MIT CSAIL) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 51 / 55
52. What’s in Your Dongle and Bank Account? Mandatory and Discretionary Protection of Android External Resources15 The current permission-based Discretionary Access Control (DAC) and SEAndroid-based Mandatory Access Control (MAC) are too coarse-grained to protect those resources: whoever gets the permission to use a channel is automatically allowed to access all resources attached to it. To address this challenge, we present in this paper SEACAT, a new security system for fine-grained, flexible protection on external resources. It extends SEAndroid for specifying policies on external resources, and also hosts a DAC policy base. 15Soteris Demetriou (University of Illinois at Urbana-Champaign), Xiaoyong Zhou (Indiana University, Bloomington), Muhammad Naveed (University of Illinois at Urbana-Champaign), Yeonjoon Lee, Kan Yuan, and Xiaofeng Wang (Indiana University, Bloomington), and Carl A. Gunter (University of Illinois at Urbana-Champaign) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 52 / 55
53. EdgeMiner: Automatically Detecting Implicit Control Flow Transitions through the Android Framework16 The callback mechanism provided and orchestrated by the Android framework makes the correct generation of the control flow graph a challenging endeavor. Existing static analysis tools model callbacks either through manually curated lists or ad-hoc heuristics. This work demonstrates that both approaches are insufficient, and allow malicious applications to evade detection by state-of-theart analysis systems. Our implementation, called EDGEMINER, statically analyzes the entire Android framework to automatically generate API summaries that describe implicit control flow transitions through the Android framework. 16Yinzhi Cao (Columbia University), Yanick Fratantonio and Antonio Bianchi (University of California, Santa Barbara), Manuel Egele (Boston University), Christopher Kruegel and Giovanni Vigna (University of California, Santa Barbara), and Yan Chen (Northwestern University) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 53 / 55
54. CopperDroid: Automatic Reconstruction of Android Malware Behaviors17 The System presents a novel unified analysis able to capture both low-level OS-specific and high-level Android-specific behaviors. The System presents an automatic system call-centric analysis that faithfully reconstructs events of interests, including IPC and RPC interactions and complex Android objects, to describe the behavior of Android malware regardless of whether it is initiated from Java or native code execution. 17Kimberly Tam (Royal Holloway University of London), Aristide Fattori (Universita‘ degli Studi di Milano), and Salahuddin J. Khan and Lorenzo Cavallaro (Royal Holloway University of London) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 54 / 55
55. DeepDroid: Dynamically Enforcing Enterprise Policy on Android Devices18 In this paper, we present DeepDroid, a dynamic enterprise security policy enforcement scheme on Android device. DeepDroid is implemented by dynamic memory instrumentation of several central system processes without any firmware modification. By introducing Android Binder intercepting, more fine-grained context-aware supervision policy may be enforced. 18xueqiang wang (Data Assurance and Communication Security Research Center, CAS), kun sun (College of William and Mary), and yuewu wang and jiwu jing (Data Assurance and Communication Security Research Center, CAS) Bob Paper Summary on Mobile Security in 2014 January 13, 2015 55 / 55