Mobile Application Security Code Reviews

Mobile App Security Code Reviews
Security BSides Las Vegas 2011

© Copyright 2011 Denim Group - All Rights Reserved

Instructor
Dan Cornell
dan@denimgroup.com
@danielcornell

www.denimgroup.com
www.smartphonesdumbapps.com
(210) 572-4400

© Copyright 2011 Denim Group - All Rights Reserved 1

My Background
• Dan Cornell – Founder and CTO Denim Group
• Software developer by background (Java, .NET, etc.)

• Denim Group
– Build software with special security, performance, reliability
requirements
– Help organizations deal with the risk associated with their software
• Code reviews and application assessments
• SDLC consulting
• Secure development training – instructor-led and e-Learning


Agenda
1. Introduction and Overview
2. Data: In Motion and at Rest
3. Other Dangerous Inputs
4. Platform-Specific Concerns
5. Conclusions / Questions


1 – Introduction and Overview
• Focus For This Class
• Security Implications for Mobile Applications
• Mobile Application Threat Model
• Testing the Security of Mobile Applications
• Platform Background
– Android
– iOS


Tradeoffs: Value versus Risk
• Mobile applications can create tremendous value for organizations
– New classes of applications utilizing mobile capabilities: GPS, camera, etc.
– Innovating applications for employees and customers
• Mobile devices and mobile applications can create tremendous risks
– Sensitive data inevitably stored on the device (email, contacts)
– Connect to a lot of untrusted networks (carrier, WiFi)

• Most developers are not trained to develop secure applications
– Fact of life, but slowing getting better
• Most developers are new to creating mobile applications
– Different platforms have different security characteristics and capabilities


Smart Phones, Dumb Apps
• Lots of media focus on device and platform security
– Important because successful attacks give tremendous attacker leverage
• Most organizations:
– Accept realities of device and platform security
– Concerned about the security of their custom applications
– Concerned about sensitive data on the device because of their apps
– Concerned about network-available resources that support their apps

• Who has mobile application deployed for customers?

• Who has had mobile applications deployed without their knowledge?
– *$!%$# marketing department…


Generic Mobile Application
Threat Model


Some Assumptions for Developers
• Smartphone applications are essentially thick-client applications
– That people carry in their pockets
– And drop in toilets
– And put on eBay when the new iPhone comes out
– And leave on airplanes
– And so on…

• Attackers will be able to access:
– Target user (victim) devices
– Your application binaries

• What else should you assume they know or will find out?


Testing the Security of Mobile Applications
• IMPORTANT: It is really the system as a whole you care about
– Application plus…
– 3rd party web services
– Enterprise services
– And so on

• The most “interesting” weaknesses and vulnerabilities we find are in
mobile applications’ interactions with supporting services

• Mobile applications are different than web applications
– Can’t just fire up an automated scanner and turn up a bunch of SQL injection and
XSS vulnerabilities
– Usually…


Testing the Security of Mobile Applications
Type of Analysis Activities
Static Analysis
Source Code Source code scanning
Manual source code review
Binary Reverse engineering
Dynamic Analysis Debugger execution
Traffic capture via proxy
Forensic Analysis File permission analysis
File content analysis


Platform Background: Android
• Linux-based operating system
• Applications typically written in Java
• Java compiled to DEX bytecode for the Dalvik virtual machine
– Kind of like a Java virtual machine
– Register-based rather than stack-based


Platform Background:
• UNIX-based operating system
• Applications written in Objective-C


Pandemobium Stock Trader Application
• Android and iOS versions

• Functionality
– Log in
– Track stock tips
– Make stock trades
– Get stock tips
– Share stock tips
• We will use as an example
through the class


2 – Data: In Motion and at Rest
• Local Data Storage
• Consuming 3rd Party Web Services
• Mobile Applications and Enterprise Services


Local Data Storage
• Overview
• Identifying Potential Storage Issues
• Encryption Best Practices


Local Data Storage Overview
• If you store data on the device it can be captured
– How you store the data can impact how easy this is
– But at the end of the day it can be captured
– So be careful what you store on the device. And be careful how you store it

• But what if I encrypt the data?
– Great idea. Where are you going to store the key?

• This is an issue that gets a lot of media attention


Local Data Storage: Android
• Files
– Internal storage (file permissions enforced)
– External storage (no file permissions enforced)
• SQLite Databases
• Shared Preferences
• Web Cache


