September 30, 2019

Mobile App Security: App Store vs. Google Play

By Himanshu Dwivedi

Data Theorem

A Statistical Security Comparison

Part 1: TLS Enforcement (ATS vs. NSC)

Apple and Google are often compared on a variety of items, including the iPhone vs. Pixel, iOS vs. Android, and supporting features of each. These comparisons often delve deeper into hardware chips, operating systems, battery life, device thickness, user experience, and camera resolutions. Feature comparisons, while interesting, often ignore critical security considerations such as:

1. Which store is enforcing the best enterprise security requirements onto its apps?

2. Which store helps their apps become more secure with practical yet stringent security rules?

3. How often do enterprise security requirements win over consumer features?

There is a lot of hype around app removals from both app stores and A/V vendors (in the case of malware or spyware apps); however, what about legitimate apps used by the enterprise with low levels of security, or no security at all?

It has been predicted by the year 2024, 80% of Internet traffic will be sourced from iOS and Android apps; thus, in 5 short years, young men and women today (ages 12 to 17) will enter the world with “apps” as the gateway to the Internet, not a desktop or mobile browser. The fact that two companies will own a large market share of the “Internet” is not the topic of this paper (but maybe a future one), but rather both companies have an opportunity to enforce security on a broader scale for the greater good.

Because Data Theorem’s can uncover global app security issues, we are sharing the aggregated data analysis of what we are seeing. This paper is part 1 of 434 part series comparing the two app stores, in terms of security and privacy. Please note we are not comparing devices (iPhone vs. Pixel), operating systems (iOS vs Android), nor individual apps, but rather the ecosystem itself: the App Store vs. Google Play.

Round 1: Enforcing TLS on mobile apps

Both the App Store and Google Play have recently developed standards to enforce encryption (TLS) at all times between a mobile app and server side APIs, with limited-to-zero exceptions. For iOS, these rules are called App Transport Security (ATS) and on Android, they are  bundled into something called Network Security Configuration (NSC). While the idea of enforcing TLS at all times may appear to be one small step for a mobile app , universally requiring it on the App Store/Google Play would be one giant leap for all end-users. The rationale behind this is due to the significant attack surface that “data in-transit” exposures have on mobile apps. As a quick recap, data in-transit is all data that is sourced from the mobile app, traversing across public networks, to server side systems/APIs. Each hop on these public networks is an attack surface for hackers. Data in-transit is not a new attack class; however, it has significant wider impact on mobile apps. For example, 15 short years ago, a win32 client app on a Windows desktop would normally run through an office network only. 10 years ago, a web app on a browser would run through an office and home network. Today, we're “always on” and a mobile app is guaranteed to be on an office, home, hotel, coffee shop, restaurant, airplane, neighbor, friend, sidewalk, or any hostile network with a “Free Wifi” sign on the window (figure 1.0):

In a single day, it is now a foregone conclusion that a mobile device, and all the apps on it, will be communicating over an untrusted or hostile network. There should be no debate here. If you produce mobile apps for consumers or for the enterprise, the “network” is one of the largest attack surfaces available to attackers, which may be at the Four Season hotel in Hawaii where F500 executives vacation with their families. If your security relies on the good people of a Hualalai hotel, please ensure they’re on your payroll too; else, ATS and NSC need to play a bigger role in your mobile app security program (figure 2.0):

ATS at a Glance

ATS was first introduced in iOS 9 in order to ensure API connections initiated via NSURLConnection, NSURLSession, UIWebView and WKWebView were always performed over SSL/TLS, using the safest TLS configuration (TLS 1.2 with strong cipher suites). Any connection that did not follow these rules would get automatically blocked by ATS when the app is running on iOS 9+ devices. Apple has also allowed developers to disable some or all of ATS protection using various exemption keys to be added to the App's Info.plist.

At WWDC 2016, Apple announced that they were going to disallow the following ATS exemption keys:

• NSAllowsArbitraryLoads: Disables ATS for all domains

• NSExceptionAllowsInsecureHTTPLoads: Disables ATS for a single domain, allowing insecure HTTP loads to that domain

• NSExceptionMinimumTLSVersion: Enables support for TLS versions that are older than 1.2 for a specific domain

The announcement stated that on January 1st 2017, any app using any of these exemptions would trigger a rejection during the App Store review process. An investigation would then be started by the App Store review team, requiring the developer team to provide a reasonable justification for using these exemptions.

