Hotel WiFi JavaScript Injection (2012)(justinsomnia.org)
justinsomnia.org
Hotel WiFi JavaScript Injection (2012)
https://justinsomnia.org/2012/04/hotel-wifi-javascript-injection/
73 comments
This is why I make sure my personal blog redirects to https, and why I typically install things like "https everywhere" browser extensions.
I know this kind of stuff happens, and I don't want to waste time tracking it down and shaming people for doing it.
I know this kind of stuff happens, and I don't want to waste time tracking it down and shaming people for doing it.
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 know, for the longest time my hosting provider "claimed" I needed a static IP in order to have https.
It wasn't until there was a bigger push that they "realized" that https doesn't require a static IP.
It wasn't until there was a bigger push that they "realized" that https doesn't require a static IP.
It was required - back in the early aughts, and modern TLS adoption with SNI was far from guaranteed even in 2012.
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.
Is it possible for this to happen today with SMTP?
Email supports HTML/CSS/JS and is sent over plaintext, so shouldn't the same kind of injection vulnerability exist?
Email supports HTML/CSS/JS and is sent over plaintext, so shouldn't the same kind of injection vulnerability exist?
Yes, but:
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.
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.
Not over TLS, which you really should be using in this day and age.
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.
Do any major providers these days still allow unencrypted SMTP at all though? Seems like quite the security risk.
[deleted]
> and is sent over plaintext
No longer true.
No longer true.
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.
A blanket statement that all email is encrypted is just plain false.
Do mainstream client silently fall back for SMTP? Thunderbird, Evolution, Outlook, etc... ? Somehow I doubt it.
There is also word around that SMTP certificates are often not verified, but I know that's not true for Thunderbird at least.
The situation might be different between SMTP servers, but that shouldn't really apply for hotel wifi.
There is also word around that SMTP certificates are often not verified, but I know that's not true for Thunderbird at least.
The situation might be different between SMTP servers, but that shouldn't really apply for hotel wifi.
Gmail, Exchange and iCloud mail all seem to fall back on plaintext when TLS is unavailable.
Apparently gmail displays hazard icons in the UI if an email isn’t sent over TLS.
I’ve not found precise documentation about Thunderbird’s behaviour.
https://workspaceupdates.googleblog.com/2020/04/improve-emai...
https://support.apple.com/en-gb/guide/security/sec100a75d12/...
https://learn.microsoft.com/en-us/purview/email-encryption
Apparently gmail displays hazard icons in the UI if an email isn’t sent over TLS.
I’ve not found precise documentation about Thunderbird’s behaviour.
https://workspaceupdates.googleblog.com/2020/04/improve-emai...
https://support.apple.com/en-gb/guide/security/sec100a75d12/...
https://learn.microsoft.com/en-us/purview/email-encryption
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).
That's interesting. I wonder whether an ISP could block traffic using TLS SMTP ports to force opportunistic senders to revert to plaintext.
I suspect this may be possible because TLS SMTP uses port 587, rather than 443 like other TLS connections.
https://www.cloudflare.com/en-gb/learning/email-security/smt...
I suspect this may be possible because TLS SMTP uses port 587, rather than 443 like other TLS connections.
https://www.cloudflare.com/en-gb/learning/email-security/smt...
The SMTP that we're talking about uses port 25, not port 587 (or 465). But yes, an ISP could block the STARTTLS negotiation.
Port 587 is submission - an end-user's client talking to their email provider's SMTP server.
Port 25 is smtp - your email provider's SMTP server talking to the recipient's email provider's SMTP server.
Port 443 is https - not TLS. TLS can operate over any port you like. The port is determined by the service being used, not by the fact that it's TLS.
Port 587 is submission - an end-user's client talking to their email provider's SMTP server.
Port 25 is smtp - your email provider's SMTP server talking to the recipient's email provider's SMTP server.
Port 443 is https - not TLS. TLS can operate over any port you like. The port is determined by the service being used, not by the fact that it's TLS.
Add your web site to https://hstspreload.org . Problem will be solved.
If only there were some kind of way to serve HTTP over a secure connection.
Maybe even with some kind of certification authority scheme to prevent the RXG from spoofing the domain.
Maybe even with some kind of certification authority scheme to prevent the RXG from spoofing the domain.
According to Wikipedia Let’s Encrypt was started in September 2015.
They did some great work!
https://en.m.wikipedia.org/wiki/Let%27s_Encrypt
They did some great work!
https://en.m.wikipedia.org/wiki/Let%27s_Encrypt
The question is: how widespread is it in 2024?
P.S. I am always using a VPN on Hotel/Cafe WiFi.
P.S. I am always using a VPN on Hotel/Cafe WiFi.
Far less due to TLS being ubiquitous
I think this is still possible with access points that require installing and trusting a custom certificate. The example in my mind is WeWork's WiFi
Anything you can do at the network level that can MITM in 2024 for TLS without the client needing a custom cert? I assume no, but curious anyway
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).
Ah thats clever
Problem is solved with using a VPN, no?
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).
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.
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.
Only on HN will you be modded down, receive a rant from two people, only to in the end get the admission: yes, you're right.
Widespread TLS/HTTPS adoption is sufficient.
Or just TLS
Surely we are past this bullshit now thanks to https being everywhere?
Also this is our reminder that yes, HTTPS is worth it even for "It's just my blog, I have nothing to hide, why should I encrypt?"
Also this is our reminder that yes, HTTPS is worth it even for "It's just my blog, I have nothing to hide, why should I encrypt?"
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.
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 is awesome.
Propose an RFC - seriously.
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.
Propose an RFC - seriously.
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
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.
You could do it today with TLS_RSA_WITH_NULL_SHA if null ciphers were still supported.
What's the downside of HTTPS that you'd want to remove the encryption feature?
I could see some forms of advertising or spam (or scams) preferring this.
Captive portal detection is endlessly buggy.
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.
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.
But that's a huge workaround for many.
But that's a huge workaround for many.
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.
You'd be surprised how many hotels can't be bothered
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.
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…
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
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.
They don't even have to do that. If they control the network, they can just set the AD flag to 'true' in a forged DNS response.
This would break the chain of trust (you wouldn't trust the network's key signing the address for that zone).
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.
Add DoH/DoT to your reply and you're correct.
I remember when this stuff was happening. It was like the world shifted over to HTTPS instantly. Wish we could do the same for IPv6.
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".
[deleted]
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.
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.
> service blocked when inside a hotel
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".
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".
Umm it was something hotel were actively doing https://www.google.com/search?client=firefox-b-1-e&q=fcc+hot... ... you don't think some are still doing so using the whole it's a big building issue argument along the way.
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.!
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.!
Virtually all those search results are about wifi blockers, not cellular blockers, apart from one random unproven claim on Reddit.
Blocking wifi is also illegal, and you will see from your own link that the FCC did fine hotels that were doing it.
Blocking wifi is also illegal, and you will see from your own link that the FCC did fine hotels that were doing it.
On top of all the illegality involved in signal jamming....in fairness, AT&T signal in Miami is pretty awful no matter where you go IME
They aren't blocking cell data intentionally, that's extremely illegal. That's just how big buildings work dude.
And with a lot of people in one place connecting to the same cell tower that cannot reliably handle that many.
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.