Invetter: Locating Insecure Input Validations in Android Services

1. Invetter: Locating Insecure Input Validations in Android Services Presented by Aman Gupta

2. Introduction • Android is the leading OS of all mobile devices. • Android services manages sensitive resources. • Android enforces access control to manage sensitive information, however, security breaches in access control makes it vulnerable to illegal access. • Android services sometimes incorrectly trust data from apps without any validation.

3. Android System Services System service can be accessed via a set of pre-defined public interfaces using Android Interface Definition Language (AIDL). • AIDL - Stubs and the Proxies. • Stubs - extended by the services to implement their functionalities. • Proxies - encapsulates the remote-process communication (RPC) logic. Client queries Android Service Manager using interfaces defined by proxies. Service Manager has no way of forbidding apps from forging inputs.

4. Input Validation Problems Unlike well defined set of sensitive input. No clarity of input being sensitive which crosses the boundary: • Unstructured - sensitive input validations in system services are difficult to identify. • Ill Defined - no publicly available sources define how sensitive input validations should be carried out in Android services. • Fragmented - sensitive input validations are dispersed in a large number of Java classes. Identity flaws: • Confusion about system security model. • Weakened validations in customized system images.

5. Sensitive Input Validations Weakened Validations in Customized System Images: Customized image removed check before invoking setRingerMode(); any app is free to change ringer mode (eg: silent, vibrate). Confusion about System Security Model: Mistaken trust of app-supplied data. May allow any app to insert new VPN server address into system without authorization.

6. Overall Architecture of Invetter

7. Methodology Instead of relying on identifying all sensitive inputs and their missing validations, we can look for existing sensitive input validations that are misplaced or incomplete, which is a much more tractable problem. The assumption is that the probability that a sensitive input is never validated anywhere in the entire Android codebase is small. Invetter works in 3 steps: • Extraction of system services along with their interfaces and recognition of all input validations using structural analysis. • Extracted validations are passed into learning module to recognize the sensitive input validations. • Look for insecure input validations based on observations.

8. Structure Analysis Recognizes input validation. Leverages inherent structural characteristics in input validation for a method body: • Conditional statements • Comparison of input data • Termination on validation failure Terminates when validation fails: • Throw exception • Return constant • Log and return • Recycle and return

9. Learning based recognition Seeds of Sensitive Input Validations Only input validations which verify the user identity or restrict usage of sensitive resources are considered sensitive.

10. Learning based recognition Machine Learning - association rule mining technique: • If one input validation is adjacent to a sensitive input validation, it is highly likely that this is sensitive input. • Intuition : input validations are often co-located in same service methods. For example. “packageName” and “uid” are often used together to verify app’s identity.

11. Vulnerability Discovery Rule a : Incorrectly trusting app-supplied data • App input is used to check the identity of the caller. Rube b : Incorrectly trusting code in the app process • Sensitive input validation performed in Android SDK and not in Android Service. Rule c : Weaken validations in customized images • Inconsistent validations.

12. Evaluation • Applied to 8 different versions system of AOSP : 5.0, 6.0, 7.0 and 7.1. • 4 system images customized by 3 different venders: Samsung S6, XiaoMi Note2, Huawei P9 and Huawei Mate9. • Static analysis framework ran on CentOs7 with four 8-core 2.0GHz and 192 GB memory.

13. Evaluation • 85 minutes to generate an analysis report • 11.8 hours for 8 images • Most time was consumed in structure analysis phase • 103 possible insecure input validations • 86 true positives • 20 exploitable

14. Evaluation • Native code • Invetter is implemented based on Soot. • 15 services are not analyzed (eg. Camera). • Inferring sensitive inputs • User to kernel and app to service. • Sensitive inputs are challenging to identify. • Sensitive input validations can be learned by co-occurrence. • Recommendations for secure validations • All data from an app including Android SDK should not be trusted. • Validation of app identity should be system controlled. • System level controls shouldn’t be placed in user apps.

15. Conclusion • Unlike explicit permission based access control, we discuss undocumented input validation problems. • Input validations are unstructured, ill-defined, and fragmented, making it challenging to analyze. • Invetter combines machine learning and static analysis to locate sensitive input validations that are problematic in system services. • Invetter was used to 4 different codebase, located 103 insecure validations, of which at least 20 were truly exploitable vulnerabilities by using various attacks such as private escalation and private information leakage.

16. Thank you! Are there any questions?