Android Data Storage

• In Android, every application gets its own uid/gid
– Clever use of the Linux security model
– But external storage does not have permission enforcement

• Default permissions are to be readable and writeable by the app only
– Files
– SQLite databases
– Shared Permissions
– Context.MODE_PRIVATE

• But of course you can override this
– Context.MODE_WORLD_READABLE
– Context.MODE_WORLD_WRITEABLE


Local Data Storage:
• Files
• SQLite Databases
• plist Files
• Keychain
• Web Cache


Android Static Analysis
for Storage Issues
• Android-specific functions for file handling:
– Context.openFileOutput()
– Context.openFileInput()
– Context.getDir()

• Android-specific functions for SQLite database handling:
– Context.openOrCreateDatabase()
– Context.getDatabasePath()
– SQLiteDatabase.openDatabase()


for Storage Issues
• Android-specific functions for Shared Preferences handling
– Context.getSharedPreferences()

• Android-specific functions for cache handling:
– Context.getCacheDir()
– Context.getExternalCacheDir()

• Non-Android-specific functions
– Anything else you would examine in Java
– java.io and the like


for Storage Issues
• File permissions:
– MODE_PRIVATE – generally all right
– MODE_WORLD_READABLE, MODE_WORLD_WRITEABLE – why?

• What is being stored?
• How is it being used?

• World readable/writeable files can be manipulated by malicious
applications


iOS Static Analysis for
Storage Issues
• NSFileManager class
– NSFileProtectionKey attribute
• NSFileProtectionNone – Always accessible
• NSFileProtectionComplete – Encrypted on disk when device is locked or booting

• UIApplicationProtectedDataWillBecomeUnavailable notification
– Fired when application data is about to become unavailable
– References to sensitive files should be dropped


Encryption Best Practices
• Key management is a huge problem
• If encrypted data and the key are stored on the device…

• Android Encryption
– Access to javax.crypto libraries
– Open source options like Bouncy Castle

• iOS Encryption
– Access to common crypto algorithms
– Keychain available for encrypted storage


iOS Keychain
• Allows you to store key/value pairs using iOS protections
• Default: only visible to “owning” application
• Possible values for kSecAttrAccessible:
– kSecAttrAccessibleWhenUnlocked
– kSecAttrAccessibleAfterFirstUnlock
– kSecAttrAccessibleAlways
– kSecAttrAccessibleWhenUnlockedThisDeviceOnly
– kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
– kSecAttrAccessibleAlwaysThisDeviceOnly
• But…
– Clever German researchers found out how to dump non-PIN protected data
– And clever Russian researchers found out how to brute-force the PIN
– Do not store sensitive data on the device


Consuming 3rd Party Web Services
• Overview
• Identifying Services In Use
• Data Communications and Handling Best Practices


Overview of Consuming 3rd Party Web Services
• Interesting apps need to talk to stuff
– And most of that stuff you should not trust

• These are untrusted inputs
– Positively validate them before use

• You do not control what they do with the data
– Be careful what you send


Identifying Services In Use
• Look for URL connections

• Look for network connections

• Look for web controls


Data Communications and Handling Best Practices
• Remember: Mobile devices can talk on lots of different networks

• So use SSL
– Can not observe or change traffic
– DNS concerns

• And force it to be used correctly
– With valid certificates

• Be careful of caching


Android Network Connections
• Android-specific classes:
– android.net.*
– android.net.SSLCertificateFactory
• Make sure server validation has not been turned off

• Java platform classes:
– java.net.URLConnection
– java.net.URL
– And so on…


Android Network Connections
• Included Apache classes:
– org.apache.http.HttpClient
– org.apache.http.HttpPost
– org.apache.http.Response

• WebView component
– Include HTML content in web applications


iOS Network Connections
• CFStream
– kCFStreamPropertyShouldCloseNativeSocket
– kCFStreamPropertySocketSecurityLevel
– kCFStreamPropertySOCKSProxy
– kCFStreamPropertySSLPeerCertificates
– kCFStreamPropertySSLPeerTrust
– kCFStreamPropertySSLSettings
• CFHost
• NSStream
• NSHost
• NSURLDownload
• NSURL
• UIWebView


What to do With 3rd Party Services?
• Largest concern is how they impact YOUR security
– Validate all input
– Be careful how your logic treats the data
– Be careful what you send


