name: inverse layout: true class: center, middle, inverse --- # Secure Android Application Development Originally: Franziska (Franzi) Roesner<BR> Modified by Lauren Bricker CSE 340 Winter 23 --- 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? What issues have you heard about with mobile devices? -- count: false May 2020 - "...[StrandHogg 2.0](https://www.forbes.com/sites/daveywinder/2020/05/26/critical-android-data-stealing-security-threat-confirmed-for-almost-all-android-versions-strandhogg-google-update-warning/?sh=eca23fd2c828) also enables hackers to hijack nearly any app ... it allows for broader attacks and is much more difficult to detect (than the original StrandHogg)." -- count: false Oct 2020 - "[MalLocker.B](https://www.forbes.com/sites/daveywinder/2020/10/11/new-android-home-button-phone-bricking-threat-heres-what-you-need-to-know/?sh=19ebf3a03310) can effectively brick phones only with a press of the home button when answering a call" -- count: false April 12, 2021 - [BRATA Malware](https://thehackernews.com/2021/04/brata-malware-poses-as-android-security.html) Poses as Android Security Scanners on Google Play Store ??? These were found with a quick web search. --- # 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-column30[  ] .right-column70[ “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 ] -- count: false .right-column70[ Examples? ] --- # What can go wrong? [Exploring intent-based Android security vulnerabilities on Google Play](https://snyk.io/blog/exploring-android-intent-based-security-vulnerabilities-google-play/) .left-column50[  ] .right-column50[ Intents can carry bundled extra arguments of different types, including serialized objects or even other intents. When a public component receives an intent, it can unpack its extras bundle and use the extracted data to launch other components within the app. ] --- # 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 in the operating system - 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 ] ] ??? We are going to be asking for permissions in our next assignment (Accessibility). --- # Sensing (preview) .right-column-half[  ] .left-column-half[ ## Types of Sensors | | | | |--|--|--| | Clicks | Key presses | Touch | ] --- # Sensing (preview) .right-column-half[  Sampled or Event based input ] .left-column-half[ ## Types of Sensors | | | | |--|--|--| | Clicks | Key presses | Touch | | Microphone | Camera | IOT devices | |Accelerometer | Rotation | Screen| |Applications | Location | Telephony| |Battery | Magnetometer | Temperature| |Bluetooth | Network Usage | Traffic| |Calls | Orientation | WiFi| |Messaging | Pressure | Processor| |Gravity | Proximity | Humidity | |Gyroscope | Light | Multi-touch | | ... | ... | ....| ] ??? --- # Security and Sensing Why is security important with respect to sensing? -- count: false In what situations might it be problematic to have your phone collecting personal data? -- count: false .left-column-half[ [U.S. Troops Accidentally Reveal Secret Bases by Going Jogging](https://www.popularmechanics.com/technology/apps/a15912407/strava-app-military-bases-fitbit-jogging/) (2018) ] .right-column-half[  ] --- # Permissions .left-column50[ ### **Manifests** (install-time)  ] .right-column50[ ### **Prompts** (time-of-use)  ] --- # Example in practice From the Doodle and Layout `AndroidManifest.xml` ```xml <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> ``` Why are these needed? --- # 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.] --- # 1. Only ask for permissions you need [Best practices](https://developer.android.com/guide/topics/permissions/overview#minimal-number): - Request a minimal number of permissions - Associate runtime permissions with specific actions - Consider your app's dependencies (such as libraries that also need permissions) - Be transparent about what you are accessing and why - Make system accesses (like hardware or data) explicit ??? --- # 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. We will see this also in our next assignment (Accessibility). --- # 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[  ] Use the latest release of the libraries! --- # Finding Libraries in Android Apps .left-column50[ - To see what libraries are being used by the app you are creating, open up the `build.gradle` file for your application and look at the dependencies. - Important to keep your Android Studio/gradle/libraries up to date Note: Some of these libraries are for testing purposes, you'd never ship with testing code in place... ] .right-column50[  ] --- # 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)| | Garmin | Ransomware | | DoD malware, StuxNet | USB keys| | Veterans Affairs |stolen laptop| | Mirai botnet| default passwords| | Google blacklists all | misconfiguration| | Northshore School district | Ransomware | ??? Northshore school district Another faculty member --- # Security breaches due to UX  ---  --- # Phishing is increasing in sophistication  --- # 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 Young and old users are the most vulnerable --- # 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?  --- # Advice What top two pieces of security advice you would give friend who knows little about computing? Answer on [Ed](https://edstem.org/us/courses/32031/lessons/51095/slides/286341)
