Edgedressing | Hacker News Reader

Edgedressing

github.com

54 pointsCuriousThings11 comments

This is good and clever work, and I applaud the author for looking at a boring feature and seeing in it a potential attack vector that probably wouldn't have occurred to most people. Kudos! That said, I think the security implications are pretty minimal.

(FWIW, iOS and MacOS do the exact same thing, opening captive.apple.com and showing whatever it redirects to if you're on a captive portal network.)

This behavior does incur a security risk, but using public wifi networks is basically impossible without doing this check either automatically or manually, and most users would be completely bewildered if the OS did nothing to prompt them when they needed to click through a page to make the internet work.

Moreover, if you can MITM the network and they're not tunneling their connection, you have lots of great ways to send them hostile code already! You can use classic SSL stripping to just send them whatever you want! (Granted, a lot of traffic goes straight to HTTPS these days, and browsers are getting wiser about this with HSTS and things like the new automatic HTTPS upgrade in Safari).

If you're paranoid enough not to want to run untrusted javascript (fair enough), you shouldn't be connecting to weird public wifi networks anyway.

Yup. I thought this (captive portal detection) was common knowledge? Android also does this.

I believe NCSI probes are also purposefully HTTP because captive portals MITM all traffic to force authentication. If it was HTTPS the probe would fail with a certificate error. The whole point is that the url can be hijacked. This is not really a vulnerability, they have just independently discovered this feature.

The certificate error is of itself diagnostic of a portal rather than a proxy. The reason to use HTTP, is that some portal systems just drop TLS connections until authenticated. (Which is the correct behavior, rather than MITM.)

Opening the browser automatically is a big bug, that should be easy to fix.

It's not a bug, it is quite literally the feature, and something that also happens on Android and iOS, and I believe even on recent releases of Gnome.

This is Microsoft's version of the WiFi captive portal. For the attack to work, the attacker needs to control the network, and also exploit a hole in the host browsers.

I remember Apple having to fix Safari a few years back, related to that type of attack.

> the attacker needs to control the network

So like, setup a WiFi with the same name? Or any name known to the device, then deauth. Devices also often broadcast some of the names they know.

> and also exploit a hole in the host browsers.

Well now that depends on your goal. Care to guess how many people could be lured into downloading malware or entering some credentials on a phishing page when they get to it?

I agree it's not like printnightmare level bad, but there's options here.

The only real solution to this would seem to be some sort of standardisation about how captive portals should work, but the providers of these services don't seem like the sort who would jump on to that sort of thing quickly.

I'm actually kind of surprised that this hasn't happened yet, with the security concerns around how capacitive portals work.

I'm not super familiar with how the Wi-Fi connection process works, but I would expect that a URL for a capacitive portal could be provided during the connection handshake

Well, it would be standardized (which removes guessing), but it would have all the same security issues once the attacker gets in and injects some wireless frames, no?

Should connecting to a network really initiate opening a web browser and visiting arbitrary URLs without any additional user interaction?

Reply on news.ycombinator.com