Overview of Mobile Applications and Enterprise Services
• If you were a bad guy, would you rather have
– The data on one device
– All the data on the server
– I guess it depends on how advanced and persistent you are…

• These provide a great window into your organization
– Client data
– Transaction data
– And so on…

• The most serious vulnerabilities we find in assessments deal with
apps’ interactions with enterprise services


3 – Other Dangerous Inputs
• Mobile Browser Content Handling


Mobile Browser Content Handling
• Identifying Mobile Browser Content Handlers
• Testing the Security of Content Handlers


Android: Identifying Content Handlers
• Look in AndroidManifest.xml
• Look for <intent-filter> tags:
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme=“the_scheme" />
</intent-filter>

• But what apps export intents?
– http://www.openintents.org/


iOS: Identifying Content Handlers
• Look in Info.plist
• Look for <key>CFBundleURLSchemes</key>
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>the_scheme</string>
</array>
</dict>
</array>

• But what apps handle custom schemes?
– http://handleopenurl.com/


Testing the Security of Content Handlers
• How to reach them?
– Get a user to click: <a href=“the_scheme://stuff?param=value” />
– Get a user to visit a malicious web page:
<iframe src=“the_scheme://stuff?param=value” />

• Approaches:
– Fuzzing
– Targeted attacks


Implementing Secure Content Handlers
• This is remotely-accessible attack surface
• Ask yourself: Do you really need to expose this attack surface?

• Of course you do, think of how cool this will be…

• Treat that as any untrusted input
– Positive validation
– Design logic accordingly


Where Does Tainted Data Come From?
• Android:
– Activity.getIntent().getData()

• iOS:
– handleOpenURL() – Now deprecated
– openURL() – New method – complete w/ naming conflict


Interlude: SQL Injection for Mobile Applications
• iOS and Android both provide built-in access to SQLite databases
• Validate input and properly encode it before including it in SQL queries

• Android
– query(), rawQuery() – Be careful
– compileStatement() – Better, but still be careful

• iOS
– sqlite3_exec() – Be careful
– sqlite3_prepare_v2() – Better, but still be careful
– iOS SQLite has such an elegant syntax, doesn’t it?


But How Bad is SQL Injection in Mobile Apps?
• Probably not as bad as SQL injection for web applications
– Probably

• Remember DREAD:
– Damage Potential
– Reproducibility
– Exploitability
– Affected Users
– Discoverability


4 – Platform-Specific Concerns
• Secure Coding Practices for the iOS Platform
– Buffer overflows and format strings
– Everything old is new again
– Objective-C is a superset of “actual” C – enjoy


Let’s Take Apart Some Apps: Android

• Example of static • axml2xml.pl
– http://code.google.com/p/android-random/downloads/detail?name=axml2xml.pl

binary analysis
• dedexer
– http://dedexer.sourceforge.net/
• Application structure • dex2jar
– AndroidManifest.xml – http://code.google.com/p/dex2jar/

– assets/ • JD-GUI
– res/ – http://java.decompiler.free.fr/

– classes.dex • SQLite Browser
– http://java.decompiler.free.fr/


Other Materials
• www.smartphonesdumbapps.com – Denim Group presentations,
slides and code for mobile application security
• http://software-security.sans.org/downloads/appsec-2011-
files/dhanjani-hacking-securing-next-gen.pdf - SANS APPSEC
SUMMIT 2011 presentation from Nitesh Dhanjani and Sean Pennline
• http://www.slideshare.net/SOURCEConference/david-thiel-secure-
development-on-ios - SOURCE Boston 2011 presentation from David
Thiel from iSecPartners
• McAfee mobile pen testing guidelines:
– http://www.mcafee.com/us/resources/white-papers/foundstone/wp-pen-testing-
iphone-ipad-apps.pdf
– http://www.mcafee.com/us/resources/white-papers/foundstone/wp-pen-testing-
android-apps.pdf


5 – Conclusions and Questions
Dan Cornell
dan@denimgroup.com
@danielcornell

www.denimgroup.com
www.smartphonesdumbapps.com
(210) 572-4400


Mobile Application Security Code Reviews

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Mobile Application Security Code Reviews

Ähnlich wie Mobile Application Security Code Reviews (20)

Mehr von Denim Group

Mehr von Denim Group (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Mobile Application Security Code Reviews