Unpatched iOS bug blocks VPNs from encrypting all traffic(bleepingcomputer.com)
bleepingcomputer.com
Unpatched iOS bug blocks VPNs from encrypting all traffic
https://www.bleepingcomputer.com/news/security/unpatched-ios-bug-blocks-vpns-from-encrypting-all-traffic/
12 comments
I haven't heard "slug" before, is that your own phrase? It sounds like you've implemented what's known as a stateless transparent firewall if I'm understanding what you've said correctly. Stateless because it's just plain ACLs, transparent because it's not a routed hop/isn't detectable by the client (outside traffic being dropped), and firewall because it's filtering unauthorized traffic. Most people just call it "ACLs" for short though since "stateless transparent firewall" is a bit of a mouthful and "firewall" by itself often implies a routed mode stateful firewall.
"I haven't heard "slug" before, is that your own phrase?"
Yes, although I've been using it for several years when discussing a safety device like this ...
I first discussed a transparent, stateless firewall in 2001 when I wrote a HOWTO for the FreeBSD project:
http://www.kozubik.com/published/freebsd_bridging_ipfw.txt
... although that is hopelessly out of date. Like I said, I keep meaning to do a blog post on this ...
Yes, although I've been using it for several years when discussing a safety device like this ...
I first discussed a transparent, stateless firewall in 2001 when I wrote a HOWTO for the FreeBSD project:
http://www.kozubik.com/published/freebsd_bridging_ipfw.txt
... although that is hopelessly out of date. Like I said, I keep meaning to do a blog post on this ...
Things like this work great for your own network, but you often want a VPN specifically because the network you're connected to isn't yours, especially for iOS (or Android) devices because they're mobile.
This concept is often referred to as a "VPN killswitch" as well (though that is really a misnomer, IMO).
Popular with pirates because having torrent activity leaked to your ISP is not great.
Popular with pirates because having torrent activity leaked to your ISP is not great.
I guess you could call it a killswitch, but if so it's a very tiny subset of the ways killswitches are implemented.
I may have a VPN box that only allows traffic to one IP via IP tables/nftables. VPN breaks, no traffic. Simple. It’s useful for more than just piracy though. It’s a nice way to shut down all sorts of ISP crap and guarantee no leakage. Run the household DNS though it as well.
This, but if your op-sec is strict enough, have unique DNS servers per security domain; possibly just a simple local caching server that is forced to work through the intended public face.
I just use iptables, and allow only output via eth0/enp0s1 to the VPN server, so everything else must use tun0. Or I use pfSense VMs as VPN gateways, with outbound NAT and analogous rules.
But TFA is about iOS, where none of that is possible. Or at least, I'm not aware that it is.
Another thing. Although most people do work with and without VPNs on a given device, that's extremely iffy. Ideally, you want a device to have never hit the Internet directly, but only through the VPN or whatever that you're using. And using pfSense VPN-gateway VMs, that's very easy to do.
But TFA is about iOS, where none of that is possible. Or at least, I'm not aware that it is.
Another thing. Although most people do work with and without VPNs on a given device, that's extremely iffy. Ideally, you want a device to have never hit the Internet directly, but only through the VPN or whatever that you're using. And using pfSense VPN-gateway VMs, that's very easy to do.
What would be the WiFi equivalent of this? Think a scenario where a road warrior is in need of connecting his or her devices to a public network. It seems my simple OpenVPN setup on each individual device isn’t enough.
How exactly is this different than how tor works?
It's really not related to Tor, or how Tor works at all ...
However you could use it with Tor in just the same way - your Tor-networked device should be talking on only specific network ports and any other "chatter" should be considered a leak ... so you would configure the "slug" to only allow the Tor-generated traffic on the expected ports.
I do not use Tor and don't have specific ports/protocols information on it ...
However you could use it with Tor in just the same way - your Tor-networked device should be talking on only specific network ports and any other "chatter" should be considered a leak ... so you would configure the "slug" to only allow the Tor-generated traffic on the expected ports.
I do not use Tor and don't have specific ports/protocols information on it ...
In my opinion, it's best to use Whonix for Tor, because the Tor process and userland are in separate VMs, or separate Qubes AppVMs. There is no forwarding at all between the Whonix workstation VM and the Internet, via the gateway VM. The workstation VM just uses Tor SocksPorts exposed on the gateway VM, through a private network link.
Where leaving no traces on a device is key, Tails is better, because it runs in RAM and wipes everything during shutdown.
Where leaving no traces on a device is key, Tails is better, because it runs in RAM and wipes everything during shutdown.
I'm not sure if the temporary workaround they propose is a fix or the problem itself. I've noticed when I turn my phone off airplane mode in the mornings, I do not have working VPN connection -- all traffic is blocked. Perhaps this is Wireguard and its particular configuration, or perhaps Wireguard getting a faster start than the operating system reconnecting to my network. In any case, the VPN appears to be blocking traffic. The only workaround I have for that is to disconnect, which takes some time, or switch servers (faster) and reconnect -- and then I guess I'm in the same boat of possible IP leaks.
So, for the folks that consider this a security issue.
Do you really want the OS to break all your existing connections when you start the VPN?
Do you think this is what most people expect to happen?
I would say that the great majority of VPN users use the VPN to gain access to services behind a firewall, not to disguise their location from the world.
I would guess they'd be pretty annoyed to have a file transfer interrupted that has nothing to do with the resources behind the VPN.
Seems bizarre to call this a "bug"
Do you really want the OS to break all your existing connections when you start the VPN?
Do you think this is what most people expect to happen?
I would say that the great majority of VPN users use the VPN to gain access to services behind a firewall, not to disguise their location from the world.
I would guess they'd be pretty annoyed to have a file transfer interrupted that has nothing to do with the resources behind the VPN.
Seems bizarre to call this a "bug"
> Do you really want the OS to break all your existing connections when you start the VPN?
Yes, just like when I connect to WiFi while having LTE enabled and active.
Yes, just like when I connect to WiFi while having LTE enabled and active.
I have unlimited data, I'd very much rather the device use everything seamlessly
Multipath TCP or QUIC will provide us all with a seamless experience, if they ever gain adoption.
Great, this website bans access from datacenter IP address ranges. In other words, I cannot read this blog while connected to my VPN provider...
> Error 1005
> The owner of this website (www.bleepingcomputer.com) has banned the autonomous system number (ASN) your IP address is in (xxxxx) from accessing this website.
> Error 1005
> The owner of this website (www.bleepingcomputer.com) has banned the autonomous system number (ASN) your IP address is in (xxxxx) from accessing this website.
Here is the original report by ProtonVPN.
https://protonvpn.com/blog/apple-ios-vulnerability-disclosur...
https://protonvpn.com/blog/apple-ios-vulnerability-disclosur...
They're not blocking IVPN either.
I suggest the use of Tor.
If they are blocking those addresses, what makes you think they aren't blocking tor?
This is trivial to verify. I’ll save you two minutes and say that yes indeed it’s accessible through Tor. Tor doesn’t have a static number of exit nodes and due to the variable nature of the network it’s difficult to block.
> due to the variable nature of the network it’s difficult to block.
Due to the fact that the Tor project provides a variety of lookup tools to determine whether an IP is an exit node -- including a DNS-based lookup -- it's trivial to block Tor users.
https://www.torproject.org/projects/tordnsel.html.en
Due to the fact that the Tor project provides a variety of lookup tools to determine whether an IP is an exit node -- including a DNS-based lookup -- it's trivial to block Tor users.
https://www.torproject.org/projects/tordnsel.html.en
Yet it isn’t blocked while this VPN is.
But your reasoning is incorrect - in fact, site owners can block Tor in Cloudflare with a single, easy to configure firewall rule.
> Tor doesn’t have a static number of exit nodes and due to the variable nature of the network it’s difficult to block.
> Tor doesn’t have a static number of exit nodes and due to the variable nature of the network it’s difficult to block.
Really? I don't think I've seen that before. Where is that?
It's treated like a country, with country code "T1". Site operators can create rules which apply special handling to visitors from the exotic country of Torlandia. ;)
https://support.cloudflare.com/hc/en-us/articles/203306930-U...
https://support.cloudflare.com/hc/en-us/articles/203306930-U...
making tor exits unblockable is the opposite of how the tor project operates.
Actually, there is a proposal for Tor exits to use a different IPv6 address for each circuit. See https://trac.torproject.org/projects/tor/ticket/26646
They still would be listed though? And people blocking tor ipv6 would of course block ranges rather than individual IPs.
I presume that they'd never get reused.
And yes, there could be blocking by ranges.
And while I doubt that Tor would ever do it, one could use residential IPs via "free" smartphone apps. Some VPN services may be doing that.
And yes, there could be blocking by ranges.
And while I doubt that Tor would ever do it, one could use residential IPs via "free" smartphone apps. Some VPN services may be doing that.
They are all listed...
https://blog.torproject.org/changes-tor-exit-list-service
No one could not use residential IPs that way.
No one could not use residential IPs that way.
Yes, they're all listed now.
But I don't see anything in https://trac.torproject.org/projects/tor/ticket/26646 about listing the IPv6 addresses. And using random addresses from multiple /48, that'd be an extremely long list.
I was wrong about not reusing IPv6. But even so, using the same IPv6 would be very rare, given the number available.
You say that no one could use residential IPs that way. But I know for a fact that it's already being done. For example, see https://luminati.io/proxy-networks/residential-ips.
But I don't see anything in https://trac.torproject.org/projects/tor/ticket/26646 about listing the IPv6 addresses. And using random addresses from multiple /48, that'd be an extremely long list.
I was wrong about not reusing IPv6. But even so, using the same IPv6 would be very rare, given the number available.
You say that no one could use residential IPs that way. But I know for a fact that it's already being done. For example, see https://luminati.io/proxy-networks/residential-ips.
Why wouldn't they?
Handful of blocked ranges yes...
It's obvious that this isn't a goal of Tor.
Handful of blocked ranges yes...
It's obvious that this isn't a goal of Tor.
I'd say that it hasn't been Tor's goal.
But blocking has become so common that user pressure to prevent it can no longer be ignored. If they don't act, they risk being replaced.
I typically get around it by routing a VPN service, or a private VPN, through Tor. That also enables apps that require UDP. There is the risk of deanonymization, if VPN connections last too long and pin Tor circuits. Or if users don't adequately anonymize payment for VPN services or VPS used for private VPNs.
I started playing with a set of bash scripts that creates multiple VPN connections, with each using a different Tor circuit, and tests them. It periodically switches from one to another, and kills the old one. So both Tor circuit and VPN exit IPv4 change periodically. A script ongoingly starts and tests new VPN connections, to maintain availability. It's basically a crude hack of Tor's approach to circuit management.
But blocking has become so common that user pressure to prevent it can no longer be ignored. If they don't act, they risk being replaced.
I typically get around it by routing a VPN service, or a private VPN, through Tor. That also enables apps that require UDP. There is the risk of deanonymization, if VPN connections last too long and pin Tor circuits. Or if users don't adequately anonymize payment for VPN services or VPS used for private VPNs.
I started playing with a set of bash scripts that creates multiple VPN connections, with each using a different Tor circuit, and tests them. It periodically switches from one to another, and kills the old one. So both Tor circuit and VPN exit IPv4 change periodically. A script ongoingly starts and tests new VPN connections, to maintain availability. It's basically a crude hack of Tor's approach to circuit management.
tor does not use ipv6 currently.
Huh?
https://metrics.torproject.org/rs.html#search/2001:
I see 377 starting with 2001:.
https://metrics.torproject.org/rs.html#search/2001:
I see 377 starting with 2001:.
Visiting the website through WifiMask VPN (using Digital Ocean servers) works fine.
My self hosted DigitalOcean VPN is blocked by them, I wonder if it’s region specific
usually vps are blocked because they use bot to scrape data etc creating useless problems.
Update: By vps i mean ip from digitalocean,linode, vultr etc.
Update: By vps i mean ip from digitalocean,linode, vultr etc.
They don't seem to be blocking Linode, maybe they had a problem with that provider.
> While connections made after connecting to a VPN on your iOS device are not affected by this bug, all previously established connections will remain outside the [VPN]...
Is it a bypass or working by design? If you’re relying on the VPN for security then the fact they were established before it means the horse has already bolted.
Is it a bypass or working by design? If you’re relying on the VPN for security then the fact they were established before it means the horse has already bolted.
Even if it's not by design, is it even possible to move existing connections to another IP address?
Or is the "expected" behavior to sever all connections and let whatever reconnect mechanism work through the VPN?
Or is the "expected" behavior to sever all connections and let whatever reconnect mechanism work through the VPN?
The expected behavior is that your OS works correctly.
If a VPN adds a 0.0.0.0/0 route, that route should be respected. Your OS should not circumvent your routing table for some packets and not others.
If a VPN adds a 0.0.0.0/0 route, that route should be respected. Your OS should not circumvent your routing table for some packets and not others.
I don't think it is a case of deliberately "circumventing" the routing table, but rather that the operating system most likely performed source address selection based on the routing table at connection setup. The fact that the routing table has since changed is likely irrelevant after that depending on how the source address is used when calculating the outbound interface. That behaviour is different across different operating systems but this is correct and functioning as expected for Darwin.
No, you can’t move the TCP connection but a decent expectation would be to interrupt all of the existing TCP connections and let the clients retry and resume the session using a session identifier.
Mobile apps should already be used to IP changes interrupting connections due to WiFi->cellular transitions.
Mobile apps should already be used to IP changes interrupting connections due to WiFi->cellular transitions.
I'm not sure I like that. Every site that successfully resumes via a session identifier after the VPN is turned on can now use the session identifier and their logs to match up my real IP address and my VPN IP address.
Obviously, I don't care if those particular sites know my real IP address since I was using them without a VPN before.
But I might not want the sites that I only visit via VPN to know my real address. If I go around giving both to whatever random sites I happened to be using before starting the VPN, there is the risk that one of those sites will give/sell the data to one of the sites that I want to only know my VPN address.
If there are some sites that I do not want to have find my real IP address when I'm on a VPN to them, not letting any sites find out both (except for the VPN provider) is a good idea.
This might be hard to do. Many higher level protocols do not use persistent TCP connections. They connect, process data for a while, and then disconnect when they go idle. Those will end up moving to the VPN (and leaking non-VPN/VPN IP information into the server's logs).
Maybe if it worked at the process level? Processes launched before the VPN starts would not use the VPN unless you explicitly told the system to do so. Still probably has holes.
If you really are trying to seriously use the VPN for privacy, I think you might need a setup where things that use the VPN and things that do not are kept separate, including separate things like cookies and other storage. On a desktop, something like running the things using the VPN in a VM or a container. On phones, though? I don't think you can do that.
Obviously, I don't care if those particular sites know my real IP address since I was using them without a VPN before.
But I might not want the sites that I only visit via VPN to know my real address. If I go around giving both to whatever random sites I happened to be using before starting the VPN, there is the risk that one of those sites will give/sell the data to one of the sites that I want to only know my VPN address.
If there are some sites that I do not want to have find my real IP address when I'm on a VPN to them, not letting any sites find out both (except for the VPN provider) is a good idea.
This might be hard to do. Many higher level protocols do not use persistent TCP connections. They connect, process data for a while, and then disconnect when they go idle. Those will end up moving to the VPN (and leaking non-VPN/VPN IP information into the server's logs).
Maybe if it worked at the process level? Processes launched before the VPN starts would not use the VPN unless you explicitly told the system to do so. Still probably has holes.
If you really are trying to seriously use the VPN for privacy, I think you might need a setup where things that use the VPN and things that do not are kept separate, including separate things like cookies and other storage. On a desktop, something like running the things using the VPN in a VM or a container. On phones, though? I don't think you can do that.
> Every site that successfully resumes via a session identifier after the VPN is turned on can now use the session identifier and their logs to match up my real IP address and my VPN IP address.
This would already be the case if the sites had disconnected clean instead of abruptly, since the session can still be resumed in that case.
Really what you want if you're worried about those sorts of correlations is to simply never send any traffic without the VPN. Have no default route via the physical interface at all so that if the VPN is disconnected the internet is unreachable.
This would already be the case if the sites had disconnected clean instead of abruptly, since the session can still be resumed in that case.
Really what you want if you're worried about those sorts of correlations is to simply never send any traffic without the VPN. Have no default route via the physical interface at all so that if the VPN is disconnected the internet is unreachable.
> Even if it's not by design, is it even possible to move existing connections to another IP address?
Computer Networks 101 Exam
Question 31.) What identifies a TCP connection?
Computer Networks 101 Exam
Question 31.) What identifies a TCP connection?
[ ] Peer IP address
[ ] Peer IP and Port
[x] The four-tuple (peer IP, peer port, local IP, local port)I've been hearing about multipath TCP for the last 15 years and didn't know if maybe it was finally in use.
Multipath TCP has been in use on iOS since 2013(!), a lot of the Apple apps use it and since 2017 other apps can as well, which is pretty neat
This has been standard Mac OS X behavior for a long time: on a machine with multiple IP addresses, connections will use the default gateway associated with the interface providing that address.
As a Linux admin, I am thoroughly confused. Are you saying that MacOS maintains a separate routing table for each interface?
Typically, a system has only one default route. You can have many interfaces and many routes, but only one default. Otherwise you don't know which default gateway to send a packet to.
Typically, a system has only one default route. You can have many interfaces and many routes, but only one default. Otherwise you don't know which default gateway to send a packet to.
The GP is wrong, and your understanding is correct - there is one routing table.
There is one routing table but it can have multiple default gateways:
fenrir:~ $ uname -a
Darwin fenrir 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
fenrir:~ $ netstat -rn |head
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 172.16.22.254 UGSc 85 732 en0
default 192.168.88.1 UGScI 2 49 en2
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 3806 lo0
169.254 link#6 UCS 2 0 en0 !
169.254 link#8 UCSI 0 0 en2 !
fenrir:~ $ traceroute -ni en0 google.com
traceroute to google.com (216.58.194.142), 64 hops max, 52 byte packets
1 172.16.22.254 0.565 ms 0.340 ms 0.300 ms
2 172.16.25.60 0.893 ms 0.727 ms 0.721 ms
3 172.16.25.0 0.954 ms 0.819 ms 0.815 ms
4 108.218.244.1 7.422 ms 1.908 ms 3.617 ms
5 *^C
fenrir:~ $ traceroute -ni en2 google.com
traceroute to google.com (216.58.194.142), 64 hops max, 52 byte packets
1 192.168.88.1 12.399 ms 3.768 ms 0.811 ms
2 192.168.80.1 1.950 ms 8.322 ms 1.702 ms
3 172.26.96.161 30.448 ms 393.449 ms 46.537 ms
4 107.72.199.60 182.826 ms
107.72.199.36 34.835 ms
107.72.199.60 50.557 ms
5 12.83.186.101 52.178 ms 32.536 ms 33.431 ms
6 12.83.186.85 38.516 ms 51.138 ms 61.687 ms
7 12.122.5.190 48.626 ms 251.733 ms 38.487 ms
8 12.122.2.197 58.184 ms 82.183 ms^C
fenrir:~ $ traceroute -ns 192.168.88.243 google.com
traceroute to google.com (216.58.194.142) from 192.168.88.243, 64 hops max, 52 byte packets
1 192.168.88.1 4.658 ms 10.498 ms 3.633 ms
2 192.168.80.1 4.264 ms 58.660 ms 7.153 ms
3 172.26.96.161 105.557 ms 41.207 ms 32.243 ms
4 107.72.199.60 66.562 ms
You can actually do this on linux pretty easily but it's not the default, it's sometimes called "source routing"
Easy to setup with netplan and systemd-networkd, a little more complex to do manually.
Easy to setup with netplan and systemd-networkd, a little more complex to do manually.
Nobody claimed the OS was designed to be secure!
https://www.apple.com/ipad/why-ipad/
Giant letters: "It's designed to be secure. And to protect your privacy."
Giant letters: "It's designed to be secure. And to protect your privacy."
Welp, clearly a lie.
We direly need an open source phone as a matter of personal and social security.
There is such a open source phones for example Librem 5
https://puri.sm/products/librem-5/
and Pine phone https://www.pine64.org/pinephone/
and Pine phone https://www.pine64.org/pinephone/
We do, but modern smartphones (if you are not talking about regular phones with no ability to run third-party software) are so complex that it would require a Linux-level _centralized_ effort to pull off. And it's really hard to imagine any centralized effort in this field given the current competition.
I don't see a linux-style effort producing any usable software anyway.
That won't protect you from bugs. But if you're interested, check out the Librem 5 project.
Actually, having access to the source code does protect you from bugs. Apple ignores all the ones I report.
And many open source projects would most likely ignore pull requests.
??? you don’t need to commit software upstream to use it, audit it, or publish obvious vulnerabilities and improvements. Right now consumers have a feudal arrangement with Apple: accept the software at any conditions or not have land on which to work.
What? How did OpenVPN and OpenSSH have critical bugs for years despite them having open source code?
I've noticed this before with DNS, too. I have internal names that always get resolved externally despite my VPN. Hoping this all gets fixed eventually :(
Discovered myself that android has issues.
Start wifi tethering. Connect your VPN, assume traffic is going over it.... nope.
There is a shadow APN configured for your network provider that you can't edit, and all tethered traffic goes over that, not the VPN'd connection.
The VPN only protects traffic originating from the phone.
Start wifi tethering. Connect your VPN, assume traffic is going over it.... nope.
There is a shadow APN configured for your network provider that you can't edit, and all tethered traffic goes over that, not the VPN'd connection.
The VPN only protects traffic originating from the phone.
it was going through vpn in android 4.2 or 4.4 if I'm not mistaken.
But variety of applications can install their cert (with ofc user permission via dialog) and snoop traffic. At least unencrypted.
The way they do it is installing vpn and reading stuff in-between
https://play.google.com/store/apps/details?id=app.greyshirts...
But variety of applications can install their cert (with ofc user permission via dialog) and snoop traffic. At least unencrypted.
The way they do it is installing vpn and reading stuff in-between
https://play.google.com/store/apps/details?id=app.greyshirts...
I believe that you can make a new APN entry, copying the provided settings, without the second tethering-only APN, if you want, which gets around it too.
AFAICT the reason for this second APN is to allow providers to discriminate between phone-originated data and tethering for charging purposes. And they seem to have persuaded google not to allow people to edit it :/
AFAICT the reason for this second APN is to allow providers to discriminate between phone-originated data and tethering for charging purposes. And they seem to have persuaded google not to allow people to edit it :/
https://labs.integrity.pt/articles/the-curious-case-of-apple...
That's a post from April 2019 showing a very similar issue with IKEv2 VPNs leaking traffic on iOS. I wonder if the two issues are related. Back then, Apple was made aware under responsible disclosure but apparently nothing was done about it.
That's a post from April 2019 showing a very similar issue with IKEv2 VPNs leaking traffic on iOS. I wonder if the two issues are related. Back then, Apple was made aware under responsible disclosure but apparently nothing was done about it.
This isn't all that surprising because this is exactly how networking is expected to work. If it is desired to kill all active connections, then it should be explicitly done at the time of VPN connection.
A "slug" is a layer-2 bridge, with no IP address configured, that still enforces a TCP/IP whitelist. So it does not "use" a hop on the network route, and you can't see the device, but as it bridges traffic it enforces a (very simple) ruleset.
In my case, I use my own VPN hosts that transact over TCP22 ... and so my network "slug" allows only tcp port 22 traffic. Everything else is blocked.
This means that no matter how badly behaved (or buggy) my VPN software is (I use sshuttle[1]) the bad behavior is blocked by the slug.
The slug itself has almost zero attack surface as it is a BSD based system that has no IP address configured and runs no network services.
I keep meaning to write up a blog entry about this ...
[1] https://sshuttle.readthedocs.io/en/stable/