14-829 / 18-638: Mobile Security - Fall 2017

Assignment #1 - Permissions, OS Variations, and Stealing User Data

Due: September 14, 2017

Description: The goal of this assignment is to gain intuition about how Android applications work, how the Android permission model works, and how attackers can do things they're not supposed to be able to do, all through application design. The assignment has three components: 1) read about some specific types of attacks, 2) analyze when these attacks will/won't work, and 3) design a malicious application to try to steal user data. Note that Assignment #2 will build off the material from Assignment #1, so pay attention to the details as you work, and start working on the assignment early to avoid a rush before the deadline.

Tasks:

1. Study Android models - Read through the Android documentation to learn how Android apps work and the details of the Android permission system, paying specific attention to differences between Android OS versions with different security models.
2. Read some papers - Download and read these papers [1, 2, 3]. These papers provide background on common privilege escalation attacks in Android and also provide some intuition on the Android permissions model.
3. Design your malicious app - Using your new-found knowledge about Android version and security models, privilege escalation, and intent- and collusion-based attacks, design an Android app to silently steal your user's Android contact list or some other permission-protected data. The app must:
   • Appear to perform some useful task that is not related to stealing the protected data,
   • Exfiltrate the user's protected data to an off-device destination (e.g., to your email inbox),
   • NOT use any permissions (either manifest or run-time),
   • NOT require root access,
   • Be fully automated and require NO explicit user interaction (meaning the user should be unaware the app is doing anything other than what it was apparently designed for).
   Feel free to make other assumptions, as long as they don't violate the constraints or directly go against the narrative of this assignment, but you must fully explain and justify any such assumptions.
4. Describe your app design - Describe your design and how you would implement the app, paying particular attention to security models and constraints of different Android OS versions. Be sure to describe the apparent functionality of your app and how (and under what conditions) it would successfully steal the target user data. Actually implementing the app is not required, though it is strongly encouraged for better understanding and practice.
5. Play "Would I detect it?" - Now, take on the role of a security-conscious user and suppose you are presented with this app. How difficult would it be to detect the data theft? If the developer only provided you with bytecode? If obfuscation was used? Comment on tools and techniques that you could use for detection in all of these cases.

Deliverables: Each student will submit a written summary of their efforts in the above tasks, namely, a detailed description of your app design, including relevant details about constraints, assumptions, potential issues, and detectability. Include details of how your design achieves each of the given constraints, and comment on the impact of different Android OS version security models. The written summary should be formatted as a single-column document using font size 11 or greater, converted to a .pdf document for submission.

Submission Instructions: Each student should submit a .pdf version of their written summary via Canvas, using the format requested above. All students are expected to complete the assignment on their own; discussion about the assignment is allowed and encouraged, but all design, analysis, and writing tasks must be done individually (i.e., talking is allowed, but not sharing anything written).

Grading: This assignment is worth 20 points: five (5) points for the detailed description of the app design, six (6) points for describing how the constraints are satisfied, four (4) points for discussing OS version issues and additional assumptions needed, and five (5) points for discussing detectability. We reserve the right to take off points for presentation aspects, e.g., incorrect format, unclear writing, etc.