[avsteele]

So every company who uses VPNs to allow their people to get into the network from offsite (customer site, airport, hotel) now can't safely?

You basically have to trust everyone on the remote LAN to not act like a malicious DHCP server.

Reading the other thread, this wouldn't even be just the gateway.. Sounds bad!

[skywhopper]

Presumably most corporate VPNs are used to access specific resources on internal company networks, so if you were affected by this, those resources would fail to load entirely.

But also, if you were using more specific routes for your corporate VPN traffic and not just forwarding all traffic through it, then the simple attack of sending two /1 rules wouldn’t interfere.

You’d still leak some metadata, but you leak a lot by using public networks anyway.

[dspillett]

> You basically have to trust everyone on the remote LAN to not

More than that when connecting via WiFi as almost everyone on a laptop does these days: you have to be careful of “evil twin” attacks from random APs nearby.

Though if you are accessing a VPN to get access to internal network resources, and someone uses this hack to redirect you, you are not going to see those resources anyway and you'll know something is wrong. Accessing any insecure resources is a risk (HTTP traffic can be monitored, fake servers could collect authentication credentials such as SSH user+pass info if not using key-based auth) but only if they are otherwise public because your redirected connection won't be able to route to your corporate network's internal hosts.

Unless I'm misreading (possible, I've only skimmed the details) those using VPNs because they already don't trust their outgoing connection, or are otherwise wanting to disguise their ID and/or location, are more at risk than road-worriers (or these days “home warriors” more likely) connecting to DayJob's VPN.

[djbusby]

When I connect on SSH it verify the host-key. So, that would warn before submitting user/pass (but also, user-key should be used)

[dspillett]

If doing SSH properly, yes.

Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.

Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…

[prmoustache]

On the other hand, it is fairly easy to obtain an ip, change your config to static ip reusing same ip, then and only then connect to the VPN.

[mschuster91]

It's incredibly brittle. The more frequented a network is the shorter the DHCP leases will be, I've seen public hotspots with 10 minutes of lease time.

[prmoustache]

That doesn't mean the dhcp reuse the ip if it sees it used. Some old clients do not behave correctly and I believe DHCP servers take that into account.

[dspillett]

“Fairly easy” for those of us with a technical background. I'm not volunteering to explain that to the CEO when he hears about this and asks how he can access internal company resources safely while mobile!

[jacob019]

They could send a /32 route for a single IP, just to decloak you.