Android Security

Paper reading 1


I will post some of the research papers which I have read as a part of the literature survey for my master’s degree thesis:

Security Analysis of Android Factory Resets (AFR)[1]

Introduction

  • Raises doubts against the current security of the factory settings of Android devices
  • Improper sanitization of the data partition leads to exposure/recovery of user credentials due to flawed factory reset

Problem definition

  • The amount of data left behind by flawed implementations
  • The drivers being flawed
  • Critical failures of AFR pointed out by the researchers
    • The lack of Android support for proper deletion of data partition
    • Incompleteness of upgrades pushed to flaws by vendors
    • The lack of driver support for proper deletion shipped by vendors in new devices
    • The lack of Android support in the deletion of internal and external SD card in all SDKs
    • The fragility of full-disk encryption to mitigate problem upto Android v4.4

Contribution of the research paper

  • The first comprehensive study of AFR, by analyzing the security of 21 devices from 5 different vendors running Android v2.3x – v4.3
  • Discovered critical failures of the Android OS and/or vendor shipped devices for the secure deletion of user data and account details during AFR .
  • Suggestion for improving for Google and vendors to mitigate the future risks

Mentioned about three ioctl() functions MEMERASE, BLKDISCARD, BLKSECDISCARD,  used for sanitising the data partitions.

Results

  1. The sanitisation of the external storage occurs only if a user selects the additional option “External Storage” or “Secondary Storage” in the AFR
  2. Data partitions store the confidential data about Google and third party apps. It was found that devices which were upgraded from v2.3 to v4.0 doesn’t update the device driver for ioctl to execute BLKSECDISCARD on the logical sanitising functionality from the underlying eMMC.
  3. The phones released with newer version of Android ICS and JB seems to have the same issues as the mobile phone vendor hasn’t provided the updated device drivers of ioctl() to call secure logical sanitization functions.

Suggestions to improve

  1. An app to overwrite the entire partition “bit-by-bit”. But it requires root permission
  2. AOSP supports full disk encryption but it is uses user (4-6 digit) PIN to encrypt the entire data/external partition.

Open research questions

  1. Investigate security of digital sanitisation of very recent devices (models above Android v4.4) after an AFR

ROP is still Dangerous: Breaking Modern Defences[2]

Problem statement:
Failures of existing ROP defense mechanism

Novelty:

  1. Introduces three novel techniques to bypass the existing defense mechanism of ROP attacks.
  2. A baseline set of attacks that can be used to evaluate future ROP defenses
  3. Bypasses the state-of-art ROP defenses including kBouncer and ROPecker

Existing ROP defense techniques:

  1. Call preceded ROP: Normally, every ret instruction returns back to an instruction that immediately follows a corresponding call. ROP attacks deviate from this pattern.
  2. Evasion attacks: Anomaly detection at runtime. ROP attacks tries to make it appear as normal. ROP defenses check if there’s any short gadgets. Discards long gadgets. An attacker can evade this protection by using long gadgets.
  3. History Flushing: Defense inspect limited memory execution history and inspect them for any possible ROP attacks. This could be evaded by overwriting with a fake history

kBouncer

Overview

  1. Inspects last 16 indirect branches taken each time the program invokes a system call
  2. It verifies that all ret instructions in the LBR returned to a call-preceded address.
  3. If the eight most recent indirect branches are all gadget like, the process is killed

Attack overview

  1. Initial exploitation: A traditional ROP payload is mounted in the easiest way discarding the fact that kBouncer is present in the system. Memory is prepared to make syscalls but not yet ready to invoke
  2. Hide the history: Before invoking a system call, history hiding attack is launched. As a side effect, the registered may be clobbered but memory locations remains unchanged. A termination gadget is used to terminate kBouncer’s backward search for gadget like sequences.
  3. Restore the registers and issue system call: After bringing the process into a valid state, the registered are restored into their desired values. Then system call is issued via evasion attack. It is achieved using less than 8 call-preceded gadgets

Requirements for future defenses against ROP

  1. Either the defenses should have access to all the previous history or with the limited history should not be cleared out by the attacker.
  2. Defenses that defend against one specific aspect of ROP must argue that is a necessary component of one

Open research problem

  1. A general purpose defense against ROP attacks
  2. Find the fundamental difference between the ROP attacks and typical program execution

Android Prespective

kBouncer and ROPecker is not yet implemented for Android. Hence Android kernels are vulnerable to ROP attacks.

Dune: Safe User-Level Access to Privileged CPU features[3]

