[HN Gopher] iOS allows DNS request to escape the VPN tunnel
___________________________________________________________________
iOS allows DNS request to escape the VPN tunnel
Author : nb_key
Score : 138 points
Date : 2022-10-12 14:37 UTC (8 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| lapcat wrote:
| Dupe: https://news.ycombinator.com/item?id=33173163
| nb_key wrote:
| > 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
| khana wrote:
| RetpolineDrama wrote:
| Wallet at least has a semi-plausible non-evil answer: Users who
| kick their VPN on to another country and try to use apple pay
| at checkout will unexpectedly get declined (because the
| purchase would appear to be coming from another country
| perhaps?).
|
| Apple could fix that with proper UI though.
| jaywalk wrote:
| I don't see any reason why Apple Pay would use IP geolocation
| like that when it's running on a device that has GPS.
| bierjunge wrote:
| GPS can be easily spoofed.
|
| Back in the university days, we (me + a few friends) used
| to get some radios and antennas to create a signal stronger
| than the one coming from satellites. It was always fun when
| the semester started and all freshmen were using Google
| Maps to navigate through the campus, but the map always
| showed their location in North Korea. Good ol' times.
| pphysch wrote:
| I thought GPS worked by triangulation? How did you use
| one transmitter to specifically misdirect receivers to
| believing they were in North Korea?
| ballenf wrote:
| > some radios and antennas
|
| Still an impressive feat.
| zikduruqe wrote:
| I'm calling shenanigans. I used to work in a lab where we
| had GPS repeaters to test consumer equipment. That alone
| costs big bucks. And, we had the FAA come down on us big
| time, because our GPS repeater broadcast outside the
| building too far and we got into some hot water.
|
| If you were spoofing GPS campus wide over 1.544 GHz and
| had all your GPS sentences correct, with simple radios
| and antennas... and you hadn't got in trouble with Uncle
| Charlie or the FAA....
| imwillofficial wrote:
| Spoofing GPS is trivial. Getting caught or not is a toss
| of the coin
| zikduruqe wrote:
| Cheating the location on my phone is gravy.
|
| Broadcasting an RF signal to spoof GPS (and especially
| across a campus), that my friend, is not trivial or
| cheap.
| Dylan16807 wrote:
| Trying to set up an alternate 3d volume of GPS space
| sounds very difficult.
|
| But broadcasting a loud signal that tells everyone in
| range that they are at the same exact _point_ doesn 't
| seem too hard to me. Couldn't that even be as simple as
| replaying a single-antenna recording taken somewhere
| else?
| culturestate wrote:
| _> I don 't see any reason why Apple Pay would use IP
| geolocation like that when it's running on a device that
| has GPS._
|
| I don't think contactless Apple Pay actually uses device
| geo[1] for authorization, but it's still worth noting that
| iOS devices without cell connectivity (ie WiFi-only iPads)
| don't have GPS anyway.
|
| You _can_ use Apple Pay on websites in Safari, though,
| which IIRC doesn 't require location permissions to work.
|
| 1. You have to be able to use it in the same places you'd
| use a normal card, which means you can't rely on network
| connectivity of any kind.
| tablespoon wrote:
| > I don't see any reason why Apple Pay would use IP
| geolocation like that when it's running on a device that
| has GPS.
|
| One reason is that GPS doesn't work well (or at all)
| indoors, through cell-tower geolocation should work well
| enough for that case.
| thelopa wrote:
| A compromised device can send a false location or the
| user may have disabled location. Geolocation has
| relatively predictable failures.
| mritzmann wrote:
| Fraud detection happens on the server side. The IP address
| is more reliable than GPS, because the client can fake GPS
| at any time.
| rosnd wrote:
| But Apple Pay doesn't require internet (on the phone).
| exabrial wrote:
| I disagree completely.
|
| * first, a purchase shouldn't require an internet connection.
| Humans have been doing commerce for millennia without it, and
| we have sophisticated pub/priv key schemes to figure this all
| out.
|
| * second, it's a security hole. It's either a VPN or it's
| not.
| emptyparadise wrote:
| iOS devices are leaky as hell. I once tried blackholing all
| requests besides those to a VPN service on a router level, and
| even then my iPhone would just fall back to mobile data for
| notifications and other Apple services.
| account-5 wrote:
| I can't even imagine the uproar that would be a thread about
| Google doing this!
| joshstrange wrote:
| https://mullvad.net/en/blog/2022/10/10/android-leaks-
| connect... and I'll bet good money Android does the same
| thing if it can't get internet access over WiFi
| account-5 wrote:
| I'm not defending Google in anyway, I'm sure they do, and
| I'd be the first to deride them too. But HN generally has a
| lot more forgiveness for apple, for some reason.
| Zak wrote:
| Apple does a lot of marketing around protecting user
| privacy better than the competition. In this case, iOS
| leaks more data than Android.
| joshstrange wrote:
| Completely different situation. The iPhone falls back to mobile
| data if it can't get to the internet over WiFi.
| neilalexander wrote:
| It's also optional (called "Wi-Fi Assist").
| disabled wrote:
| Last that I heard, Raspberry Pi with VPN installed along with
| PiHole that you SSH/VNC (via iOS app) in to is your best option.
| kube-system wrote:
| SSHing to another machine isn't a solution, you're just using a
| different machine.
|
| The way to solve it and still continue to use iOS is to
| implement your VPN at the network layer. e.g. use one of those
| wifi routers with a VPN client built in.
| tablespoon wrote:
| > The way to solve it and still continue to use iOS is to
| implement your VPN at the network layer. e.g. use one of
| those wifi routers with a VPN client built in.
|
| That's a little impractical for a phone. You'd have to lug
| around some kind of VPN-enabled mobile hotspot, plus
| batteries to power it.
| kube-system wrote:
| You're right, it ain't convenient... but _mobile_ hotspots
| already have batteries.
| addingnumbers wrote:
| They circumvent this by forcing certain traffic to circumvent
| your hardened WiFi by using the mobile network radios.
| egberts1 wrote:
| iOS Airplane Mode
| kube-system wrote:
| That is a possibility but the last I checked it was not the
| case.
| giobox wrote:
| This doesn't stop apps using things like DNS over HTTPS etc.
| PiHole works pretty great today, but developers are getting
| sneakier and sneakier about how to obtain outbound DNS. It's
| not just unencrypted port 53 all the time anymore. Eventually
| devices will get the IP for the DNS record they want just fine,
| if they really want to.
|
| PiHole arguably is getting less effective with each passing
| year as alternate DNS resolution methods like DNS over HTTPS
| etc gain traction, and defeating DNS over HTTPS is s a whack-a-
| mole game today, all you can really do is try to blacklist
| known DNS over HTTPS server IPs, which is a running battle.
|
| My assumption is all ad driven applications who depend on
| resolving advert domains correctly to serve the ad content will
| one day all utilise methods like DNS over HTTPS to stop
| products like PiHole reducing revenue.
| tablespoon wrote:
| > PiHole arguably is getting less effective with each passing
| year as alternate DNS resolution methods like DNS over HTTPS
| etc gain traction, and defeating DNS over HTTPS is s a whack-
| a-mole game today, all you can really do is try to blacklist
| known DNS over HTTPS server IPs, which is a running battle.
|
| Aren't blocking ads another whack-a-mole? So it seems like
| more of the same.
|
| Also, aren't there proxies that you can setup that can
| inspect HTTPS connections (so long as you install the proxy's
| cert on your machine). I suppose the whack-a-mole might be
| more practical if a few people used those regularly along
| with some kind of automated scanning for DNS over HTTPS.
| giobox wrote:
| The key difference is the point of control:
|
| For PiHole today, most everything comes over port 53, and
| thus easy to track, monitor and block as required.
|
| Tomorrow, DNS requests can be on any port, to any server,
| on any protocol. This makes trying to use a single point of
| control like the PiHole so much harder than it was in the
| past. Who is to say next week its HTTPS as the encrypted
| transport for DNS? Use whatever bizarre encryption scheme
| you like. It's your app... The app can just ignore whatever
| DNS server you suggested via DHCP or whatever and go back
| to its homebrew domain name resolution system.
| saurik wrote:
| > Who is to say next week its HTTPS as the encrypted
| transport for DNS?
|
| That ship has already set sail, my friend :(.
| mindslight wrote:
| > _Aren 't blocking ads another whack-a-mole?_
|
| Yes, but the mole-whacker is whoever controls the software
| doing the rendering. So on a personal computer, the ads are
| the moles. But on a locked down "phone", the user is the
| mole.
| addingnumbers wrote:
| > Also, aren't there proxies that you can setup that can
| inspect HTTPS connections (so long as you install the
| proxy's cert on your machine).
|
| It's common for apps to prevent this with certificate
| pinning. They'll ignore the certs you've installed manually
| and will only connect to servers with certs signed by their
| in-house certificate authority.
| timbit42 wrote:
| We will need to keep a list of DNS IPs to block access
| through ports 80 and 443.
| giobox wrote:
| And what happens when they start changing the port? It's a
| battle no one ultimately can win, in short term. The
| technical options available to get DNS by so many different
| means are so easy to implement, relatively speaking. Even a
| really junior engineer can likely invent their own DNS
| resolution protocol, its one of the simplest APIs to
| reinvent if all you care about is returning IP address for
| a given name.
|
| 80 and 443 are only used by convention for HTTP/HTTPS - you
| can use whatever the hell you like. There's also the option
| to not use HTTP(S) or DNS at all to obtain addresses, the
| list of ways you can avoid traditional methods is endless.
| Finally, you can just serve your DNS on same IP as back end
| of the app - block the IP and the app dies completely,
| meaning a simple IP block will not work etc etc. It's super
| easy to write some code that combines tens of methods,
| ensuring you get that DNS record no matter how hard the
| user tried to stop you.
|
| FWIW people (including me) already do this, but its a blunt
| tool and not all that effective in many cases: https://gist
| .github.com/ckuethe/f71185f604be9cde370e702aa179...
| WallyFunk wrote:
| For those looking for a workaround, you can get a VPN router in
| my case, a GL.iNet Mango[0] router.
|
| The great thing: even if the VPN connection drops, it doesn't
| leak your real/naked IP, and also /all/ traffic on an iOS device
| has to pass through the VPN. No special exceptions for Apple
| traffic.
|
| The only caveat is you have to carry this when traveling, which
| means if you're traveling light, carrying this around could be
| burdensome. If you are at home most of the time though, such a
| router is invaluable.
|
| [0] https://www.amazon.co.uk/GL-iNet-GL-MT300N-V2-Converter-
| Pre-...
| netfortius wrote:
| Add Android to this:
| https://mullvad.net/en/blog/2022/10/10/android-leaks-connect...
| jacooper wrote:
| Android only leaks connection checks.
|
| While on IOS any system app doesn't use the VPN or DNS
| requests.
|
| VPNs are useless on iOS, and its made to be this way, again the
| "privacy OS" isn't privacy focused at all.
|
| https://www.michaelhorowitz.com/VPNs.on.iOS.are.scam.php
| CharlesW wrote:
| From TFA: _" Apple also said that the Always On VPN feature
| of MDM offers a fix. Mobile Device Management is over my
| head. [...] According to Apple, MDM lets the corporate IT
| techies force all data leaving an iOS device to go to the
| company. But, MDM is is not available to consumers."_
|
| There appear to be several easy-to-use MDM solutions that
| cater to small businesses that would also work fine for
| families. Apple even has one, Apple Business Essentials.
| drcongo wrote:
| Also Google / Android, but that doesn't get the clicks.
| jacooper wrote:
| Only connection checks.
| warunsl wrote:
| That's because Google doesn't market "Privacy" as their USP
| with giant billboards maybe?
| mensetmanusman wrote:
| This type of feature is useful for places like China that need to
| imprison people that speak out against the ccp.
|
| Our tech overlords are not immune to pressures if we teach them
| how it is abused.
| DavideNL wrote:
| Related ProtonVpn article:
|
| " _We've raised this issue with Apple multiple times.
| Unfortunately, its fixes have been problematic. Apple has stated
| that their traffic being VPN-exempt is "expected", and that
| "Always On VPN is only available on supervised devices enrolled
| in a mobile device management (MDM) solution". We call on Apple
| to make a fully secure online experience accessible to everyone,
| not just those who enroll in a proprietary remote device
| management framework designed for enterprises._ "
|
| https://protonvpn.com/blog/apple-ios-vulnerability-disclosur...
| egberts1 wrote:
| That is why a detached but portable WiFi/5G router is for ... to
| block these Apple shenanigans ...
|
| While your phone is in Airplane mode and regular (but your
| router's) WiFi only network
| dljsjr wrote:
| Always-on VPN that tunnels _everything_ requires MDM
| commissioning. It 's documented by Apple.
|
| See the section "Always On VPN":
| https://support.apple.com/guide/deployment/vpn-overview-depa...
|
| Is it dubious that Apple doesn't let VPN apps do this as well?
| Maybe. But this is known and documented.
| mmastrac wrote:
| I wonder if there's a small bit of pressure on the device
| manufacturers to keep DNS leaks happening for consumers. I'd
| love to be a fly on the wall at some of the NatSec-level
| conversations.
| giobox wrote:
| So many times law enforcement take advantage of this too, to
| fingerprint devices. The number of people caught because
| someone leaks packets outside the VPN for a few seconds because
| they forgot to configure VPN to disable outbound data if VPN
| drops... I've long wondered if making always on VPN require MDM
| provisioning on iPhones was a sop to police/criminal
| investigation forces, especially after Apple's public fights
| with the FBI over matters like the locked San Bernadino phone
| etc. I bet very few crims installing VPNs are aware of that
| apple support doc.
|
| If this was working as it arguably should and could be done
| easily without MDM provisioning, it would remove a genuinely
| useful avenue for law enforcement and add more fuel to the the
| FBI's dislike for Apple's security features.
| roamerz wrote:
| You used FBI and the term law enforcement in the same
| sentence. Sad to say the respect I once had for what the FBI
| likes and dislikes has been greatly diminished by the
| political bias that seems to influence it's actions. I look
| forward to the day when they are strictly law enforcement and
| without political agenda. We as a country need them.
| cgb223 wrote:
| Should it be expected that individual users should be familiar
| with corporate deployment documentation just to know that their
| VPN app they bought actually leaks?
| bogomipz wrote:
| I'm not following. Your link appears to be specific to
| corporate environments. The title of the document is:
|
| "VPN overview for Apple device deployment."
|
| It further states "Secure access to private corporate networks
| is available in iOS ..."
|
| An individual iPhone user who is not using a company issued
| device would not be beholden to MDM restrictions or profiles.
| Nor would access to "private corporate networks" be necessarily
| relevant.
| neilalexander wrote:
| You can create and install mobileconfig profiles on any
| iPhone, even unmanaged.
| bogomipz wrote:
| Yes and if it's an unmanaged device it is by definition not
| being managed by an MDM. The title of the link makes it
| clear that the context is "device deployment." Further the
| section un the linked article states"Always On VPN"
|
| ">Always On VPN activation requires device supervision."
|
| Supervision denotes a managed device"
|
| "Supervision generally denotes that the device is owned by
| the organization, which provides additional control over
| its configuration and restrictions."[1]
|
| No regular non-corporate iOS device user is ever likely to
| be downloading manually distributed mobile profiles.
|
| [1] https://support.apple.com/guide/deployment/about-
| device-supe...
| Twisell wrote:
| I once was invited to install a profile as a beta testing
| user. I guess this process is now streamlined through the
| TestFlight app though.
| dljsjr wrote:
| It's written that way because the target audience is
| enterprise IT folks who are managing fleets of employee
| devices, but you can freely use MDM profiles as a consumer.
| It's certainly not user-friendly which is why I commented
| that the way it works for VPN clients installed as apps could
| be seen as a dubious implementation.
___________________________________________________________________
(page generated 2022-10-12 23:02 UTC)