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
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
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
“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
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
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
“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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
quine
lemon
koudaiii
hk_shino
kmwebnet
miyashino
miu_crescent
yoshiiryo1
bengo4com
kobayang
defaultcf
csswizardry
autifyhq
colly
phodgson
afnizarnur
eileencodes
zakiwarfel
marcelosomers
destraynor
chrislema
cromwellryan
chriscoyier
ammeep
bkeepers