$30 off During Our Annual Pro Sale. View Details »

Paper Summary on Mobile Security in 2014

Mingshen Sun
October 19, 2015

Paper Summary on Mobile Security in 2014

Paper Summary on Mobile Security in 2014

Mingshen Sun

October 19, 2015
Tweet

More Decks by Mingshen Sun

Other Decks in Research

Transcript

  1. Paper Summary on Mobile Security in 2014
    Bob Mingshen Sun
    January 13, 2015

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide