Not all VPN traffic. Only traffic that would be routable without a VPN.
This works by tricking the computer into routing traffic to the attacker’s gateway instead of the VPN’s gateway. It doesn’t give the attacker access to the VPN gateway.
So traffic intended for a private network that is only accessible via VPN (like if you were connecting to a corporate network for example) wouldn’t be compromised. You simply wouldn’t be able to connect through the attacker’s gateway to the private network, and there wouldn’t be traffic to intercept.
This attack doesn’t break TLS encryption either. Anything you access over https (which is the vast majority of the internet these days) would still be just as encrypted as if you weren’t using a VPN.
For most people, in most scenarios, this amount to a small invasion of privacy. Our hypothetical malicious coffee shop could tell the ip addresses of websites you’re visiting, but probably not what you’re doing on those websites, unless it was an insecure website to begin with. Which is the case with or with VPN.
For some people or some situations that is a MASSIVE concern. People who use VPNs to hide what they’re doing from state level actors come to mind.
But for the average person who’s just using a VPN because they’re privacy conscious, or because they’re location spoofing. This is not going to represent a significant risk.
I do still think that a lot of people do use VPNs in public spaces for privacy from an untrusted provider, though, perhaps more than your initial comment seemed to suggest.
Plaintext connections inside corporate networks can still be MITM’ed if the adversary knows what they’re targeting, while they can’t connect to the corporate network they can still steal credentials
You wouldn’t be able to MITM a plaintext connection inside a corporate network with this attack by itself. You could only MITM something that the attacker can access without your VPN.
Any corporate network that has an unsecure, publicly accessible endpoint that prompts for credentials is begging to be hacked with or without this attack.
Now you could spoof an login screen with this attack if you had detailed info on the corporate network you’re targeting. But it would need to be a login page that doesn’t use HTTPS (any corporations, dumb enough to do that this day and age are begging to be hacked), or you’d need the user to ignore the browser warning about it not being secure, which that is possible.
I’m tech support so I’ve seen some stuff, sooo many intranet sites on internal servers don’t have HTTPS, almost only the stuff built to be accessible from the outside has it. Anything important with automatic login could be spoofed if the attacker knows the address and protocol (which is likely to leak as soon as the DHCP hijack is applied, as the browser continues to send requests to these intranet sites until it times out). Plaintext session cookies are also really easy to steal this way.
Chrome has a setting which I bet many orgs have a policy for;
Put another way, this means that a malicious coffee shop or hotel can eavesdrop on all VPN traffic on their network. That’s a really big fucking deal.
Not all VPN traffic. Only traffic that would be routable without a VPN.
This works by tricking the computer into routing traffic to the attacker’s gateway instead of the VPN’s gateway. It doesn’t give the attacker access to the VPN gateway.
So traffic intended for a private network that is only accessible via VPN (like if you were connecting to a corporate network for example) wouldn’t be compromised. You simply wouldn’t be able to connect through the attacker’s gateway to the private network, and there wouldn’t be traffic to intercept.
This attack doesn’t break TLS encryption either. Anything you access over https (which is the vast majority of the internet these days) would still be just as encrypted as if you weren’t using a VPN.
For most people, in most scenarios, this amount to a small invasion of privacy. Our hypothetical malicious coffee shop could tell the ip addresses of websites you’re visiting, but probably not what you’re doing on those websites, unless it was an insecure website to begin with. Which is the case with or with VPN.
For some people or some situations that is a MASSIVE concern. People who use VPNs to hide what they’re doing from state level actors come to mind.
But for the average person who’s just using a VPN because they’re privacy conscious, or because they’re location spoofing. This is not going to represent a significant risk.
That’s a fair point, you’re right.
I do still think that a lot of people do use VPNs in public spaces for privacy from an untrusted provider, though, perhaps more than your initial comment seemed to suggest.
Plaintext connections inside corporate networks can still be MITM’ed if the adversary knows what they’re targeting, while they can’t connect to the corporate network they can still steal credentials
You wouldn’t be able to MITM a plaintext connection inside a corporate network with this attack by itself. You could only MITM something that the attacker can access without your VPN.
Any corporate network that has an unsecure, publicly accessible endpoint that prompts for credentials is begging to be hacked with or without this attack.
Now you could spoof an login screen with this attack if you had detailed info on the corporate network you’re targeting. But it would need to be a login page that doesn’t use HTTPS (any corporations, dumb enough to do that this day and age are begging to be hacked), or you’d need the user to ignore the browser warning about it not being secure, which that is possible.
I’m tech support so I’ve seen some stuff, sooo many intranet sites on internal servers don’t have HTTPS, almost only the stuff built to be accessible from the outside has it. Anything important with automatic login could be spoofed if the attacker knows the address and protocol (which is likely to leak as soon as the DHCP hijack is applied, as the browser continues to send requests to these intranet sites until it times out). Plaintext session cookies are also really easy to steal this way.
Chrome has a setting which I bet many orgs have a policy for;
https://chromeenterprise.google/policies/#OverrideSecurityRestrictionsOnInsecureOrigin
Of course they should set up TLS terminators in front of anything which doesn’t support TLS directly, but they won’t get that done for everything