Privilege Escalation Attacks on Android

redlemonbalmMobile - Wireless

Dec 10, 2013 (3 years and 8 months ago)

101 views

Privilege Escalation
Attacks on Android

Lucas
Davi
, Alexandra
Dmitrienko
,
Ahmad
-
Reza
Sadeghi
, Marcel
Winandy

Ruhr
-
University Bochum, Germany

Presented by Mengtao Sun

SoS

Lab, Lehigh University

Introduction

Introduction


Mobile Phones have been ubiquitous


Smartphones are increasingly prevalent and handling more
tasks


Web browsing and emailing


Multimedia and entertainment


Navigation and LBS


Online purchasing




Targets to Attackers


Various forms of security threats exist on smartphone
platforms


Apple’s
iOS


Apple utilizes a vetting process which is secret


No malware found so far, but a lot of permission misuses and
privacy invasion


Android


A much complete permission system


An opener platform, thus much harder
to control

Contributions


Privilege escalation attacks


Basically,
Android does not deal with transitive privilege usage
,
which allows applications to bypass restrictions imposed by the
permission model


Concrete attack scenario


The paper implies that Android’s permission model fails to
provide reliable boundaries against runtime safety checks

Background

Background: Android Architecture


Usually, Android applications consist of separated modules,
or
components
. Components communicate through the
mechanism of Inter Component Communication (ICC).


Android applications may utilize libraries written in native
code via JNI. Inclusion of native code defeats Java security
model.

Background: Android Security Mechanisms


Sandboxing


Sandboxing isolates applications form each other and from
system resources.


It’s totally different from the notation of “sandbox” we always talk
in SFI. It indeed isolates applications, but more in a “conceptual”
way.


In Android’s sandboxing, each application is assigned a unique
ID.


An application can only have access to files owned by itself, or
files of others which are explicitly announced to be public for
others

Background: Android Security
Mechanisms
(Cont.)


Permission mechanism


Security sensitive interfaces are protected by standard Android
permissions. (e.g. PHONE_CALLS, INTERNET, SEND_SMS)


Required permissions of an app are written in a
Manifest

file.
The permissions should be confirmed by user upon installation.


At runtime, when an ICC call is requested by a component, a
reference monitor checks whether the application has proper
permissions


Application developers may also add reference monitors into their
own applications

Privilege Escalation Attack

Security Deficiencies of Android


The problem: An
application with less permissions (
a non
-
privileged caller
) is not
restricted to access components of a
more privileged application (
a privileged
callee
).


Example:


Proof
-
of
-
concept
Instantiation

Attack Scenario (Assumptions)


A user installs a non
-
malicious, but vulnerable application.
The attacker’s goal is to send messages via SMS by exploiting
this application.


In the experiment, Android Scripting Environment (ASE)
serves as application B


Developed by Google and might be required by many other
applications


Possesses lots of critical permissions


Implemented in a C/S fashion.
Access to the server is not
protected by any permission
.

Attack Implementation


Vulnerable Application (Application A): a standard Java
application using JNI.


Code with a buffer overflow vulnerability:


Attack Workflow

I.
Exploiting the
setjmp

vulnerability through buffer overflow
and launching a return
-
oriented programming (ROP) attack

II.
Invoking the ASE client with a command to send SMS
messages



Specific Instruction Sequences








The
so
-
called Update
-
Load
-
Branch (ULB) serves as a trampoline


Register r6 is updated to move on
sequences

Conclusion & Critique

Conclusion


It’s possible to launch privilege escalation attacks on Android
due to the flaw in Android permission model


Transitive permission usage is allowed unconditionally


Vulnerable applications can be exploited to launch an attack


It’s not good to rely on developers to improve safety


Some other papers follow this way

Critique and Possible Future Work


It’s possible that a malicious application initiates an attack
like this (if accidentally approved by user), but to exploit a
vulnerable application seems much harder


According the papers we discussed before, not many
applications include native code


There are already a plenty of solutions to buffer overflow:
people are sensitive to this now!


The authors point out that using native code through JNI is
dangerous


SFI and JNI security mechanisms on Android platform are
promising

Thanks!

Questions?

Presented by Mengtao Sun

SoS

Lab, Lehigh University