name: inverse layout: true class: center, middle, inverse --- # Secure Android Application Development Originally: Franziska (Franzi) Roesner<BR> Modified by Jennifer Mankoff CSE 340 Winter 2021 --- layout: false [//]: # (Outline Slide) # Roadmap .left-column[  ] .right-column[ - **Part 1**: What can go wrong? - **Part 2**: How are mobile platforms (Android) designed for security? - **Part 3**: Best practices for mobile (Android) app developers ] --- # What can go wrong? .left-column[  ] .right-column[ “Threat Model” 1: Malicious applications  ] --- # What can go wrong? .left-column[  ] .right-column[ “Threat Model” 1: Malicious applications Example attacks: - Premium SMS messages - Track location - Record phone calls - Log SMS - Steal data - Phishing ] .corner-ribbon.tr[ Tip: Don't do<BR> these things! :) ] --- # What can go wrong? .left-column[  ] .right-column[ “Threat Model” 2: Vulnerable applications Example concerns: - User data is leaked or stolen - (on phone, on network, on server) - Application is hijacked by an attacker ] --- # Mobile Platform Security Features **Goal**: Limit how much harm developers of malicious or buggy applications can do! **A key feature**: Application isolation **Also**: - Secure hardware - Full disk encryption - Modern memory protections (e.g., ASLR) - Application signing - App store review --- # Applications are Isolated .row[ .doublecolumn[ **From each other** - Run in separate processes - With separate UIDs ```java Process.pid #=> 95291 Process.uid #=> 501 ``` ] .column[  ] ] .row[ .doublecolumn[ **And from the system** - No shared accessible file system - No default access to devices ] .column[  ] ] --- # Permissions .left-column50[ ## **Prompts** (time-of-use)  ] .right-column50[ ## **Manifests** (install-time)  ] --- # Android 6.0: Prompts!  - **First-use prompts** for sensitive permission (like iOS). - **Big change**! Now app developers needed to check for permissions or catch exceptions. --- # Best Practices for Mobile App Developers 1. Only ask for the permissions you need 2. Use “internal storage” for sensitive data 3. Validate input from external sources (incl. users) 4. Encrypt network communications 5. Don’t hard-code secrets in source code 6. Use existing cryptography support (carefully) 7. Be careful with inter-process communications 8. Be careful about libraries you include More at [developer.android.com](https://developer.android.com/training/articles/security-tips) --- # 1. Only ask for permissions you need Apps are often “overprivileged”. Early (2011) study:  .footnote[Felt et al.] --- # 2. Use “internal storage” for sensitive data Internal storage is: - Not accessible to other apps - Deleted when the app is installed External storage (like SD cards) are globally readable and writable. Even better, encrypt data (`EncryptedFile`). [Interesting tutorial](https://www.tutorialspoint.com/android/android_internal_storage.htm#:~:text=Internal%20storage%20is%20the%20storage,when%20user%20delete%20your%20application) --- # 3. Validate input from external sources (including users) Check your assumptions about input! - From users, from other apps, from web - Length? Format? - Can cause issues like **buffer overflow attacks** (in native code, not Java) or **SQL injections** (when sent to server) - Be careful with **WebViews** --- # 4. Encrypt network communications **Use HTTPS!** This means user data will not be readable over the network. ```java URL url = new URL("https://www.yourserver.com"); HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection(); urlConnection.connect(); InputStream in = urlConnection.getInputStream(); ``` `HttpsURLConnection` extends `HttpURLConnection` with support for https-specific features. --- # 5. Don’t hard-code secrets in source code CryptoHelper.java ```java private static String SECRET_KEY = "8badcafef00ddead"; ``` .center[  ] CryptoHelper.smali ```java const string v0, "8badcafef00ddead” sput-object v0, Ledu/washington/cs/cse484/simplenotepad/CryptoHelper;->SECRET_KEY:Ljava/lang/String; ``` --- # Instead, use Android Keystore Allows you to create and store secret values. Prevents extraction of keys by: 1. Making sure they never enter the application process 2. Use of secure hardware --- # 6. Use existing cryptography libraries (carefully) **Do not write your own cryptography!** Unless you are a cryptographer :) Follow [recommended best practices](https://developer.android.com/guide/topics/security/cryptography) for parameter selections --- # 7. Be careful with inter-process communications Primary mechanism in Android: **Intents** - Sent between application components e.g., with `startActivity(intent)` - Explicit: specify component name e.g., `com.example.testApp.MainActivity` - Implicit: specify action (e.g., `ACTION_VIEW`) and/or data (URI and MIME type) - Apps specify *Intent Filters* for their components. --- # Eavesdropping and Spoofing .footnote[Chin et al.] Buggy apps might accidentally: - Expose their component-to-component messages publicly -> **eavesdropping** - Act on unauthorized messages they receive -> **spoofing** --- # Permission Re-Delegation .footnote[Felt et al.] .left-column30[  ] .right-column60[ An application without a permission gains additional privileges through another application. Settings application is **deputy**: has permissions, and accidentally exposes APIs that use those permissions. ] --- # 8. Be careful about libraries you include Libraries run in the context of the application –> they can use all the same permissions! .center[  ] --- # Best Practices for Mobile App Developers 1. Only ask for the permissions you need 2. Use “internal storage” for sensitive data 3. Validate input from external sources (incl. users) 4. Encrypt network communications 5. Don’t hard-code secrets in source code 6. Use existing cryptography libraries (carefully) 7. Be careful with inter-process communications 8. Be careful about libraries you include More at [developer.android.com](https://developer.android.com/training/articles/security-tips) .corner-ribbon.tr[ Questions? ] --- # What can go wrong? .left-column50[ “Threat Model” 3: Vulnerable people - Malware - Fake anti-virus - Fake s/w updates - Fake video codecs - Fake account breaches - Passwords - Social networks - Oversharing - Accidental sharing - Fake friends ] .right-column50[  ] --- # Security breaches due to UX More and more security problems are due in part to human factors issues And not systems, networking, or algorithms | Breach | Cause| | --- | --- | | RSA Security, LA Hospital | phishing (+ ransomware)| | DoD malware, StuxNet | USB keys| | Veterans Affairs |stolen laptop| | Mirai botnet| default passwords| | Google blacklists all | misconfiguration| --- # Security breaches due to UX  ---  --- # Phishing is increasing in sophistication Malware and phishing are combined now - Malware attachments (Ex. custom PDF exploits) - Links to web sites with malware (web browser exploits) - Can install keyloggers or remote access software --- # General Strategy for Usable Privacy and Security Three pronged-approach, in order - Make it invisible (where possible) - Offer better user interfaces (affordances, mappings, mental models, etc) - Train users (where necessary) Let’s discuss training first --- # User education is a challenge Users are not motivated to learn about security Security is a secondary task Difficult to teach people to make right online trust decision without increasing false positives “User education is a complete waste of time. It is about as much use as nailing jelly to a wall…. They are not interested…they just want to do their job.” [Martin Overton](http://news.cnet.com/21007350_361252132.html), IBM security specialist --- # User education is a challenge  --- # Fostering good mental models is hard - Instead people tend to have folk models - *Folk models* are mental models that are not necessarily accurate in the real world, thus leading to erroneous decision making, but are shared among similar members of a culture - These lead people to take bad steps to protect themselves - We don't know yet how to foster best mental models --- # But Actually, Users Are Trainable Users can learn to protect themselves from phishing… if you can get them to pay attention to training  - Create “teachable moments”: PhishGuru - Make training fun: Anti-Phishing Phil - Use learning science principles .footnote[ P. Kumaraguru, S. Sheng, A. Acquisti, L. Cranor, and J. Hong. Teaching Johnny Not to Fall for Phish. ] --- # Can use studies to test this .left-column[  ] .right-column[ Evaluating PhishGuru *Hypothesis*: Is embedded training effective? - Study 1: Lab study, 30 participants - Study 2: Lab study, 42 participants - Study 3: Field trial at company, ~300 participants - Study 4: Field trial at CMU, ~500 participants Studies showed significant decrease in falling for phish and ability to retain what they learned ] .footnote[P. Kumaraguru et al. Protecting People from Phishing: The Design and Evaluation of an Embedded Training Email System. CHI 2007. <BR> P. Kumaraguru et al. Getting Users to Pay Attention to Anti-Phishing Education: Evaluation of Retention and Transfer. eCrime 2007. ] --- # Evaluation of Anti-Phishing Phil .left-column30[  ] .right-column60[ Is Phil effective? Study 1: 56 people in lab study Study 2: 4517 people in field trial ] -- .right-column60[ Brief results of Study 1 - Phil about as effective in helping people detect phishing web sites as paying people to read training material - But Phil has significantly fewer false positives overall - Suggests that existing training material making people paranoid about phish rather than differentiating ] --- # Evaluation of Anti-Phishing Phil .left-column30[  ] .right-column60[ Study 2: 4517 participants in field trial - Randomly selected from 80000 people Conditions - Control: Label 12 sites as phish/not then play game - Game: Label 6 sites, play game, then label 6 more, then after 7 days, label 6 more (18 total) Participants - 2021 people in game condition, 674 did retention portion ] --- # Study 2 results  Novices showed most improvement in false negatives (calling phish legitimate) --- # Study 2 results  --- # What can you do?  --- # Exercise - What top two pieces of security advice you would give friend who knows little about computing? <iframe src="https://embed.polleverywhere.com/free_text_polls/pADsWwUmG81QVziXjtgzo?controls=none&short_poll=true" width="800px" height="600px"></iframe>
