Most Apple apps on iOS 16 bypass VPN connections

Posted:
in iOS edited June 13

Security researchers found that most apps associated with Apple services on iOS 16 will send data that bypasses a selected VPN connection.

VPN setting in iOS
VPN setting in iOS



In March 2020, ProtonVPN found a bug in iOS 13.3.1 and later that could prevent a VPN from fully encrypting traffic. It exposed data and IP addresses by failing to terminate existing network connections once a user activated a VPN.

Then, in August 2022, security researcher Michael Horowitz found that the flaw still existed within iOS.

"It takes so little time and effort to re-create this, and the problem is so consistent, that if [Apple] tried at all, they should have been able to re-create it," he wrote at the time. "None of my business. Maybe they are hoping, that like ProtonVPN, I will just move on and drop it. Dunno."

Recently, a different security researcher looked into the issue and found similar results as Horowitz.

On October 11, Tommy Mysk shared results from his own tests using ProtonVPN and Wireshark, a tool that can intercept and analyze network traffic. He found that DNS requests from some Apple apps on iOS 16 ignore the VPN when communicating back to Apple servers.

We confirm that iOS 16 does communicate with Apple services outside an active VPN tunnel. Worse, it leaks DNS requests. #Apple services that escape the VPN connection include Health, Maps, Wallet.
We used @ProtonVPN and #Wireshark. Details in the video:#CyberSecurity #Privacy pic.twitter.com/ReUmfa67ln

-- Mysk (@mysk_co)



Apple apps that leaked data were Apple Store, Clips, Files, Find My, Health, Maps, Settings, and Wallet. Most apps, such as Health, are responsible for handling private user information.

Mysk found that Android apps behave the same way when handling Google services.

"I know what you're asking yourself and the answer is YES. Android communicates with Google services outside an active VPN connection," he wrote, "even with the options "Always-on" and "Block Connections without VPN. I used a Pixel phone running Android 13."

Some apps, such as Health, use end-to-end encryption to connect to Apple servers. Others use encryption in transit and at rest.

Apple's iCloud encrypts the data as it's being sent to one of its servers, then stores it in an encrypted format along with the encryption keys. End-to-end encryption means that only a user's device can encrypt and decrypt their information, and Apple can't access it.

Whether an attacker could snoop on the non-VPN traffic from these apps to gain insight into the data or user isn't clear. However, given that this issue, and the same behavior on Android as it pertains to Google's services has persisted for several years, it is likely intended behavior for a reason known only to Apple and Google.

How to avoid the VPN issue



The only way to be sure that Apple and Google calls do not "leak" out of the VPN connection, is to use a VPN on a Wi-Fi router. There does not appear to be a way on-device to force the issue. You can compare the latest offers on services that can be used with compatible routers in our VPN deals roundup.



Read on AppleInsider

