Download as PDF, PPTX
Uploaded bySam Bowne
CNIT 128 8: Mobile development security
This document discusses threat modeling and guidelines for securing mobile applications. It covers conducting threat modeling as a pencil-and-paper exercise to identify security risks and prioritize mitigations. Guidelines are provided for both native mobile apps and mobile web apps, including storing sensitive data securely, authenticating to mobile services, securing communications, and preventing information leakage. Platform-specific guidelines are also outlined for iOS and Android.
More Related Content
Similar to CNIT 128 8: Mobile development security
CNIT 128 8: Mobile development security
- 1. Ch 8: MobileDevelopment Security CNIT 128: Hacking Mobile Devices Revised 4-12-17
- 2. App Security Constraints •Built-in security features of the mobile platform • Possibility of device theft
- 3. Mobile App ThreatModeling
- 4. Threat Modeling • Apencil-and-paper exercise • Identifying security risks • Helps developer identify most critical risks • Focus on features and/or controls to mitigate those risks • The alternative is endless, aimless, bug- squashing
- 5. Threat Modeling Technologies •Microsoft Threat Modeling – From 1999 (link Ch 8a) • Trike – Open-source, began in 2006 (link Ch 8b) – More traditional risk management philosophy
- 6. Threat Modeling Technologies •OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) – From CERT (link Ch 8c) • Cigital Threat Modeling – Based on software architecture (link Ch 8d) • P.A.S.T.A. (Process for Attack Simulation and Threat Analysis)
- 7. Similar Approach • Diagramthe app • Understand where information assets flow • Document risks to the assets and security controls • Rank the risks by probability and impact • Remediate and verify highest-scored risks
- 8. Example: Adding aMobile Client to an Existing Web App • New client will support end users and Customer Support Representatives (CSRs) • How do existing threats change when a mobile app is added? – Enumerate threats – Outline assets mobile devices possess – Discuss how the mobile tech stacks create opportunities for threats
- 10. Threats • Web apphacking tools • Bluetooth and 802.11 attacks • Injecting code into a mobile browser – Man-in-The-Browser (MiTB) • Malicious apps – Malware and Trojans • Femtocells – Observe all traffic
- 11. Threats from Phone'sUser • Download your app and reverse-engineer it • Jailbreak the device, subverting controls you depend on • Thieves may steal the device and gain access to the UI and physical interfaces such as USB
- 12. 1. Users asThreats • What evil or insidious things could a user do? – Steal encryption keys or credentials from apps – Reverse-engineer apps • What obnoxious or stupid things could a user do to cause trouble?
- 13. Other Device "Owners"as Threats • Other stakeholders – App store account owner – App publisher, who provides the user experience and access to mobile services – Mobile carrier, e.g. AT&T – Device manufacturer: Samsung, etc. – App store curator: Apple, Google, Amazon, etc. – Company's IT dept. that administers the device
- 14. Importance of OtherStakeholders • Operate apps and underlying software • Control credentials • Operate services • Carriers and handset manufacturers place apps on the device – May customize the OS – May place code beneath the OS in firmware
- 15. Importance of OtherStakeholders • App store curators control a large portion of the app lifecycle – Packaging and deployment – Update and removal • When stakeholder goals differ – Opportunity for one "owner" to do something that another stakeholder considers a violation of security or privacy – Like collecting and storing personal information
- 16. Assets • Each stakeholderprotects its assets • End-users may value privacy • App publisher and carrier want to collect and use personal and usage information
- 17. Types of Data •Offline access – Available when phone is not connected to a network • Personal data – Contacts, voicemails • Sensor-based data – Location data (GPS and tower telemetry) – Camera and microphone data
- 18. Identity Data • Apppublishers are reluctant to force users to authenticate using small virtual keyboards • Identity data includes – Persistent credentials – Bearer tokens (such as OAuth) – Usernames – Device-, user-, or application-specific UUIDs
- 19. Usernames • If aweb-based service uses a mobile device for "out-of-band" password reset • And a user has an app for that service • Attacker with a stolen phone can reset the password
- 20. Threat Modeling • Derivethe attack surface and potential attacks – List assets and stakeholders – Brainstorm how each stakeholder might cause a security or privacy breach for another • Prioritize attacks by likelihood and impact • Implement mitigations • Use the list of attacks to drive Secure Software Development Lifecycle
- 21.
- 22. Threat modeling • Mobileapp has two main components – Mobile client – Mobile Web services that support it • Both can be attacked
- 23. Native APIs orMobile Web? • Apps written specifically for the platform, using native APIs – Take full advantage of the platform's features – User interface consistent with platform • Mobile Web apps – Same as web app, but optimized for a smaller screen • Cross-platform mobile development frameworks try to provide the best of both worlds
- 24. Device and RuntimeEnvironment Integrity • How can an app ensure that the OS hasn't been modified? – Or even the app itself? • Mobile Device Management – Provides some assurance • App integrity protection – Anti-debugging and code obfuscation
- 25. Limitations of IntegrityAssurance • If device is jailbroken or rooted – Environment can lie about what's happening • Mobile Application Management (MAM) – Some provide private app stores – For closed-loop provisioning, patching, uninstallation, monitoring, and remote data wipe • Maintaining/Patching your App – The app store is the main channel for updates
- 26. Secure Mobile AppGuidelines
- 27. Secure Mobile AppGuidelines
- 28. Secure Mobile AppGuidelines • Web app security – OWASP Top Ten • Create a walled garden – Requests to Web app should parse the user-agent string to detect mobile requests – Redirect traffic to mobile interfaces/services – Don't serve mobile apps same content as computers – Legacy content may be aggressively cached by mobile browsers
- 29. Secure Mobile AppGuidelines • Reduce session timeout for mobile devices – Greater risk of MiTM attacks – Greater risk of device theft • Use a secure JavaScript subset – Remove eval(), square brackets, "this" – Secure JavaScript subsets:
- 30. The Dangers ofSquare Bracket Notation • It can even lead to remote code execution – Link Ch 8f
- 31. Secure Mobile AppGuidelines • Mask or Tokenize Sensitive Data – Mobile devices have aggressive data caching – Increased risk of data exposure – Replace sensitive data with an alternate representation "mask" or "token"
- 32. Secure Mobile AppGuidelines • Storing sensitive data on the device – Avoid storing sensitive data when possible – Places to store data, strongest to weakest • Security hardware • Secure platform storage • Mobile databases • File system
- 33. Mobile Device SensitiveData • Personal data – Contacts, pictures, call data, voicemails, etc. • Sensor-based data – GPS, camera, microphone • Identity data – Persistent credentials – Bearer tokens (like OAuth) – Usernames – Device-, user-, or application-specific UUIDs
- 34. Security Hardware • SecureElement (SE) microprocessor – Used for mobile payment systems – Accessed using existing smartcard standards • ISO 7816 (contact) • ISO 14443 (contactless) – Considered fairly secure – Locks out after 5 to 10 failed PIN attempts • When used for a virtual wallet – BUT general-purpose apps don't have access to the SE
- 35. ISO 14443: MIFARE •Used by BART and Boston T system • MIFARE Classic used a 48-bit key • Several vulnerabilities have been found
- 36.
- 37. Secure Platform Storage •Apple's keychain – SQLite database – Protected by an OS service that limits access – Keychain items can only be accessed by the app that stored them • And other apps from the same developer • BUT root user can read the keychain
- 38. Keychain Weakness • Rootuser can read everything in the keychain – Link Ch 8l
- 39. Android KeyStore • Intendedto store cryptographic keys • Has no inherent protection mechanism such as a password • Apps must provide a mechanism like this to protect sensitive information; – Password from user – Use Password-Based Key Derivation Function 2 (PBKDF2) to generate an AES key – Encrypt data with AES
- 40. Mobile Databases • Databasecan be encrypted with a single secret with third-party extensions to SQLite – SEE, SQLCipher, CEROD • Apparently innocent data may expose personal identity – Such as images • SQL injection attacks are possible – Via intents or network traffic – So use parameterized queries
- 41. File System Protectionsin iOS • Default encryption of files on the data partition • Centrally erasable metadata • Cryptographic linking to a specific device, so files moved from one device to another are unreadable without the key • Enabled by default in iOS 5 and above • Apple's iOS Security White Paper (link Ch 8m)
- 42. File System Protectionsin Android • Files stored in internal storage are private to the app that created them – Unless the app changes the default Linux file permissions or uses MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE • Files stored in external storage (such as SD cards) are accessible to all applications • Android 3.0 and later provides file-system encryption
- 43. • From March2, 2015 – Link Ch 8o
- 44. Authenticating to MobileServices • As previously covered, OAuth and SAML make it possible to avoid storing or using a password in your mobile app – As if any developers cared...
- 45. Always Generate YourOwn Identifiers • Apps have used existing identifiers like – IMEI number, MAC address, phone number, etc. • To identify users and devices • But what happens when a device is stolen or sold? • Also such identifiers often lack secrecy and entropy – Phone number is often publicly listed on Facebook, etc.
- 46. More Recommendations • Implementa Timeout for Cached Credentials – Good for security but inconvenient – Rarely done • Secure Communications – Use Only TLS – Direct HTTPS communications resist man-in- the-middle attacks including sslstrip • Validate Server Certificates
- 47. Use Certificate Pinningfor Validating Certificates • Adds another step to verifying a server certificate • Compares the certificate to a trusted copy of the certificate included in the app • Exploits the special relationship between the app and the server • The app can be more secure than a Web browser because it knows which server it should be connecting to
- 48. WebView Interaction • WebViewCache Threats – May contain sensitive web form and authentication pages – If a user chooses to save credentials in the browser, they are in the cache – WebView cookies database could be used to hijack sessions with banks and other websites
- 49. WebView Interaction • WebViewCache Mitigations – Disable autocomplete on all sensitive form inputs – Set no-cache HTTP header on server – WebView object on the client side can be set to never save authentication data and form data – Use clearCache() method to delete files stored locally on the device – On Android, you must delete files explicitly because clearCache() doesn't erase them all
- 50. WebView Interaction • WebViewCache Mitigations – To reduce the risk from cached cookies, set up a session timeout on the server – Cookies should never be set to persist for a long time – To clear cookies on the client, use the CookieManager or the NSHTTPCookieStorage classes – On iOS, use NSURLCache to remove cached responses
- 51. WebView and JavaScriptBridges • On Android, protect against reflection- based attacks by targeting API 17 or above • On older devices: – Only use addJavaScriptInterface if really needed – Develop a custom JavaScript bridge with shouldOverrideUrlLoading – Reconsider why you need a bridge and remove it if feasible
- 52. WebView Countermeasures • Ifan app uses a custom URI scheme – Be careful what functionality is exposed – Use input validation and output encoding to prevent injection attacks
- 53. Preventing Information Leakage •Clipboard – Android and iOS support copy-and-paste – Access to clipboard is fairly unrestricted – Take explicit precautions to avoid sensitive data entering the clipboard – On Android, cell setLongClickable(false) on a field – On iOS, subclass UITextView to disable copy/ paste
- 54. Preventing Information Leakage •Logs – Watch for sensitive data in system and debug logs – Or the device driver dmesg buffer – Any Android app with the READ_LOGS permission can view the system log – On iOS, disable NSLog statements – X:Y coordinate buffers can expose PINs or passwords
- 55.
- 56. iOS-Specific Guidelines • Keyboardcache – MDMs can add an enterprise policy to clear the keyboard dictionary at regular intervals – Users can do this with Settings, General, Reset, "Reset Keyboard Dictionary" • Enable full ASLR – Usually on by default – Sometimes developer must explicitly code for it
- 57. iOS-Specific Guidelines • CustomURI Scheme Guidelines – Use openURL instead of the deprecated handleOpenURL – Validate the sourceApplication parameter to restrict access to the custom URI to a specific set of applications – Validate the URL parameter; assume it contains malicious input
- 58. iOS-Specific Guidelines • Protectthe stack – With gcc, use –fstack-protector-all to enable Stack Smashing Protection (SSP) – Apple LLVM compiler automatically enables SSP • Enable automatic reference counting – Automatically manages memory for Objective-C objects and blocks – Reduces chance of use-after-free vulnerabilities – And other C memory-allocation problems
- 59. iOS-Specific Guidelines • Disablecaching of application screenshots – iOS captures the screen when an app is suspended – Such as when user clicks the Home button or the Sleep/Wake button – Or the system launches another app – It does this to show transition animations – This could capture sensitive data – Prevent this by specifying a splash screen to display upon entering the background
- 60.
- 61. Android-Specific Guidelines • TraditionalC++/Java secure coding – Google recommends using Java rather than C ++; it's more secure • Ensure ASLR is Enabled – C and C++ must be compiled and linked with PIE
- 62. Secure Intent Usage •Public components should not trust data received from intents • Perform input validation on all data from intents • Use explicit intents where possible • Only export components if necessary • Create a custom signature-protection-level permission to control access to implicit intents • Use a permission to limit receivers of broadcast intents • Don't put sensitive data in broadcast intents
- 63. Android-Specific Guidelines • SecureNFC guidelines – Don't trust data from NFC tags – Perform input validation – Write-protect a tag before it is used to prevent it from being overwritten • Test your controls – Make sure every setting is really working