Many Mobile Apps Intentionally Using Insecure Connections for Sending Data
A new analysis of iOS and Android apps released to Apple's and Google's app stores over the past five years found many to be deliberately breaking HTTPS protections.
June 11, 2021
Many mobile application developers are deliberately disabling secure HTTPS protections when sending data from a user's browser to the server, often leaving sensitive data open to interception and compromise by attackers in the process.
One reason appears to be to facilitate the delivery of ads via the applications, a new study by Symantec reveals.
Symantec recently analyzed hundreds of thousands of iOS and Android mobile apps released over the past five years to Apple's App Store and Google Play. The exercise showed some 7% of iOS apps and 3.4% of Android apps intentionally break the green padlock that indicates a secure communication channel between the user's browser and the server. Symantec found such apps to be actively sending data to insecure network servers and disabling SSL validation.
Kevin Watkins, principal security researcher at the Symantec Division at Broadcom, which owns the security vendor's enterprise business, says it's not entirely clear why some app developers are intentionally breaking encryption protections and sending potentially private data via insecure SSL connections. "It's hard to say, but [it's] something we are looking into as far as post-research," Watkins says. "We did find a lot of cut and pasting [of] code and classes by app developers as well as guidance from ad networks to disable the locks."
For example, some software development kits — including Google's — explicitly require apps to disable a network security available in iOS 9.0 onward called App Transport Security (ATS) that is designed to prevent insecure network connections. Apple itself allows developers to justify disabling ATS entirely for all or some specific types of content and servers if it views the app developers' reasons for doing so. What users likely don't know is that once a developer is allowed to use insecure channels, it can add any data — including private user data — to the data being sent to their servers, Symantec said in a blog post this week.
"The sheer [number] of apps disabling security, especially for iOS, was surprising," Watkins says. "In particular, Apple's ATS, developed to improve privacy and data integrity, was more or less ineffective due to being turned off and allowed to do so through the app vetting process."
For the study, Symantec analyzed apps released to Google and Apple's official mobile app store between 2017 and 2021. The company's goal was to identify apps breaking the padlock and/or disabling privacy features such as ATS for iOS. Symantec found that over the past five years, the volume of iOS apps exhibiting these behaviors has not declined. In fact, more iOS apps in 2020 (7.6% or 45,158 out of 593,208 apps) exhibited dangerous behavior than in any previous year.
At the same time, the volume of Android apps breaking the padlock have been coming down year over year, from 5% of all apps in 2017 to 2.4% at present. Symantec found that in 2017, a total of 12,243 out of 249,640 Android apps were vulnerable. So far in 2021, about 2,376 out of 99,170 Android apps were found to be breaking the padlock.
Multiple Categories
Symantec discovered that apps breaking the padlock spanned multiple categories. Game apps were the top culprit, with many of them transferring a large amount of public media content and data. Somewhat surprisingly, financial apps, which often contain personally identifiable information and financial data, represented the second biggest category. In one instance, Symantec found a large financial services company's iOS app to be breaking HTTPS protections when users were using their credentials to log in to the service. The issue has been fixed in subsequent versions of the financial service provider's iOS apps, Symantec said.
Unfortunately for users, there's little they can do to find out if an iOS or Android app they are using might be breaking HTTPS protections, Watkins says. "Transparency and visibility into an app actively breaking the SSL lock, unfortunately, is not possible due to the sandbox and security limitations enforced on-device Apple and Google," he says. The best bet for users, he adds, is to use secure access points and reputable VPNs to minimize chances of their data being intercepted when being sent in the clear to an app developer's servers.
Symantec's blog post contains recommendations for app developers on how to avoid unintentionally breaking HTTPS and SSL protections. It notes, however, that little can be done to protect against insecure communications in situations where developers are intentionally choosing to break the lock.
About the Author
You May Also Like