Android buckles down and iOS opens up? Trends in platform security affecting developers

Monday night, NowSecure Director of Research David Weinstein highlighted key trends in Android and iOS security in 2016 and participated in a panel discussion during Security by Design’s event “iOS and Android Security – Differences You Need to Know” in McLean, VA.

Security by Design educates developers about secure development practices by connecting them with security experts at Meetups and other events such as the Security by Design 2016 Conference coming up on October 28. NowSecure is a sponsor and shares the group’s mission to make sure security isn’t an afterthought and help developers think about security throughout the development process.

Android and iOS security year in review

David set the stage for the panel discussion with a presentation covering platform security developments over the past year in both Android and iOS, highlighting developments in Android Nougat and iOS 10, and how those changes foreshadow where each OS is headed and how developers can prepare themselves. Review David’s slides now on SlideShare.

The goal wasn’t to cover the entirety of Android and iOS security developments of the past year but instead focus on those items most relevant to developers. Overall, David highlighted trends suggesting that in general Apple is opening up a little bit while Android is locking down, but both are making progress in improving the security of data.

In particular, many attendees were surprised to learn that Apple intends to fully enforce its App Transport Security (ATS) feature by the end of the year. David had performed a quick static analysis of the top 50 free apps on the Apple App Store and Google Play focusing on ATS and network policy information and shared his findings.

Top 50 free iOS apps:

• 80 percent use NSAllowsArbitraryLoads
• 34 percent use NSExceptionDomains
• Not a single app uses MinimumTLSVersion exception

Top 50 free Android apps:

• Only the Chrome mobile browser uses NetworkSecurityPolicy with isolatedProcess
• No app left the debug flag enabled
• 66 percent set allowBackup to true

Resources

Here’s a list of links to resources relevant to or mentioned by David during his talk:

• Changes in Android Nougat including removing some implicit broadcast intents, file and encouraging better filesystem security hygiene.
• Related blog post about passing file:// URIs “file:// scheme is now not allowed to be attached with Intent on targetSdkVersion 24 (Android Nougat). And here is the solution.“
• National Information Assurance Partnership (NIAP) evaluation of Apple iOS 9.3.2 with MDM Agent using the Common Criteria Evaluation and Validation Scheme (CCEVS) process
• “RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response” is a research paper showing that Google has been applying differential privacy with Chrome for a while, but less publicly than Apple.
• Details about Apple’s Secure Enclave from slides and video of “Behind the Scenes with iOS Security,” a Black Hat USA 2016 presentation by Apple Head of Security Engineering and Architecture Ivan Krstić
• CWAC-NetSecurity backports the Android 7.0 network security configuration subsystem going back to API level 17 (Android 4.2) making it easier to tie an app to particular certificate authorities or certificates, support self-signed certificates, and handle other advanced SSL certificate scenarios.
• Not a lot of apps (perhaps only Chrome) use Android’s Network Security Configuration functionality (Google documentation), but developers should take advantage especially considering tools like CWAC-NetSecurity and OkHttp.
• PermissionsDispatcher is an awesome tool for managing Android Runtime Permissions in apps.

Panel on good mobile development security habits

The panel then discussed a number of good security habits – for example, not relying on security by obscurity. Specifically, a question was asked about incidents whereby attackers insert ad libraries into apps available on the Apple App Store or Google Play, repackage them, and then make them available on third-party markets.

The question was whether code obfuscation made it any more difficult for someone to repackage and release their own version of an app. Attendees learned that obscuring the app’s code doesn’t do much to mitigate this risk. However adding sanity checks within the app’s code to verify it was signed by the right certificate can help, but it won’t necessarily prevent repackaging.

From there the conversation moved into how and whether to obfuscate one’s application. Obfuscation can make it more difficult for someone to understand the inner-workings of an app, but not so much that you break your app. Static analysis tools can apply heuristics about the type of obfuscation applied to the application. Using obfuscation to hide a password or private key in an application isn’t a good idea. David’s thought on the topic was that ideally, a developer won’t rely on hiding how their app works with obfuscation and instead make the app fundamentally secure and tested.

In the end, panelists agreed that how fast the platforms are evolving and adding security features very quickly, and it can be a challenge for developers to keep up. Though on the bright side, over time some things that had to be done manually are being made a bit easier to opt-into thanks to new APIs and other measures.