Open in app

Sign in

Write

Sign in

76 Popular Apps Confirmed Vulnerable to Silent Interception of TLS-Protected Data

Will Strafach
9 min readFeb 6, 2017

During the development of our web-based mobile app analysis service verify.ly, it was essential to have a clear understanding of the most common security issues which plague mobile applications today. Automatically scanning the binary code of applications within the Apple App Store en-masse allowed us to get a vast amount of information about these security issues.

I will present some findings within this post which I believe to be in the public interest, related specifically to iOS applications which are vulnerable to silent interception of (normally) TLS-protected data while in use. Our system flagged hundreds of applications as having a high likelihood of vulnerability to data interception, but at this time I will be posting details of the connections and data which I was able to fully confirm as vulnerable using a live iPhone running iOS 10 and a “malicious” proxy to insert an invalid TLS certificate into the connection for testing.

UPDATE: A follow up has been posted here.

Highlights

  • During the testing process, I was able to confirm 76 popular iOS applications allow a silent man-in-the-middle attack to be performed on connections which should be protected by TLS (HTTPS), allowing interception and/or manipulation of data in motion.
  • According to Apptopia estimates, there has been a combined total of more than 18,000,000 (Eighteen Million) downloads of app versions which are confirmed to be affected by this vulnerability.
  • For 33 of the iOS applications, this vulnerability was deemed to be low risk (All data confirmed vulnerable to intercept is only partially sensitive analytics data about the device, partially sensitive personal data such as e-mail address, and/or login credentials which would only be entered on a non-hostile network).
  • For 24 of the iOS applications, this vulnerability was deemed to be medium risk (Confirmed ability to intercept service login credentials and/or session authentication tokens for logged in users).
  • For 19 of the iOS applications, this vulnerability was deemed to be high risk (Confirmed ability to intercept financial or medical service login credentials and/or session authentication tokens for logged in users).
  • The App Transport Security feature of iOS does not and cannot help block this vulnerability from working.
  • Within the “Solving the Problem” section, I present a simple short-term mitigation to this vulnerability class which any end user will be able to make use of.

Explaining the Risk

There are many potential avenues along the network path for this vulnerability class to be exploited in order to intercept and/or manipulate data. While it is certainly possible for an ISP or a rogue Wi-Fi provider to be the attacker, that is unlikely in most Western regions, and is not considered to be a serious risk. With regards to this sort of man-in-the-middle attack, a common analogy makes a reference to using the Wi-Fi connection within a coffee shop, or an airport, but lately I am starting to dislike the analogy as it is easy to misunderstand and minimize the perceived potential for attack. The truth of the matter is, this sort of attack can be conducted by any party within Wi-Fi range of your device while it is in use. This can be anywhere in public, or even within your home if an attacker can get within close range. Such an attack can be conducted using either custom hardware, or a slighly modified mobile phone, depending on the required range and capabilities. The best similar and well-understood form of attack to this would be the ability to read data from credit cards at a close range.

Vulnerable Applications (Low Risk)

This is a listing of iOS applications which are vulnerable to this attack, but pose a low risk to end users if data is intercepted. Additionally included are iOS applications which have already been publicly disclosed as vulnerable.

Vulnerable Applications (Medium and High Risk)

Please see this follow up post.

Past Occurances

This class of vulnerability has been an issue in the past for various noteworthy iOS applications. Gathering information via open source, I was able to find 26 total instances over the past few years. To my knowledge, the mentioned apps are likely to be fixed, unless otherwise noted (This is an assumption based on timeframe, but they were not part of this assessment so I have not 100% confirmed).

Solving the Problem

This class of vulnerability poses a complex problem, as application developers are the only ones who can fully mitigate it. It is derived from networking-related code within iOS applications being misconfigured in a highly unfortunate manner. Due to this, Apple’s “App Transport Security” mechanism will see the connection as a valid TLS connection, as it must allow the application to judge the certificate validity if it chooses to do so. There is no possible fix to be made on Apple’s side, because if they were to override this functionality in attempt to block this security issue, it would actually make some iOS applications less secure as they would not be able to utilize certificate pinning for their connections, and they could not trust otherwise untrusted certificates which may be required for intranet connections within an enterprise using an in-house PKI. Therefore, the onus rests solely on app developers themselves to ensure their apps are not vulnerable.

  • End Users: There is a short term trick which can be used to mitigate this type of vulnerability. The vulnerability is very likely to only be exploited if your connection is flowing over Wi-Fi (whether you’ve joined a public Wi-Fi network, or a determined attacker has force-joined your mobile device onto a rogue network without your knowledge). Therefore, if you are in a public location and need to perform a sensitive action on your mobile device (such as opening your bank app and checking your account balance), you can work around the issue by opening “Settings” and turning the “Wi-Fi” switch off prior to the sensitive action. While on a cellular connection the vulnerability does still exist, cellular interception is more difficult, requires expensive hardware, is far more noticeable, and it is quite illegal (within the United States). Therefore, it is much less plausable for an attacker to risk attempting to intercept a cellular data connection.
  • Companies: If you offer an application in the iOS App Store, consider analyzing builds prior to App Store submission using our verify.ly service. This class of vulnerability and all other possible “low hanging fruits” (vulnerabilities discoverable to a determined attacker who commits 24 hours total analysis time) can be fully detected by performing an automated scan of the binary code and giving you an easy to read report outlining any and all flagged issues, ensuring your customer data is safe.
  • Developers: Be extremely careful when inserting network-related code and changing application behaviors. Many issues like this arise from an application developer not fully understanding the code they’ve borrowed from the web.

Further Investigation

As mentioned earlier, this will be revisited in 60 to 90 days to document responses from affected companies and application fix timelines. Investigation of more applications may also occur, due to hundreds of applications being flagged as being vulnerable (with high confidence), but this would depend on public interest.

Contact

If you have any questions, feel free to reach out to me via Twitter (@chronic).

If you need any sort of mobile application research conducted which requires mass analysis of many applications to retrieve data and/or answer a question, e-mail would be the best way to get in touch (will.strafach@sudosecuritygroup.com).

Security
Privacy
IOS
Appsec
Infosec

--

--

Will Strafach

Written by Will Strafach

3.8K Followers

building great things. breaking others. | infosec, cyber, CANEX, mobile phone (iOS) hacking. | e: will@wstraf.me

Help

Status

About

Careers

Blog

Privacy

Terms

Text to speech

Teams