76 Popular Apps Vulnerable to Data Interception, Warns iOS Security Researcher

[MacRumors]

At least 76 popular iOS apps have been found to be vulnerable to data inception, according to a report from a security expert.

The discovery was made by app binary code scanning service verify.ly and published in a Medium post by Sudo Security Group CEO Will Strafach, who revealed that the apps failed to make use of the Transport Layer Security protocol.

The TLS protocol secures communication between client and server. Without the protection, the apps are susceptible to data interception by an attacker with access to custom hardware such as modified smartphone, which can be used to initiate TLS certificate injection attacks. The interception is possible regardless of whether the developers chose to use Apple networking security feature, App Transport Security.

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.

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.

Apps in the vulnerable list included a number of popular downloads like third-party Snapchat apps, the official app for Vice News, and banking apps for banks based in Puerto Rico and Libya.

Strafach sorted the 76 apps into low, medium, and high risk categories, and says he is reaching out to developers to fix the problems before disclosing the most high-risk apps in the list. According to Strafach, more than 18,000,000 downloads of the vulnerable app versions have been downloaded from the App Store.

Until the issues are dealt with, Strafach advises users of the apps to avoid accessing them over Wi-Fi, as it's harder to exploit the vulnerabilities over a cellular network.

Article Link: 76 Popular Apps Vulnerable to Data Interception, Warns iOS Security Researcher

 

[Pike R. Alpha]

This shows us, again, that Apple's scrutiny is far from perfect. In the mean time use VPN.

 

[Kabeyun]

For the tl;dr crowd, the medium and high security risk app list won't be published for 60-90 days to give the devs time to mitigate the exploit. Bookmark the page and check back then!

This shows us, again, that Apple's scrutiny is far from perfect. In the mean time use VPN.

Not really, or at least this is a misleading statement. Obscure networking attacks are hardly particular to Apple devices. That's what bug bounties and security updates are for in all OS's. But if you prefer the wild west of the uncurated Google play store, go right ahead. But I agree with using a VPN service. Anyone who's fool enough to conduct financial transactions on an open WiFi network...

 

[KALLT]

This shows us, again, that Apple's scrutiny is far from perfect. In the mean time use VPN.

Ironically, I see a few VPN/‘secure browsing’ apps on that list.

 

[Pike R. Alpha]

For the tl;dr crowd, the medium and high security risk app list won't be published for 60-90 days to give the devs time to mitigate the exploit. Bookmark the page and check back then!

Not really, or at least this is a misleading statement. Obscure networking attacks are hardly particular to Apple devices. That's what bug bounties and security updates are for in all OS's. But if you prefer the wild west of the uncurated Google play store, go right ahead. But I agree with using a VPN service. Anyone who's fool enough to conduct financial transactions on an open WiFi network...

There is nothing wrong or misleading about the fact that Apple missed it, and since security is important to all of us... that is why Apple should have caught the problem long before security researchers do (did in this specific case).

 

[nwcs]

Very much expected. Security is a moving target for both developers and consumers. What may be totally secure today could be insecure tomorrow. As for TLS, only TLS 1.2 is currently secure so it's using the right version at the right time. You also have to stay on top of third party libraries and think like an attacker. Troy Hunt shows how easy it is to break the security of a lot of apps. The problem is people don't think like an attacker and so miss critical areas.

 

[sundragon]

This shows us, again, that Apple's scrutiny is far from perfect. In the mean time use VPN.

You've got to be kidding. Nothing is totally secure except turning off the device and putting it in a locker. Compare this to what you see in the Google Play store or outside Google Play in Asia on Android and it's barely comparable.

 

[Kabeyun]

There is nothing wrong or misleading about the fact that Apple missed it, and since security is important to all of us... that is why Apple should have caught the problem long before security researchers do (did in this specific case).

Respectfully disagree. The headline, "15,000 Ford cars involved in accidents this year" implies that there's something about Fords that's a particular problem. It may be true that app clearinghouses like Apple's App Store should scrutinize every line of submitted code, but it's misleading to suggest that this is a particularly Apple problem.

 

[Good User Name]

Inception or interception?

 

[scuac]

This shows us, again, that Apple's scrutiny is far from perfect. In the mean time use VPN.

If you browse through the list of affected apps, you will see a few VPN clients in it.

 

[gnasher729]

I'd like to know what these guys have really been doing. Their blog says:

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.

What does this mean? If it means the app uses HTTP for data that the app should protect through TLS (using HTTPS), then there is indeed nothing that Apple can do about it - like driving your car without a seat belt. The manufacturer puts a seatbelt in the car; if you don't wear it, your fault.

If it means the app used HTTPS and therefore should have been protected by TLS, but somehow the protection didn't work, that would be a nasty problem on Apple's site, and they should be able to do something about it. I suspect the problem is the former.

 

[Bokito]

This is pretty insane. Banking apps without (proper) TLS connection? You've gotta be ******** me.

