Tweet
Tweet

Slide 1

Slide 1 text

Avoiding Android App Security Pitfalls Zach Lanier 1 Monday, July 23, 12

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Agenda • Android Overview • Application Overview • Common Issues • Conclusion 3 Monday, July 23, 12

Slide 4

Slide 4 text

Android Overview 4 Monday, July 23, 12

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

“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

Slide 8

Slide 8 text

Old Exploit Mitigations Executable stack/heap! 8 Non-randomized mmap/ heap/exec! = Monday, July 23, 12

Slide 9

Slide 9 text

Slightly Old Exploit Mitigations Non-exectuable stack/heap since Android 2.3 9 Still no ASLR Monday, July 23, 12

Slide 10

Slide 10 text

Slightly New Exploit Mitigations 10 Ice Cream Sandwich added partial ASLR (heap randomization added in Android 4.0.2+) Monday, July 23, 12

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Current Mitigations (Courtesy Jon Oberheide) 12 Monday, July 23, 12

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

“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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

16 Application Overview Monday, July 23, 12

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Permissions • Others enforced by group membership in the linux kernel • “android.permission.INTERNET” • AF_INET: 3003 21 Monday, July 23, 12

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Common Issues 24 Monday, July 23, 12

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Insecure Storage 33 Derp Monday, July 23, 12

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Case Study: Storage App 42 Monday, July 23, 12

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Case Study: Storage App 44 Monday, July 23, 12

Slide 45

Slide 45 text

Case Study: Storage App 45 Monday, July 23, 12

Slide 46

Slide 46 text

Case Study: Storage App 46 Monday, July 23, 12

Slide 47

Slide 47 text

Case Study: Storage App 47 Intercept response, change values… Monday, July 23, 12

Slide 48

Slide 48 text

Case Study: Storage App 48 Monday, July 23, 12

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Intents 52 Potentially dangerous, could be received by malicious app: Better activity, explicitly specifies component to call: Monday, July 23, 12

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Intents 55 Monday, July 23, 12

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Case Study: App Framework • Custom permissions restricted us from sending Intents to the runtime 57 Monday, July 23, 12

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Case Study: App Framework 59 Monday, July 23, 12

Slide 60

Slide 60 text

Case Study: App Framework 60 Malicious app added JS alert() to “Chess” widget Monday, July 23, 12

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Conclusion 62 Monday, July 23, 12

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Conclusion • Get involved with the OWASP Mobile Security Project! http://owasp.org/index.php/OWASP_Mobile_Security_Project 64 Monday, July 23, 12

Slide 65

Slide 65 text

Questions? [email protected] https://twitter.com/quine http://n0where.org/ Greetz: b7e86886b28786a51e568bb825c7f1e2dc757f6f 787cd9982e2cbc4cd541791311d4014b7ca08816 22c4bfa3b2de272786b1b6cfc0270a5f21b3f7c1 caae4eaaf1aad7842dd04d55ec1b3c19404a5cdd 65 Monday, July 23, 12