A month before Apple is expected to enforce stricter security requirements for app communications in iOS, enterprise developers don’t seem ready to embrace them, a new study shows.
The study was performed by security firm Appthority on the most common 200 apps installed on iOS devices in enterprise environments. The researchers looked at how well these apps conform to Apple’s App Transport Security (ATS) requirements.
ATS was first introduced and was enabled by default in iOS 9. It forces all apps to communicate with Internet servers using encrypted HTTPS (HTTP over SSL/TLS) connections and ensures that only industry-standard encryption protocols and ciphers without known weaknesses are used. For example, SSL version 3 is not allowed and neither is the RC4 stream cipher, due to known vulnerabilities.
Before ATS, app developers implemented HTTPS using third-party frameworks, but configuring SSL/TLS properly is hard so implementation errors were common. These weakened the protection that the protocol is supposed to provide against traffic snooping and other man-in-the-middle attacks.
Currently iOS provides a method for apps to opt out of ATS entirely or to use it only for specific connections, but Apple wants to change that. At its Worldwide Developers’ Conference in June, the company announced that it will require all apps published on the App Store to turn on ATS by the end of this year.
The requirement won’t be enforced at the OS level, but through the App Store review process. Using some of the ATS exceptions will still be possible, but developers will have to provide a “reasonable justification” for using them if they want their apps to be approved.
During their study, the Appthority researchers found that 97 percent of the analyzed apps — 193 out of 200 — used exceptions and other settings that weakened the default ATS configuration.
“Among the top 200 iOS apps that we analyzed, 166 apps (83 percent) bypass at least some ATS requirements by setting ‘NSAllowsArbitraryLoads’ attribute to ‘true’ in their Info.plist files,” the Appthority researchers said in their report. “However, not all of them bypass ATS requirements for all network connections. For instance, a company can still support ATS requirements for network connections with its domain, while allowing ATS to bypass all other connections.”
Among the apps that didn’t use HTTPS for all of their connections were popular ones like Facebook, Twitter, LinkedIn, Facebook Messenger, Skype, Viber, WhatsApp, Fox News, CNN, BBC, Netflix, ESPN, Hulu, Pandora, Amazon Cloud Player, Word, Excel, PowerPoint, and OneNote, but also utility apps like Flashlight, QR code readers and games.
While it could be argued that some connections don’t need HTTPS because they aren’t used to transfer sensitive data, the Appthority researchers found 10 applications that did send device IDs, email addresses, physical addresses, zip codes, geolocation information and even passwords or secret keys over unencrypted HTTP links.
There are many reasons why developers can’t turn on ATS for all connections and are likely to request ATS exceptions during the app review process. For example, many apps don’t talk only to their developers’ servers, but also to third-party advertising, market research, analytics and image or video hosting services. The use of HTTPS on these external services are out of app developers’ control.
ATS provides fine-grained exceptions like “NSAllowsArbitraryLoadsInMedia,” which can, for example, be used to allow the streaming of video or audio content over HTTP, while encrypting all other connections.
However, based on Appthority’s analysis, it seems that so far developers have preferred using the more generic “NSAllowsArbitraryLoads” which disables ATS for all connections, when dealing with such problems.
The company didn’t find any app that used the “NSAllowsArbitraryLoadsInMedia” or the “NSAllowsArbitraryLoadsInWebContent” attributes to limit the scope of ATS exceptions. It hopes that Apple’s new requirements will change that.
Many apps that do use ATS disable some of its security features. For example, none of the apps analyzed by Appthority used Certificate Transparency, which is available in ATS.
Furthermore, seven of them disabled SSL certificate validation and 46 didn’t use certificate pinning. Thirty-eight apps disabled Forward Secrecy and eight apps set the allowed TLS protocol version to 1.0 or 1.1, even though the secure default in ATS is TLS 1.2.
“We still expect iOS apps with unencrypted data in enterprise environments, even after January 1,” the Appthority researchers said. “When Apple approves such apps for the App Store, there will still be the security risks associated with unencrypted data for some connections, so it’s important for enterprises to have visibility into and management of the risks related to apps with those exceptions.”
