> What bugs me about their response is that the device required to do this type of on-the-fly JavaScript injection of HTML is both rare and expensive. It requires specialized hardware (like the RG Nets’ RXG-A8) starting at a cost of $10,000. In other words, this hardware was procured precisely for the purpose of perpetrating this kind of attack. If Courtyard/Marriott/Hotel Internet Services didn’t want that feature, then they probably could have requisitioned cheaper, less specialized, and more robust networking hardware.
It looks like the device is a router and gateway for institutional networks, with features like captive portal, registration integration, etc. It isn't a dedicated JS injection device. While you can do that stuff on the cheap, $10k isn't unreasonable for networking gear with more special use-cases. The contractor likely just flipped that option on just to make a few extra bucks.
In 2012 HTTPS was only common on websites that actually processed sensitive information like online shops and banks. Most websites/BBs (even with logins) didn't use HTTPS as it required you to buy a certificate. Lets Encrypt was not around back then
I am surprised the person was surprised. I was using a lot of coffee shop WiFi in 2010's and earlier, and random injection was fairly common. Sometimes generic ads, sometimes timers ("You get free wifi for 1 hour, you have 42 minutes remaining"), sometimes ads for the coffee shop itself.
1. On today's internet, the sender's mail server almost always talks directly to the receiver's mail server anyway, both so that random intermediate servers don't see the message and (mostly) as a spam mitigation measure.
2. That MX-to-MX connection will usually happen over TLS, which is encrypted.
3. Almost always, the clients will connect to their respective mail servers over an encrypted connection.
So in practice that kind of injection isn't really feasible.
Some Cisco routers have/had a feature where they'd mitm every smtp connection and snip out the STARTTLS advertisement to prevent negotiation of an encrypted connection. Of course this doesn't affect port 465 use, but port 25/587 can get silently downgraded.
It is absolutely true that SMTP can be sent over plaintext. Many mail systems have opportunistic use of TLS, but they can fall back to plaintext if that’s not available. A few mail systems require TLS, at the risk of not being able to receive messages (and the big boss yelling about it).
A blanket statement that all email is encrypted is just plain false.
They're asking for the client-to-provider (which tends to be the one vulnerable to these attacks), not provider-to-provider connections (which makes sense, $BUSINESS's on-premise Exchange might not support TLS connections at all).
Installing a WiFi client certificate (in lieu of a PSK) and installing a root certificate used for TLS (in lieu of those distributed with the OS) are two completely different things, no?
I think if you block port 443 in such a way that a client sees it closed like any other non-HTTPS website, and the user has never been to the requested site before on that browser (to avoid HSTS being in effect), and they omit a scheme when typing the URL into the address bar, then the browser will make an unencrypted request and render the unencrypted response. However, popular browsers these days will add a "not secure" note near the address bar (where historically it would've had no such indication besides lack of padlock) and they'll try https first before falling back to http (but no fallback in the case of cached HSTS info from a prior visit).
I can't fathom this addiction for VPN for "security". Nowadays almost every website uses HTTPS and browsers block HTTP downgrades most of the times. Yes VPNs are still useful for the occasional HTTP website, however most people will use some form of free VPN that could totally do the same.
But yes, VPNs did solve this issue at the time of writing, and I even used one for quite long as my mobile carrier used to proxy all images through their own servers, as well as intercepting port 21. They stopped doing the former with the advent of HTTPS. To my knowledge they did not use this for nefarious purposes (they served downscaled images for lighter browsing at a time where 3G was frugal and websites not optimized yet for mobile).
You can thank the pervasive advertising of services like NordVPN and their owned subsidiaries for that. Loads of people have been advertised to thinking that using a VPN is "more secure", but this new colloquial understanding of a VPN is quite different from the true definition. I've had to have talks with numerous friends and colleagues dissuading them from purchasing these, including saving someone from a multi-hundred dollar NordVPN subscription because they wanted to be more "secure".
As an aside, viewing an HTTP website over VPN is indeed useful when the threat actor is the public WiFi provider, but it doesn't if your threat actor is the VPN provider, or in between the VPN provider and the hosting provider. I'll cede that this is beyond the scope of the situation talked about in the article though.
I've long wondered if there was a place for a httpv mode. Where traffic is signed but not encrypted. This would allow local caching or torrent-like distributed fetching but not modification.
The obvious downside is that the page contents are not private.
Chrome implemented something sort of like this with https://developer.chrome.com/blog/signed-exchanges. However this is very limited. It requires the linking site to cooperate. For example Google Search can link to a signed exchange rather than the original site. But this just moves traffic from the site's CDN to Google's. It also packages full bundles so shared resources need to be duplicated. Also any navigation inside that site will go to the origin and can't be cached.
Overall it seems like it probably isn't worth it. But I find it an interesting idea.
This simplifies, democratizes, and makes transparent the "internal resource sharing/caching" that some browsers can do, like when needing to load the latest jQuery for the 15th time in the last minute, even across domains.
Also would be perfect for captive portals, or other static LAN content.
I think the problem comes down to fingerprinting. For example, resources used to be cached in the browser regardless of site exactly as you described, but then ad companies figured out you can track a user's browsing history by timing the cache accesses to see if a user had loaded a bundle from another site. To remove that vector, browsers split up caches per domain.
That's a vector for literally all assets so adding a random delay to every layer up to the last Paint() is the only real counter.
It can be mitigated by adding a property to scripts to allow/default/deny shared domain resource caching, and the ecosystem can benefit from jquery/etc from being hot but still maintain opt-in default/backwards-compat status.
that, combined with the already established HTML <script> integrity Attribute and you are gravy
I believe one of the big reasons why things aren't cached cross-domain is the possibility of fingerprinting by looking at which requests are cached. It's also a lot less beneficial in today's (one could say unfortunate) world of JS and CSS bundling/compilation/whatever.
That's explicitly why captive portal detection does not use HTTPS. If your OS of choice fails to detect captive portal (or doesn't implement detection), and you have the ability to visit a website, you can visit example.com to get into the captive portal.
The really annoying part is when a device (cough, Switch at launch) doesn't have portal detection nor a web browser, making it useless on hotel wifi.
I guess one could bring a laptop, spoof the Switch's WiFi MAC on the laptop and use it to login through that portal, and then disconnecting, and connect the "authorized" Switch. And make sure the Switch doesn't have "randomize MAC" like on Android/iOS.
Yep I've done it. What a pain. Thankfully now the Switch does have captive portal detect and a little purpose built web view for agreeing to the terms.
I wouldn't be surprised at all. It's not like they've got on-site IT support. Split off a guest network on its own VLAN and done, never to be touched again. The less complicated the better.
> Surely we are past this bullshit now thanks to https being everywhere?
Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. This causes HTTPS connections to fail. Captive portals are a rather inelegant hack, but in most cases they achieve what they are designed to achieve.
But once you're past the portal (even if you need to manually load example.com so you actually see it without hitting cert pinning errors), TLS gives you back the "can't touch this" you want.
Yep, and more and more OSes and browsers detect this situation and propose you a button to go to the portal. At least for me, both KDE and firefox have their mechanism for this.
It still breaks a lot of stuff (notably, the Nextcloud client) as long as you are not logged on the captive portal, but well…
Android, iOS, and windows also have this functionality. It's a shame there hasn't been a widely implemented standard for captive portal things yet. Even if what we have now works alright if you're doing web things.
> Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi.
And for all the whining about how "but DNSSEC doesn't do anything!", this is exactly an attack scenario which DNSSEC protects, and which it has protected since the very first RFC describing it. The client can check for itself whether the IP address in the response has been correctly signed by the (sub-)domain owner (and recursively whether the (sub-)domain has been signed by the parent domain, all the way back to the root).
As for "but how will I redirect hosts to my captive portal?", that's what DHCP option 114, DHCPv6 option 103 and IPv6 Router Advertisement option 37 are for. https://developer.apple.com/news/?id=q78sq5rv
If the network’s owner was the one doing DNS redirects, couldn’t they just instead use the IP address in the DNSSEC-signed record themselves? I don’t think DNSSEC is a robust protection if you don’t trust the network you’re connected to.
The attacker doesn’t resign the DNS record with their own key, they just let the legitimately signed record though and use the IP address in that legitimate record themselves. If someone owns the network (or is an active MitM) they can control where IP addresses route to.
It basically did. Cloudflare rolled out a free feature to enable HTTPS support on every site they served via (not unchecking? Don't remember the opt-in/opt-out detail) a checkbox in 2014, and less than a year later Let's Encrypt became available. Only a couple years later in 2018, Chrome and Firefox started marking non-http sites as "unsafe".
Anyone else sick of having your 4G/5G ATT, T-Mobile or Verizon service blocked when inside a hotel, a concert venue to even a small town (National Harbor DC .. a lot of businesses block your service) all so the business and or businesses around you force you to use a their Wi-fi network; collect and make money off your data. How is that even legal??
My examples in The Flamingo Hotel in Vegas you have to connect to their wi-fi while inside the hotel. Forget about trying to work remotely there and use your 5G mobile hotspot.
At the Keseya Center in Miami ... at a recent concert there they had gates with ticket takers way out of from the front of the door. You walk up to them and they say get your ticket ready and you try but nope your ATT/TMobile/etc service is blocked you can only access getting your tickets via connecting to their wifi. My 5G worked fine until i got close to those non-ticket takers who prodded me to connected to the venue's wi-fi.
National Harbor (just outside of DC) .. inside the gaylord hotel and more so inside Burger Fi and others close by both my friend's Verizon and my ATT with full bars were blocked .. had to connect to their wifi.
Total B.S. and this stuff needs to be outlawed!!! I pay for service and if its readily available (full bars) I better have access or your paying me for time you are blocking me from using it.
Can you prove this claim? It's literally illegal, and I don't believe it actually happens. There's a difference between active jamming and "our building is made of metal".
Also why when walking right up to those gates at the Keseya center outside and still outside getting right up to the gate to speak to the attendant did my service with full bars suddenly not work?
It maybe illegal but what are the profits reaped vs the potential fines?
Im usually downvoted for things I say (im sure you dont care to read all my thoughts all over the years on HN) but a LOT of them come true ... most recently about how much i hated Cruise cause they were startup bros trying to do the whole fake it before you make it with technology that can kills..fortunately it didnt kill anyone just unfortunately mangled a pedestrian. Let's see in a year if places start getting fined for this B.S.!
It looks like the device is a router and gateway for institutional networks, with features like captive portal, registration integration, etc. It isn't a dedicated JS injection device. While you can do that stuff on the cheap, $10k isn't unreasonable for networking gear with more special use-cases. The contractor likely just flipped that option on just to make a few extra bucks.
reply