On December 1st, Data Theorem began publishing results from our app store scans in terms of the number of non-compliant apps. As of 12/05/2016, 86.3% of apps were non-compliant. About 3 weeks later on 12/21/2016, which was the day Apple cancelled the deadline, 85.73% apps were still non-compliant. While there were over 10,000 apps that were updated to be compliant in about 16 days, it was simply not enough for Apple to continue and they pulled the plug on the requirement. More information can be found on the following public blog post on ATS compliance: https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforced-2017/.

NSC at a Glance

Android Nougat’s Network Security Configuration (NSC) feature does a lot of things, including the enforcement of SSL/TLS on all of the mobile app's connections. The feature will block most cleartext HTTP traffic initiated by the App, ensuring all data to and from the App has a base level of protection at all times.

Configuring the App to opt out of cleartext traffic ensures connections initiated by the App, and any embedded SDK, will be protected at all times. NSC will also ensure there are no regressions back to plaintext traffic when new versions of the App are released in the future. For example, if a new SDK is added to the App and is leveraging plaintext HTTP to transport sensitive data, the Network Security feature will prevent the data exposure before it happens.

While Google Play will still allow HTTP, Android 10 will not. As of Android 10, any HTTP connection to/from your app will return an error and won’t work. Thus, while NSC may or may not be enforced within your app, Android 10 basically does it for you. Thus, you should enforce NSC to ban HTTP on your app, so all users, not just Android 10 users, are using the optional security settings. Nice work Android, but we’d like to see this as a Goolge Play blocker as well. 

TLS Enforcement Stats Stats on App Store & Google Play

Now that we have a short overview of ATS and NSC, how do both app stores compare in terms of enforcing TLS on mobile apps? Please note that ATS first became available in iOS 9, which was released in Sept 2015, where NSC was first available in Android Nougat, which was released in Aug 2016. Since ATS has been available for over a year longer, we would naturally expect the App Store to have more TLS enforcement than Google Play. However, Google Play is set to catch-up very quickly, as once an iOS app is compliant for ATS, all server-side TLS changes can be used for NSC as well. Thus, all the heavy lifting to enforce NSC will have already been completed by the enforcement of ATS.

My personal plea to the App Store and Google Play:

• App Store: Nate, please re-require ATS sometime in 2020. Apple had the right idea at WWDC 2016, so set a deadline again (and please stick to it). I do understand that over 50% of non-compliant apps is a deal breaker for Apple’s revenue, but with 80% of Internet traffic sourced by mobile apps by 2024, Apple has the power to make some big leaps for all in terms of data in-transit security.

• Google Play: Nice work on Android 10 enforcing HTTPS only; however,  please make it a requirement for all Enterprise apps on Google Play sometime in 2020. 

If both app stores require TLS on all connections by 2020, think how much stronger all consumer and enterprise apps will be for all of us!

One more thing...

Let’s revisit figure 2.0 for a second. Tim Cook and Sundar Pichai, the CEOs of Apple and Google respectively, were having dinner 6 blocks away from Data Theorem’s office in Palo Alto, California. The location of the restaurant is off University Ave, in the heart downtown Palo Alto and near Stanford campus. Using a Wifi Pineapple, Data Theorem would be able to force Mr. Cook’s or Mr. Pichai’s phone to connect to our gateway before reaching real Wifi networks in the area. Both the iPhone and Pixel/Nexus phones search for previously connected Wifi networks and auto-connect to these networks on behalf of the user. For example, if a device has connected to a Wifi Starbucks network in the past, the phone will automatically connect to the Starbucks Wifi network in the future as a convenience for the user. By abusing this feature, a Wifi Pineapple can trick any device by emulating the Wifi network the phone is searching for, forcing the phone to connect to the Pineapple before reaching the real network. For example, if Mr. Cook’s device is looking for a network called “AppleWifi” or if Mr. Pichai’s device is searching for “Google”, the Wifi Pineapple would trick the device by emulating those networks, which essentially puts the hypothetical hostile Data Theorem pineapple in between their devices and the real gateway.

If any of their apps have not enabled ATS or NSC, Data Theorem would be able to capture all clear-text traffic by default and also attempt Man-in-the-Middle attacks on TLS connections (the latter is prevented with SSL Pinning on API endpoints). It should be noted this attack is very old and basic, but when applying to a localized area with high net-worth devices, the results could be very interesting.

To learn more about our approach to mobile app security that goes beyond pen testing for the bare minimum vulnerabilities, take a look at our unified approach with RingCentral.