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

1. On the Effectiveness of API-Level Access Control Using Bytecode Rewriting in Android Presenter: Lu Gong

2. Authors • Students: Hao Hao, Vicky Singh • Professor: Wenliang (Kevin) Du • Dept. of EE & CS, Syracuse University, New York

3. The Conference • AsiaCCS: • ACM Symposium on Information, Computer and Communications Security • Rank C in the CCF recommendation list • Network and Information Security

4. The paper • The first systematic study on the effectiveness of using bytecode rewriting for API-level access control • Cited by: • Structural detection of android malware using embedded call graphs (AISec ’13) • Compac: Enforce Component-Level Access Control in Android (ACM CodaSpy ’14)

5. Background (1/3) • Bytecode rewriting • Use static analysis to identify sensitive API calls • Instrument bytecode to control access • Aim at implement fine-grained access control

6. Background (2/3) • API-Level Access Control

7. Background (3/3) • Method invocation instructions: • invoke-virtual: used to invoke a normal virtual method • invoke-direct: used to invoke either a private instance method or a constructor • invoke-static: used to invoke a static method • invoke-interface: used to invoke an interface method on an object whose concrete class is not known • invoke-super: used to invoke the closest superclass’ virtual method

8. Scoping (1/5) • Two kinds of byte-code rewrite mechanisms: • Put the reference monitor in another service • Put the reference monitor within the application • Only focus on the second approach • Because the first one is fail-safe

9. Scoping (2/5) • Assumption • The application either do not have native code or their native code is blocked from being executed • Reasons • Native code is running in the same process space as DVM • With native code, the app can easily tamper the DVM state, thus byte-code rewriting is useless

10. Scoping (3/5) • Privileged resources • Hardware devices • Kernel data • Data from another process space • Ways to access them • System calls • Inter-process communication

11. Scoping (4/5)

12. Scoping (5/5) • Concealing API usage (the 4th attack) is possible • Java reflection • Dynamic binding

13. Prelude (1/2) • Byte-code rewriting for a non-final class

14. Prelude (2/2) • Byte-code rewriting for a final class

15. Methodology • Study all possible attacks against bytecode rewriting • Give deeper insight into the attacks • Make recommendations on how to defend against these attacks

16. Exploit JNI Naming Convention

17. The JNI naming convention

18. Dynamic binding

19. The problem MyClass.my_Func() Java_MyClass_my_1Func MyClass.my.1Func()

20. Case study

21. Recommendations • If any names starts with numbers, bytecoderewriter should remove the digit as it is illegal.

22. Exploit Java Class Reloading

23. Example

24. Case Study (1/2)

25. Case Study (2/2)

27. Recommendations • Stop application’s Java code from reloading preloaded Android core classes • BaseDexClassLoader.findClass() • DexFile.loadClass()

28. Exploit Customized RPC stubs

29. Case Study (1/2)

30. Case Study (2/2)

32. Recommendation • Apply API-level access control on android.os.ServiceManager.getService() • Alternative: rewrite android.os.Binder

33. Conclusion • Although all problems are fixable, more static analysis and dynamic checking should be performed while byte-code rewriting

34. Thank you