Avoiding Android App Security Pitfalls

Presented at Mobile+Web DevCon

Transcript

1. Avoiding Android App Security Pitfalls Zach Lanier 1 Monday, July 23, 12
2. Intro • Zach Lanier • Security Researcher with Veracode • the “CH” in TEAM JOCH (Jon Oberheide is the “JO”) • (Net | Web | Mobile | App) pen tester type • Recovering consultant • ex-CISSP 2 Monday, July 23, 12
3. Agenda • Android Overview • Application Overview • Common Issues • Conclusion 3 Monday, July 23, 12
4. Android Overview 4 Monday, July 23, 12
5. Android Overview • Base platform • ARM core (typically) • Linux 2.6.3x - 3.0.x kernel • Native libraries • libc, WebKit, OpenSSL, etc. • Dalvik VM • Register-based VM • Runs dex bytecode • Applications • Developed in Java • Run on Dalvik VM • Linux process 1:1 5 Monday, July 23, 12
6. Android Overview • Fragmented versions :( • Various choke points (OEMs, carriers, etc.) mean bugs don’t get fixed (app, system kernel, etc.) 6 Chart source: developer.android.com (Data current as of July 2, 2012) Monday, July 23, 12
7. “Sandboxing” • “Sandboxed” by standard UNIX uid/gid • Generated unique per app at install time • High-level permissions restricted by Android runtime framework 7 Monday, July 23, 12
8. Old Exploit Mitigations Executable stack/heap! 8 Non-randomized mmap/ heap/exec! = Monday, July 23, 12
9. Slightly Old Exploit Mitigations Non-exectuable stack/heap since Android 2.3 9 Still no ASLR Monday, July 23, 12
10. Slightly New Exploit Mitigations 10 Ice Cream Sandwich added partial ASLR (heap randomization added in Android 4.0.2+) Monday, July 23, 12
11. Current Exploit Mitigations • Full ASLR w/PIE added in 4.1 (Jelly Bean) for most system binaries • Position Independent Executables = random base address for program, strengthening ASLR • RELRO + BIND_NOW • RELRO: Reordering of ELF sections, read-only GOT, etc. • BIND_NOW: load all executable sections at runtime; helps assists RELRO 11 Monday, July 23, 12
12. Current Mitigations (Courtesy Jon Oberheide) 12 Monday, July 23, 12
13. Current Exploit Mitigations • dmesg_restrict & kptr_restrict (added in 4.1) • dmesg_restrict: prevents unprivileged users from reading dmesg or klogctl (kernel log) buffer (wherein kernel information, useful in exploit dev, might be exposed) • kptr_restrict: prevents exposure of sensitive kernel pointer addresses (which would also be useful in exploit development) 13 Monday, July 23, 12
14. “Weak” ASLR • Zygote pre-forking model • Java processes inherit VM from zygote • Same mappings across all Java apps • Performance vs. security trade-off • Most ARM CPUs are 32-bit • No need to address more than 4GB physical • 32-bit ASLR can be brute-forced 14 Monday, July 23, 12
15. Future Mitigations • Code signing? • Ensure that only signed code w/app is what’s running (i.e. no [remote] retrieval and loading of new code) • Additional hardening of system libraries (e.g. bionic) 15 Monday, July 23, 12
16. 16 Application Overview Monday, July 23, 12
17. 17 • Application signing • No CAs • Self-signed by developers • Android Market/Google Play • $25 signup, anyone can publish • Anonymous sign-up possible • Some dynamic app analysis via Bouncer • See also http://jon.oberheide.org/files/summercon12-bouncer.pdf App Distribution Monday, July 23, 12
18. 18 • Android apps contained in “APK” (ZIP file) including: • classes.dex - the Dalvik executable (app code) itself • Application manifest • Resources (images, GUI layout files) • Supporting native libraries • Cryptographic signature files App Structure Monday, July 23, 12
19. Manifest • AndroidManifest.xml • Every APK must include a manifest called AndroidManifest.xml • Manifest presents essential information about an app • Package name, components, linked libraries, permissions, and more 19 Monday, July 23, 12
20. Permissions • At install time, applications explicitly request pre-defined permissions, such as: • Cellular: calls, SMS, MMS • Network: Bluetooth, WiFi, Sockets • Hardware: vibrate, backlight • Location: coarse, fine • App data: contacts, calendars 20 Monday, July 23, 12
21. Permissions • Others enforced by group membership in the linux kernel • “android.permission.INTERNET” • AF_INET: 3003 21 Monday, July 23, 12
22. Permissions • Is current approach granular enough? • Coarse network permissions • More granularity would be useful • Address/CIDR/DNS specification • Fine line between effective granularity and overloading users • e.g. Facebook app • Credentials should only be sent to facebook.com 22 Monday, July 23, 12
23. Permissions • Dalvik VM != sandbox • Not limited to executing dex bytecode • Can pop out of the VM to execute native code • User privileges still enforced • Native code packaged within APKs • Android doesn’t do code signing like iOS 23 Monday, July 23, 12
24. Common Issues 24 Monday, July 23, 12
25. Insecure Transmissions • Complete lack of encryption for transmitted data • Yes, unfortunately this happens often • Weakly encrypted data in transit • Strong encryption, but ignoring security warnings • Ignoring certificate validation errors • Falling back to plain text after failures 25 Monday, July 23, 12
26. Insecure Transmissions • Real World Example: Google ClientLogin Authentication Protocol • Authorization header sent over HTTP • When users connected via WiFi, apps automatically sent the token in an attempt to automatically synchronize data from server • Sniff this value, impersonate the user • See also: http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/ catching-authtokens.html 26 Monday, July 23, 12
27. Case Study: Foursquared • Foursquare client for Android • Foursquare is a location-based social network • Source available under Apache 2.0 license 27 Monday, July 23, 12
28. Case Study: Foursquared • Foursquare API supports HTTP Basic Auth and OAuth… • OAuth includes signatures for transactions, helps prevent replay attacks, etc. • Guess which one foursquared used 28 Monday, July 23, 12
29. Case Study: Foursquare • That’s right. HTTP Basic Auth…over plaintext transport • There’s a CWE for that! • CWE-311: Missing Encryption of Sensitive Data (including credentials) 29 Monday, July 23, 12
30. Insecure Transmissions • Why is this a problem? Well, a lot of people use Foursquare • Well, maybe not you, but everyone else! • Most applications “prefer” WiFi to cell radio...ergo trivial interception of creds • Credential re-use by users exacerbates this • Funny enough, Foursquared had OAuth support • But it wasn’t actually used/enabled 30 Monday, July 23, 12
31. Insecure Transmissions • Ensure that all sensitive data leaving the device is encrypted • This includes data over carrier networks, WiFi, and even NFC • When security exceptions are thrown, it’s generally for a reason…don’t ignore them! 31 Monday, July 23, 12
32. Insecure Storage • Android devices isolate applications’ filesystem data stores through Unix permissions • Note: rooted device -> all bets are off • Leaving USB debugging enabled, say for a lost phone, is an opportunity for access 32 Monday, July 23, 12
33. Insecure Storage 33 Derp Monday, July 23, 12
34. Insecure Storage • Default mode for files created through Java (files, databases, shared prefs, etc.): • Files created through native code inherit Zygote’s umask: 0000 34 Monday, July 23, 12
35. Insecure Storage • Public example: • Skype (April 15, 2011) - multiple, sensitive files with insecure permissions, including DB with all account information (including personal info) 35 Source: AndroidPolice.com Monday, July 23, 12
36. Insecure Storage • Store ONLY what is absolutely required • Never use shared storage areas lacking access control (i.e. SD card) • Leverage secure containers and platform provided encryption APIs • DON’T MAKE CLASSIC CRYPTO MISTAKES • Do not assign world readable or world writeable permissions to files, databases, sharedprefs, etc. 36 Monday, July 23, 12
37. Information Leakage: Logs • Logs are a good source of information leaks Example of a user tapping a link in an SMS/MMS message, firing an Intent to start the browser and go to a site • Trivial example, but easily retrievable information • A rogue app may request android.permission.READ_LOGS 37 Monday, July 23, 12
38. Information Leakage: Logs • Example: app with strict SSL cert validation and pinning (meaning we couldn't MITM) still leaked structure of POST request in the logs • Easy to then create custom client -> attack the webserver 38 Monday, July 23, 12
39. Information Leakage • Never log credentials, PII, or other sensitive data to system logs • Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content • Debug your apps before releasing them to observe files created, written to, or modified in any way • Carefully review any third party libraries you introduce and the data they consume • Test your applications across as many platform versions as possible 39 Monday, July 23, 12
40. Case Study: Storage App • Multi-platform application for storing and retrieving music, videos, documents, and more • Android, BREW, BlackBerry, and fat web browser • Proprietary, binary-only 40 Monday, July 23, 12
41. Case Study: Storage App • Simple crash in storage quota viewer • Divide-by-zero error leads to DoS • Attacker must successfully intercept and modify server response for this to happen • A bit more difficult since this tends to occur over the carrier’s network, but WiFi is still an option 41 Monday, July 23, 12
42. Case Study: Storage App 42 Monday, July 23, 12
43. Case Study: Storage App • Diddling with “Digital Rights Management” • App supported sharing of video, audio, image content with your contacts • Enforces “DRM” on “protected” files • Often copyrighted or premium content • Enforcement occurs based on the value of an attribute in the file’s XML manifest • Effectively under the user / attacker's control 43 Monday, July 23, 12
44. Case Study: Storage App 44 Monday, July 23, 12
45. Case Study: Storage App 45 Monday, July 23, 12
46. Case Study: Storage App 46 Monday, July 23, 12
47. Case Study: Storage App 47 Intercept response, change values… Monday, July 23, 12
48. Case Study: Storage App 48 Monday, July 23, 12
49. Case Study: Storage App • The “DRM” is basically enforced within the client, predicated on the response from the server • And that response can be intercepted and modified -> “DRM” bypass • CWE-807: Reliance on Untrusted Inputs in a Security Decision 49 Monday, July 23, 12
50. API Related Issues • Isolation/sandbox “forces” components to interact via API • “Intent” message objects used to interact with Activities, Services, and BroadcastReceivers • Think “IPC” • Intent objects bear attributes defining their destination, action, pertinent data, etc. • Reference monitor in Android checks permission labels of caller and callee components 50 Monday, July 23, 12
51. Intents • Applications’ activities must have an “intent-filter” and the “android:exported” attribute to be invoked by other applications • For sensitive actions, developers can require the callee to bear custom permissions • Further restrict requests for permissions, ex. by setting “protectionLevel=signature” • When invoking activities, target components should be granular/explicit 51 Monday, July 23, 12
52. Intents 52 Potentially dangerous, could be received by malicious app: Better activity, explicitly specifies component to call: Monday, July 23, 12
53. Intents • Applications can register BroadcastReceivers to receive broadcast (Intent) messages • This could include receivers the sending app didn’t expect or want to receive a message • Restrict messages only to receivers bearing specific permissions when calling sendBroadcast() • Avoid sending highly sensitive data in broadcast messages! 53 Monday, July 23, 12
54. Intents • Don’t forget that Intents are another potential point of input • Sanitize input! • Control access! • Handle exceptions! • iSEC Partners’ “Intent Fuzzer” app reveals a lot of poor exception handling in even the most basic fuzzed Intents 54 Monday, July 23, 12
55. Intents 55 Monday, July 23, 12
56. Case Study: App Framework • Cross-platform framework for HTML/JS “widgets” (think “small applications”) • WinMo, Android, etc. • “Write once, run anywhere” 56 Monday, July 23, 12
57. Case Study: App Framework • Custom permissions restricted us from sending Intents to the runtime 57 Monday, July 23, 12
58. Case Study: App Framework • But, other (malicious) apps can clobber widget content! • CWE-276: Incorrect Default Permissions • So we wrote a malicious app to do just that 58 Monday, July 23, 12
59. Case Study: App Framework 59 Monday, July 23, 12
60. Case Study: App Framework 60 Malicious app added JS alert() to “Chess” widget Monday, July 23, 12
61. Case Study: App Framework • Developers didn’t couple widget runtime and widget management app via IPC • Developers didn’t understand things like sharedUserID • Allows apps to share the same UID/GID, granting access to (otherwise protected) app data store (amongst other things) • Devs sidestepped filesystem perm model by making a custom shared data directory 61 Monday, July 23, 12
62. Conclusion 62 Monday, July 23, 12
63. Conclusion • Avoid storing sensitive data (especially in plaintext and without proper access control) • BE AWARE of system nuances (filesystem perms, memory issues) • Think about the permissions your app really needs (requesting more than necessary?) • Leverage security facilities provided by the platform! • Remember that bugs in components you use can affect the security of your application (Flash, WebKit, OpenSSL, libc, etc.) 63 Monday, July 23, 12
64. Conclusion • Get involved with the OWASP Mobile Security Project! http://owasp.org/index.php/OWASP_Mobile_Security_Project 64 Monday, July 23, 12
65. Questions? zlanier@veracode.com https://twitter.com/quine http://n0where.org/ Greetz: b7e86886b28786a51e568bb825c7f1e2dc757f6f 787cd9982e2cbc4cd541791311d4014b7ca08816 22c4bfa3b2de272786b1b6cfc0270a5f21b3f7c1 caae4eaaf1aad7842dd04d55ec1b3c19404a5cdd 65 Monday, July 23, 12