In the western world banks (or other companies using sensitive data) would immediately be penalized for not securing their users data (and would likely lose a whole lot of customers).

 

[997440]

Respectfully disagree. The headline, "15,000 Ford cars involved in accidents this year" implies that there's something about Fords that's a particular problem. It may be true that app clearinghouses like Apple's App Store should scrutinize every line of submitted code, but it's misleading to suggest that this is a particularly Apple problem.

Respectfully disagree. Because this was a known possibility, Apple should've been giving the issue stricter scrutiny.

From the link in the OP under the heading "Past Occurrences":

[...]
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.
[...]

(There's active links to those instances at the site.)

 

[manu chao]

What does this mean? If it means the app uses HTTP for data that the app should protect through TLS (using HTTPS), then there is indeed nothing that Apple can do about it - like driving your car without a seat belt. The manufacturer puts a seatbelt in the car; if you don't wear it, your fault.

In the medium term, it would be nice if all web connections would use HTTPS, but I don't think Apple could require this at this moment, there are too many third-party web services/web pages (ie, not controlled by the app developer) that don't allow for HTTPS. What Apple should try to enforce is that all web traffic that sends critical information is using HTTPS but that might be hard to test for.

 

[Chupa Chupa]

Respectfully disagree. The headline, "15,000 Ford cars involved in accidents this year" implies that there's something about Fords that's a particular problem. It may be true that app clearinghouses like Apple's App Store should scrutinize every line of submitted code, but it's misleading to suggest that this is a particularly Apple problem.

I don't read anything in the OP's post claiming it's particular to Apple, only that Apple should have caught it. Apple sells its "walled garden" as a safer alternative to the more open Android ecosystem. In fact, data protection and security is a primary selling point of iOS devices. Therefore it has a higher responsibility to throughly vet every app than does Google.

The App Store is more than just a clearing house, it's sold as a "safe house" and the only place to get "safe" iOS apps. Apple warns people that jailbreaking iDevices and installing non-App Store originated apps compromises security. But it seems Apple can't even guarantee security of Apps in it's own store. So whether it's a particular Apple problem or not is irrelevant. No other company is hard selling app security like Apple.

 

[jayducharme]

Oh the irony of Kapersky Safe Browser being a high risk....

 

[mozmac]

Seems like this post says a bunch of stuff without stating the actual problem.

 

[997440]

In the medium term, it would be nice if all web connections would use HTTPS, but I don't think Apple could require this at this moment, there are too many third-party web services/web pages (ie, not controlled by the app developer) that don't allow for HTTPS. What Apple should try to enforce is that all web traffic that sends critical information is using HTTPS but that might be hard to test for.

They did have an end of year (2016) ATS deadline, but have extended it to an unknown date.

Supporting App Transport Security
December 21, 2016

App Transport Security (ATS), introduced in iOS 9 and OS X v10.11, improves user security and privacy by requiring apps to use secure network connections over HTTPS. At WWDC 2016 we announced that apps submitted to the App Store will be required to support ATS at the end of the year. To give you additional time to prepare, this deadline has been extended and we will provide another update when a new deadline is confirmed. Learn more about ATS.

https://developer.apple.com/news/?id=12212016b

 

[manu chao]

They did have an end of year (2016) ATS deadline, but have extended it to an unknown date.
https://developer.apple.com/news/?id=12212016b

Is this for all connections? For example, if an app wants to display a sports score and the webpage that the app reads that score from doesn't support HTTPS, would this mean that if the ATS deadline were enforced, apps wouldn't be able to do this anymore.

 

[AxiomaticRubric]

Very much expected. Security is a moving target for both developers and consumers. What may be totally secure today could be insecure tomorrow. As for TLS, only TLS 1.2 is currently secure so it's using the right version at the right time. You also have to stay on top of third party libraries and think like an attacker. Troy Hunt shows how easy it is to break the security of a lot of apps. The problem is people don't think like an attacker and so miss critical areas.

There is no such thing as "totally secure". Ever.

 

[997440]

Is this for all connections? For example, if an app wants to display a sports score and the webpage that the app reads that score from doesn't support HTTPS, would this mean that if the ATS deadline were enforced, apps wouldn't be able to do this anymore.

Apps are allowed to set "Exceptions".

The beginning several minutes (or transcript) of this presentation might be of interest:
https://developer.apple.com/videos/play/wwdc2016/706/?time=201

 

[ApfelKuchen]

Respectfully disagree. Because this was a known possibility, Apple should've been giving the issue stricter scrutiny.

From the link in the OP under the heading "Past Occurrences":

(There's active links to those instances at the site.)

Do you know how much scrutiny Apple has given this? If not, it's just another example of the "no weakness tolerated" game anyone can play when looking for a reason to criticize their target.

Security efforts, like nearly anything else in life, need to be prioritized - 100% security is an impossibility. The people allocating Apple's security resources have to prioritize the entire list of vulnerabilities, and should give greatest attention to those with the greatest potential impact. The nature of things is that we'll likely know much less about what they have done, than what they haven't done.

This vulnerability in particular? This would be a targeted attack, by an individual/team using a sniffer device. The percentage of the population that would be targeted in such a way is quite small - you don't track John Q. Public with a sniffer for hours or days on end, in hopes of snagging the account number for a $1,000 bank account. This is an attack reserved for high value targets. While it certainly should be addressed, it's not likely to be high on the probability list.

It's clear Apple is aware of the issue. About the only fault I can see here is the extension of the deadline for implementing the necessary change. Yet the fact they extended the deadline means they are cognizant of the issue of continued non-compliance. Just another opportunity for micro-management by web forum.

 

[997440]

Do you know how much scrutiny Apple has given this? If not, it's just another example of the "no weakness tolerated" game anyone can play when looking for a reason to criticize their target.

Security efforts, like nearly anything else in life, need to be prioritized - 100% security is an impossibility. The people allocating Apple's security resources have to prioritize the entire list of vulnerabilities, and should give greatest attention to those with the greatest potential impact. The nature of things is that we'll likely know much less about what they have done, than what they haven't done.

This vulnerability in particular? This would be a targeted attack, by an individual/team using a sniffer device. The percentage of the population that would be targeted in such a way is quite small - you don't track John Q. Public with a sniffer for hours or days on end, in hopes of snagging the account number for a $1,000 bank account. This is an attack reserved for high value targets. While it certainly should be addressed, it's not likely to be high on the probability list.

It's clear Apple is aware of the issue. About the only fault I can see here is the extension of the deadline for implementing the necessary change. Yet the fact they extended the deadline means they are cognizant of the issue of continued non-compliance. Just another opportunity for micro-management by web forum.

You may very well be right with your sense about "micro management" by forum. That wasn't my intention and I'm admittedly not an expert, so maybe my impression is wrong. If so, thank you for correcting me.

Do you think (or know) that it's not technically possible, considering that Apple knows about the possibility that developers could misconfigure the code, that Apple could set up stricter scrutiny for this?

 

[ApfelKuchen]

You may very well be right with your sense about "micro management" by forum. That wasn't my intention and I'm admittedly not an expert, so maybe my impression is wrong. If so, thank you for correcting me.

Do you think (or know) that it's not technically possible, considering that Apple knows about the possibility that developers could misconfigure the code, that Apple could set up stricter scrutiny for this?

Based on what I've read (and we've both read the same stuff), it's not necessarily a matter of stricter scrutiny, but of stricter compliance/enforcement - those apps ought to have come into compliance before Apple's original deadline. Publicity often has a way of ratcheting-up enforcement.

We can't be sure of what the appropriate level of enforcement might be. I tend to go with probabilities - this one seems a low probability risk for the vast majority of users. The trouble is, even low-probability scenarios can defy the odds. Tomorrow, we could learn that some billionaire or Fortune 100 company was successfully attacked, and everyone then assumes they're equally vulnerable. PR nightmare for Apple and those apps.

The warning came from a security consultant. Their job is to warn their deep-pockets clients of potential risks. They reinforce their client relationships (and attract new clients) by identifying and publicizing those potential risks.

One can summarize this entire situation as follows: Apple implements TLS to address a foreseeable vulnerability. Apple sets deadline for developer adoption of TLS. App scanning service identifies apps that have yet to implement TLS. Security consultant publicizes list to warn its clients to not use those apps until they come into compliance.

In short, this isn't about uncovering a previously unknown vulnerability. It's about the state of progress in closing a known vulnerability. If the list contains just 76 "major" apps, it seems that the glass is more than half full.

 

[Kabeyun]

I don't read anything in the OP's post claiming it's particular to Apple, only that Apple should have caught it. Apple sells its "walled garden" as a safer alternative to the more open Android ecosystem. In fact, data protection and security is a primary selling point of iOS devices. Therefore it has a higher responsibility to throughly vet every app than does Google.

The App Store is more than just a clearing house, it's sold as a "safe house" and the only place to get "safe" iOS apps. Apple warns people that jailbreaking iDevices and installing non-App Store originated apps compromises security. But it seems Apple can't even guarantee security of Apps in it's own store. So whether it's a particular Apple problem or not is irrelevant. No other company is hard selling app security like Apple.

Maybe Apple's screeners shoulda woulda coulda, but it's completely fair for Apple to advertise iOS as safest and macOS as most secure vs major competitors. No guarantees ever, they don't claim it, and people don't expect a guarantee.

This problem exists in an order of magnitude greater numbers in Google Play. Your position seems to be that Apple has no right to market its more secure App Store as more secure unless is can guarantee zero exploits. Sure, bad stuff can get through, but if your main concern is the safety of offerings, you'll pick the App Store over Google Play every time. Inversely, Google isn't absolved of dealing with appsec just because they don't advertise it as an asset.