Dune provides applications with direct but safe access to hardware features such as ring protection, page tables and tagged TLB. Dune uses the virtualization hardware in modern processors to provide a process than a machine abstraction. It includes a small kernel module that instantiates virtualization hardware and mediates interactions with kernel and a user level library that helps applications manage privileged hardware features. Applications of Dune: sandboxing, privilege separation, and garbage collection.

Contributions

  1. A design that uses hardware-assisted virtualization to safely and efficiently expose privileged hardware features to user programs while preserving standard OS abstractions.
  2. Evaluates three hardware features in detail and show how they can benefit user programs: exceptions, paging, and privilege modes.
  3. Demonstration of the end-to-end utility of Dune by implementing and evaluating three use cases: sandboxing, privilege separation, and garbage collection

Open research topics

  1. Currently supports x86 CPUs and Intel VT-x. Could be extended to ARM x86 and x64. Requires to create an efficient architecture independent interface of libDune.
  2. Utilities in libDune are not thread safe. Support of libc Signal calls (signal, sigaction)
  3. Android sandboxing could be achieved by implementing Dune (VMX ring3, non root mode) on top of the underlying Linux kernel. ART could run on top of Dune.

References:

[1] http://www.cl.cam.ac.uk/~rja14/Papers/fr_most15.pdf

[2] http://nicholas.carlini.com/papers/2014_usenix_ropattacks.pdf

[3] http://www.scs.stanford.edu/~dm/home/papers/belay:dune.pdf

Advertisements

PREC: Practical Root Containment For Android Devices


Recently, I had come across this paper which was published by professors from NCSU.  Google Play is the new hub of distributing Malwares to the Android devices. A recent survey said that around 70% of the apps in the Google play are malwares. Currently, there’s no robust and 100% accurate mechanism in Google play to detect the presence of Malicious code in the app which a user submits.  PREC can dynamically identify system calls from high-risk components (e.g., third- party native libraries) and execute those system calls within isolated threads. Hence, PREC can detect and stop root exploits with high accuracy while imposing low interference to benign applications.

My understanding

Existing problems

  1. Failure of Google play for detecting malicious applications
  2. Current apps are intelligent enough to detect the emulated environment (Google play test on emulated env)
  3. Environment couldn’t differentiate apps uses third party native codes which may be malicious (not all time)

Contributions of the paper

  1. An architecture for mitigating root exploit malware that hides its existence during dynamic analysis. The approach mentioned in the proposal forces malware to commit to a normal behavior during dynamic analysis (Google play) and malicious attacks are detected and stopped at run time (on device)
  2. A run time, kernel level, system call origin identification mechanism that is used to build a fine grained behavior models for higher anomaly detection accuracy and practical malware containment
  3. Introduced a scalable and robust behavior learning and anomaly detection scheme using self organizing map (SOM) learning algorithm that can achieve both high accuracy and low overhead

During dynamic analysis, PREC records and labels each system call as originating either from third party native code or from Java code.
Current scenario:

  1. All existing malware that exploits root privilege escalation vulnerability uses third party native code
  2. Low level system APIs required by root exploits are not often available to Java code
  3. Program analysis of third party native code is significantly more difficult than Java code or system libraries, hence most malware analysis tools ignore such third party native codes

Design and Implementation details

System call identification

Approach 1: Perform classified system call monitoring by separating the system call originating from high risk third party from the system calls issued by low dangerous Java code.
Cons of approach 1: Java and third party native code uses system provided native libraries to invoke system call. Hence need to differentiate between both.
Approach 2: Dalvik VM notifies Kernel when a thread switches to third party code. The kernel can maintain a flag afterwards.
Cons of Approach 2: Vulnerable to a confused deputy attack:- the kernel cannot determine if the flag change request was from Dalvik VM or third party native code.
Approach 3:A thread based approach: Maintains a pool of special threads called native threads and execute all the third party native functions using these native threads. Malicious code cannot change a native thread to a normal thread. No communication is required between Dalvik VM and Kernel since pool of native thread are created bu PREC at app launch time.
When a Java thread needs to execute a third party native function, the Java thread is suspended and an idle native thread is dynamically selected to execute native function. This native thread is killed only after the native function ends its execution.
Pros:

  1. Kernel tracer can easily identify the system call origins (from Java or native components
  2. The thread based approach isolates only small portion of the application => no need to kill the whole application
  3. PREC can easily incoporate other executions sandboxing mechanims to provide additional security isolation between Java and malicious native code.

Main challenges authors faced

  1. Making run time root exploit containment practically achievable at a low false alarm rate
  2. Imposing low interference to benign applications