Comments

  • Reply 1 of 12
    gatorguygatorguy Posts: 24,351member
    Interesting article. At some point I would suspect both Apple and Google will have to explain the reasoning. 

    At least on a Pixel phone using Fi as the carrier with their Virtual Carrier Network I believe that issue has been addressed and mitigated, but not 100% certain. I'll definitely be looking. 
    FileMakerFeller
  • Reply 2 of 12
    It's the "agreement" with the government for a "Back Door".
    danoxwatto_cobraFileMakerFeller
  • Reply 3 of 12
    22july201322july2013 Posts: 3,615member
    failing to terminate existing network connections... once a user activated a VPN.
    Are VPN users really that stupid that they wouldn't think to close and reopen their apps after activating a VPN? I'm pretty stupid, but not that stupid. I wouldn't even consider that a bug. As the doctor said to Arnold at the end of "Last Action Hero," "that's not even a flesh wound."
    macpluspluswatto_cobra
  • Reply 4 of 12
    failing to terminate existing network connections... once a user activated a VPN.
    Are VPN users really that stupid that they wouldn't think to close and reopen their apps after activating a VPN? I'm pretty stupid, but not that stupid. I wouldn't even consider that a bug. As the doctor said to Arnold at the end of "Last Action Hero," "that's not even a flesh wound."
    I don’t think you understand how VPN is supposed to work when enabled/disabled on an operating system level. 
    The proper way is that all apps should disconnect because the operating system forces them, after which they can reconnect (through the VPN tunnel)
    The responsibility of closing/opening apps shouldn’t be of a concern to the user.

    Furthermore, there are services mentioned in the report that go beyond the app level which makes it impossible to plug all the leaks because the user has no control over stopping/starting services, nor should they worry about it.

    Stop defending Apple (and Google for that matter) when it’s so abundantly clear that this is a completely unacceptable situation. 
    muthuk_vanalingamFileMakerFellermacgui
  • Reply 5 of 12
    sdw2001sdw2001 Posts: 18,020member
    failing to terminate existing network connections... once a user activated a VPN.
    Are VPN users really that stupid that they wouldn't think to close and reopen their apps after activating a VPN? I'm pretty stupid, but not that stupid. I wouldn't even consider that a bug. As the doctor said to Arnold at the end of "Last Action Hero," "that's not even a flesh wound."

    I have a VPN, am not stupid, and I never considered it.  I have it more for browsing and things like banking.  It's almost always on, unless I have to turn it off. 
    edited October 2022 watto_cobraFileMakerFellerpulseimages
  • Reply 6 of 12
    sdw2001sdw2001 Posts: 18,020member
    As a VPN user, I have several thoughts about this.  First, Apple and Google need to be transparent about how their products interact with VPNs.  This includes the reasoning behind letting their apps bypass it.  I'd be interested to see if it's a reason beyond "because we want control of the data and we felt like it."  

    Secondly though, it seems to me that in the real world, this is am overblown concern.  Could your data from Apple apps be accessed?  Sure, possibly.  Is it remotely likely? No.  End-to-end encryption is something that is hard to break (though I understand it can be done).  It takes a determined person with the right tools and motivation to do it.  In other words, you would have to be targeted.  If you're someone dealing with sensitive info, or a celebrity, businessperson or other high value target, you better not be relying on consumer VPN tech anyway,  But your average user? When's the last time you heard about someone's iCloud truly being hacked (not just accessed by guessing a weak password or stealing the password).  You could never use a VPN and still stand very little chance of a problem.  I only use mine to reduce all the mass data collection for ad tracking, spam, and to provide an extra layer of security for financial concerns.  
    watto_cobraFileMakerFeller
  • Reply 7 of 12
    dewmedewme Posts: 5,484member
    failing to terminate existing network connections... once a user activated a VPN.
    Are VPN users really that stupid that they wouldn't think to close and reopen their apps after activating a VPN? I'm pretty stupid, but not that stupid. I wouldn't even consider that a bug. As the doctor said to Arnold at the end of "Last Action Hero," "that's not even a flesh wound."
    I don’t think you understand how VPN is supposed to work when enabled/disabled on an operating system level. 
    The proper way is that all apps should disconnect because the operating system forces them, after which they can reconnect (through the VPN tunnel)
    The responsibility of closing/opening apps shouldn’t be of a concern to the user.

    Furthermore, there are services mentioned in the report that go beyond the app level which makes it impossible to plug all the leaks because the user has no control over stopping/starting services, nor should they worry about it.

    Stop defending Apple (and Google for that matter) when it’s so abundantly clear that this is a completely unacceptable situation. 
    My personal expectations about how a VPN “is supposed to work” certainly match what you are saying, but is this a universal and enforceable requirement or a standard that VPNs are required to comply with? Our expectations may be what is considered a de facto standard or a convention, but when you drill down into the compliance and enforcement layer you may discover that there is no accountability at all, or at least nothing beyond a customer or agency deciding that a particular VPN in question does or does not meet their needs because it has some holes in it. I’d imagine (hope!) that government agencies, banking, financial services, etc., verify and validate the VPNs they use before deploying them. I doubt they use VPNs for mainstream applications, but possibly for ancillary things, but even then …

    It’s interesting that both Google and Apple appear to believe that they are free to route what they see as privileged connections around the VPN. The fact that they have not addressed what outsiders have reported as “bugs” may mean that Apple and Google do not see these as bugs at all.

    [Edit:

    There definitely are VPN standards, or at least proposed standards, for VPN protocols under IETF. These are generally defined at the transport level and security authentication level bringing in IPSec standards for things like certificate exchanges. I haven't seen any application level standards defined for VPN that specify the end-to-end requirements or interoperability with the underlying OS. Not surprisingly, one of the biggest advocates for VPN interoperability is Microsoft, likely because they have a huge number of business users who rely on these services working as expected. In all fairness, some of the underlying standards are incomplete and vendors like Microsoft have been forced to flesh out their VPN implementations with proprietary extensions, likely ones that they are now advocating to be incorporated into future VPN standards.

    I suppose companies like Apple and Google see their current efforts to bypass VPN software gateways as necessary in order to continue to provide the quality of service their customers expect on their platforms. It's possible that things like Software Update wouldn't work to Apple's expectations if they tunneled through the VPN. Because Apple/Google saw the VPN standard not providing a provision for something they needed, and they have no control over the 3rd party VPN vendor, they bypassed it entirely. If Apple/Google owned the VPN service they would have come up with a proprietary solution that stayed inside the VPN and would be in the same position as Microsoft.

    Not trying to apologize for Apple/Google, but they are probably just trying to keep their stuff working as expected and aren't doing an end-around on the VPN for nefarious reasons. ]  

    I believe there needs to be more transparency from the industry as a whole to fully explain what customers should expect when something is advertised as being a VPN product. It may be useful to have a consumer focused certification agency akin to UL, CSA, or CE that tests security related products and assigns them a rating based on the actual security of the service rather than the implied security based on a a broad category name like VPN.

    There are obviously many different reasons why VPNs are used, from allowing users to bypass regional restrictions on content consumption to protecting intellectual property to secure communications. Having security ratings from a certification authority would help customers know what they are buying is what they expect, not something less, which is the current situation.

    I’m also a big fan of Wireshark and its ecosystem. Glad to see it being used to unlock these kinds of mysteries.  
    edited October 2022 watto_cobraFileMakerFeller
  • Reply 8 of 12
    danoxdanox Posts: 3,050member
    Using any Google software platform or device is a no go proposition (hopeless) collecting information about you is their only function in life profitwise. And Apple can do better but won’t because they don’t want to fight the governments of the world a fight they can’t win outside the USA.
    edited October 2022 watto_cobra
  • Reply 9 of 12
    .... ever since Apple introduced Photos with always on tagging I have increasingly been asking if we may reach a point where older macs and software may actually be more secure or at least data opaque than what has been introduced after 2011...?
    FileMakerFeller
  • Reply 10 of 12
    I see it as a trade-off between user experience and security. Turning on a VPN and losing all your session data is a pain, even if you know what's happening and know that you are the one who instigated it. Usage scenarios can differ: do you want to have your VPN on all the time because you don't trust your service provider(s) or do you want to turn it on just for special activities (like logging into a work website)? Some enterprises mandate that all connections from a device must route through the VPN to avoid data leakage - but will then complain that the device is requesting access to non-work services because the user had, for example, YouTube open in the background (ask me how I know).

    It's not acceptable for iOS and Android to bypass the VPN for communications to their own services, but I can understand why they felt the urge to do it. I prefer to think they are trying to avoid the greatest number of issues for the greatest number of users.
  • Reply 11 of 12
    sdw2001 said:
    failing to terminate existing network connections... once a user activated a VPN.
    Are VPN users really that stupid that they wouldn't think to close and reopen their apps after activating a VPN? I'm pretty stupid, but not that stupid. I wouldn't even consider that a bug. As the doctor said to Arnold at the end of "Last Action Hero," "that's not even a flesh wound."

    I have a VPN, am not stupid, and I never considered it.  I have it more for browsing and things like banking.  It's almost always on, unless I have to turn it off. 
    Which VPN do you use? 
  • Reply 12 of 12
    I see it as a trade-off between user experience and security. Turning on a VPN and losing all your session data is a pain, even if you know what's happening and know that you are the one who instigated it. Usage scenarios can differ: do you want to have your VPN on all the time because you don't trust your service provider(s) or do you want to turn it on just for special activities (like logging into a work website)? Some enterprises mandate that all connections from a device must route through the VPN to avoid data leakage - but will then complain that the device is requesting access to non-work services because the user had, for example, YouTube open in the background (ask me how I know).

    It's not acceptable for iOS and Android to bypass the VPN for communications to their own services, but I can understand why they felt the urge to do it. I prefer to think they are trying to avoid the greatest number of issues for the greatest number of users.
    VPN supposes to be about security first-and-foremost in the sense that it doesn’t care for UX. It’s simply a protocol. 
    If there would be worries on the UX front about losing sessions, the operating system could warn the user accordingly when turning it on or off (“turning on VPN may….. are you sure?”).
    However, once it’s turned on (and in fact most people keep it on), there should be no consequences to sessions at all, similarly to keeping it off all the time (it’s just the change from on/off or off/on that could impact sessions). Nor is there any reason for individual services or apps to ignore the VPN tunnel. This is just a huge flaw and there are 0 excuses for it. 
    edited October 2022
Sign In or Register to comment.