Hotel Hotspot Hijinks | Hacker News Reader

Hotel Hotspot Hijinks

peateasea.de

60 pointsoalders33 comments

For travel routers there’s travelmate for OpenWrt https://github.com/openwrt/packages/blob/master/net/travelma...

Does that automate login to a captive portal?

Haven't tried it but sounds like it should, it already have a few shell scripts for some captive portals.

"captive portal auto-login hook (configured via uci/LuCI), you are able to reference an external script for captive portal auto-logins (see example below)"

https://github.com/openwrt/packages/blob/master/net/travelma...

It can also auto join open networks "automatically add open uplinks to your wireless config, e.g. hotel captive portals (disabled by default)"

It’s kind of baffling that after decades of wifi and captive portals, we still don’t have any kind of standard for the network to properly signal the fact “you’ll need to visit <url> in a browser” to a device.

It’s hacks (DNS hijacking) upon hacks (captive portal detection) upon hacks (captive portal detection evasion, used e.g. to allow devices to stay connected to networks offering “messaging only” plans).

On top of that, after a captive login, the entire session is only identified/authenticated via MAC address, which is very sniffable/cloneable in unencrypted wifi… At least I have yet to see any captive portal hotspot to leverage OWE for something more secure than that.

"It’s kind of baffling that after decades of wifi and captive portals, we still don’t have any kind of standard for the network to properly signal the fact “you’ll need to visit <url> in a browser” to a device. "

We do, actually, and have for decades.

https://en.wikipedia.org/wiki/WISPr

Back in ~2010 I wrote a simply python script that parses out the WISPR data that you get, and submits data to the place specified by the XML.

It works on 90+% of hotspots i've ever encountered.

Could you share your script? That sounds really useful!

That sounds cool – are you saying that commercial hotspots actually use this? The specification website seems to be offline, for one thing.

Assuming that's indeed a thing, I wonder why the experience (at least on macOS/iOS) is still so mixed then.

For example, in inflight Wi-Fi, I practically always have to manually navigate to a non-HTTPS site in my browser to hopefully get redirected to airlinename.com/wifi or whatever they use, to be able to pay for an internet pass (with credit card or by watching their ads).

I suspect this is because many airlines now offer free in-flight entertainment and messaging on their free tiers, and the OS's native captive login UI would interfere with that. So I suppose that WISPr protocol doesn't support communicating something like "limited connectivity, navigate to URL x to pay for full access, portal available at URL y".

Yes, most commercial hotspots use it. Particularly the redirect to login page ones. If you get some form of “you need to login” pop up notification, it is the main way they detect that. Those that don’t give you such a notification are probably not using it

For the captive-portal detection part, there’s an RFC covering it: The network provider can tell the device where to send the user, and can provide an endpoint to get info like how long is left on the session.

Apple has a page on it, here: https://developer.apple.com/news/?id=q78sq5rv

Not sure if this is deliberate, but it seems like a straightforward application of the "paving the cowpaths" approach to standards that was advocated so much in the last decades.

Basically I guess, browser vendors decided that there is no way to convince every captive portal operator on earth to adopt some kind of standard, so they just "standardized" the existing practice of querying some random http host and see if it gets intercepted.

I think there are also discentives to standardisation, unfortunately: Captive portal operators want their portals seen by humans, often just to get people to agree to some ToS. If this were standardized, someone would build a tool that could log into a captive portal without user interaction, and while this would be awesome for me and you, it defeats the entire purpose of the portal from the operator's perspective.

So I fear, this is why we (techies) can't have nice things.

> so they just "standardized" the existing practice of querying some random http host and see if it gets intercepted.

What I have seen a lot is only certain URI's redirecting you to the captive portal. ("A lot" being some minority of open access points, not most of them which redirect everything - but it's common enough)

For anyone stuck in this labyrinthine hell, the two which always work belong to warring big tech behemoths:

https://www.google.com

http://www.msftconnecttest.com/

Others may work on these AP's; I haven't had to try different ones after trying these two.

https://www.google.com will most likely not load because browsers nowadays have HSTS, and they will stop loading as soon as the server offers the wrong certificate...

Yeah, ran into that one a few times. Sometimes clicking "advanced" if presented as an option, lets me proceed. Other times, I think I just used Internet Explorer to get around it.

example.com, example.net, and neverssl.com all lack HTTPS.

I have "neverssl.com" as a prominent bookmark; as its name implies, the lack of SSL means I get directly to the captive portal page.

Except every once in a blue moon when the opposite happens: HTTPS 443 gets blocked/hijacked while HTTP 80 goes out just fine (in which case either of the beforementioned generally gets you to the portal).

How would that work? The entire point of https is that it can't be hijacked.

(Or rather, you can hijack it, but you can't show a portal on that connection, so what would be the point?)

I'm not saying it works as intended or that there is a point to it. Just that it does happen.

You can add

http://connectivitycheck.android.com,

http://connectivitycheck.gstatic.com, and

http://www.apple.com/library/test/success.html

to your list.

> Captive portal operators want their portals seen by humans

The concept of "engagement" strikes again. The objective there isn't to complete some business transaction or payment (otherwise it would be in every party's interests to make tooling to facilitate said transaction), it's to explicitly waste a human's time.

It is problematic because it would still require that you even have a compatible web browser.

On the other hand, this sort of nonsense is why some places just have an AP and give the wifi password and you can just connect.

(instead of visiting a page, setting a bunch of cookies and tracking you all over the universe)

Actually, we do. The WISPr standard (https://en.m.wikipedia.org/wiki/WISPr) has since evolved into ETSI recommendations, and the new ones are automatable. But cheapskate hotel Wi-Fi systems are only upgraded when the building is torn down.

Judging by the password and username posted here, it's trivial to deduce the specific hotel in question.

That has now been fixed.

I wanted to connect my Nintendo Switch to the hotel wifi, but the captive portal wouldn't load on it. So I just spoofed my Switch MAC on my laptop, got thru the captive portal, reverted everything, and I was able to happily play Diablo 3 :)

> I wanted to connect my Nintendo Switch to the hotel wifi, but the captive portal wouldn't load on it. So I just spoofed my Switch MAC on my laptop, got thru the captive portal, reverted everything, and I was able to happily play Diablo 3 :)

And next time, you can try to beat your personal high score for speed-running captive portal automation/evasion ;)

Now I think about it, that seems like it would be a rather fun activity for a software meetup!

I've been tempted to work on some kind of script environment to automatically bypass captive portal screens like this, but I've been putting it off in the hopes someone who actually knows how to do it makes one.

Couldn’t he just have used Firefox’s developer mode to record the POST and then do “copy a cURL” for a nice one liner? (Or maybe two to handle cookies)

Funny enough, I'm reading this while connected to hotel Wi-Fi, fresh from navigating through the login page of their website. In my situation, it required inputting my room number along with the last name. Does anyone happen to possess a functional script akin to the one mentioned in this post, or perhaps a comparable script that I could just plug in and use?

Try opening the console tools of your browser, find the network tab, then log in (you should be able to get the captive portal in your browser if you experiment a bit, kinda as per the article.)

Then locate the request that was made when you logged in, right click, and “Copy as cURL.”

Then just paste the resulting command in a terminal when needed. It should capture everything you need (notwithstanding CSRF/session IDs rotating etc.)

Will give this a try. Thanks!

(Re-upped from https://news.ycombinator.com/item?id=39780937 and comments moved hither)

Reply on news.ycombinator.com