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:
- Which store is enforcing the best enterprise security requirements onto its apps?
- Which store helps their apps become more secure with practical yet stringent security rules?
- 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 7-10 short years, young men and women today (ages 10 to 15) 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 blacklist the three following ATS exemption keys:
- Disables ATS for all domains
- Disables ATS for a single domain, allowing insecure HTTP loads to that domain
- 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.
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 2017. Apple had the right idea at WWDC 2016, so set a deadline again (and please stick to it). I do understand that 85% 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 make some big leaps for all in terms of data in-transit security.
- Google Play: Adrian, please require NSC’s TLS feature by sometime in 2018. Assuming the App Store will enforce ATS sometime 2017, all the heavy lifting will be completed for Android developers.
If both app stores require TLS on all connections by 2018, think how much stronger all consumer and enterprise apps will be by Jan 2019!
The Scorecard: ATS vs. NSC
Data Theorem scans the App Store and Google Play on a daily basis. Every month we will post the results here, so bookmark this page to see how each app store is progressing as it pertains to TLS enforcement between mobile apps and their server-side APIs:
- Round 1
- April 1, 2017
- ATS Compliant Apps on the App Store: 19.32%
- NSC Compliant Apps on the Google Play: 00.01%
- May 1, 2017
- ATS Compliant Apps on the App Store: 19.62%
- NSC Compliant Apps on the Google Play: 00.33%
- June 1, 2017
- ATS Compliant Apps on the App Store: 19.64%
- NSC Compliant Apps on the Google Play: 00.40%
One more thing...
Before we wrap up, 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 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...