Funny to see this question, after I just read a blog
(
http://justinsomnia.org/2012/04/hotel-wifi-javascript-injection/)
discussing a different hotel practice involving javascript injection.
I'm not tech savvy like the blog's readers are, but it seems to boil
down to that
1. hotels are businesses,
2. wi-fi service is a revenue/cost center for hotel operations and a
required amentity for hotels to retain business,
3. hotel wi-fi may (or may not be farmed out) to 3rd party companies,
4. at least one eqpt mfr offers routers(?) that can inject javascript
on the fly at the router into the content you view in order to place
ads to increase the revenue (decrease cost) to the hotel
The comments section got into a short discussion about the
legality/ehtics of this. The comments IMO were very useful to read and
get a better understanding of the practice.
Long and short seemed to be that one should not expect hotel internet
services to be secure and that using VPN or SSH would give more
security. Such steps also seemed to be more effective if the end user
is more tech savvy.
Thanks, good article, excerpts below. It still does not answer the question of whether it's possible, akin to what the article you referenced wrote, whether it's possible to do this type of "man-in-the-middle" attack for HTTPS. But it suggests it is possible to spoof your HTTPS certificate (or notspoof it but have a proxy for it on the hotel server). That way the hotelcan read your HTTPS data. Why they would do that and risk lawsuits is another matter, and if it's a reputable hotel it's unlikely, but this hotel below was potentially reading unencrypted mail and it was reputable, a NYC Marriott.
RL
I found a utility that unpacks packed JavaScript, and it only took a quick skim of advnads20.js (over 1900 lines reformatted) to estimate that its primary purpose is ad injection/takeover. The good news is, this explains why all the embedded YouTube videos in Google Reader were showing up as empty black squares.
But the question remains, did the hotel’s wifi access point get hacked, or is something more nefarious at work? Is it possible that the hotel’s internet service provider is doing this on purpose? Could it be that the Courtyard Marriott in Times Square is actually aware of and condoning this typeof bad behavior?
In any case, who the heck do I report something like this to?
Update: I really wanted to give Marriott the benefit of the doubt, but it turns out I was wrong. There is something more nefarious at work. Thanks to Danny in the comments, I learned that the “rxg” I saw in the injected CSS and JavaScript is short for Revenue eXtraction Gateway, a wireless hotspot gateway product built by RG Nets, Inc., and available for sale from WlanMall.
RG Nets RXG-A8 Revenue eXtraction Gateway
RG Nets RXG-A8
In short, the Courtyard Marriott is using the RXG to inject JavaScript intothe HTML of every webpage its hotel customers view for the purpose of injecting ads (and in the meantime, breaking YouTube). Marriott’s wireless internet service provider is a third-party company called Hotel Internet Services, so it is possible, though unlikely, that Marriott doesn’t know what’s going on. But it’s crazy to me that I’m paying $368 a night for a hotel room, and this is how I get treated.
Update: I guess not all press is good press. Ronen Isaac (coincidentally ofWlan Mall) appears to have taken down the Vimeo video (I had previously embedded above) that I thought did such an excellent job describing how the Revenue eXtraction Gateway worked.
Sorry, “RGnets RXG Injection Advertising Demo” was deleted at 10:17:28 Fri Apr 6, 2012. We have no more information about it on our mainframe or elsewhere.
Good thing RG Nets still has the video up on their own site! And thanks to The Verge, there’s now a copy of the video up on YouTube that I can embedfor your viewing pleasure:
Update: Here’s a round-up of people talking about Hotel Wifi JavaScript Injection around the web:
Hacker News
MetaFilter
Digg
Reddit
TechCrunch (twice!)
The New York Times’ Bits Blog (twice!)
The Verge (twice!)
The Huffington Post’s Gadling Blog (twice!)
heise online
Boing Boing (though they didn’t link to my post!)
Update, April 9, 2012: I just received the following message from a representative of Marriott:
As soon as we learned of the situation, we launched an investigation into the matter. Preliminary findings revealed that, unbeknownst to the hotel, the Internet service provider (ISP) was utilizing functionality that allowed advertising to be pushed to the end user. The ISP has assured the hotelthat this functionality has now been disabled.
While this is a common marketing practice with many Internet service providers, Marriott does not condone this practice. At no time was data security ever at risk.”
Though I’d question the assertion that network-level JavaScript injectionis a “common marketing practice”, I’m glad they say it has been disabled. I’m currently back in San Francisco, so I have no way to confirm, but I’ll likely be back in NYC staying at the same hotel in a month.
Update: Something has bothered me about Marriott’s official response above. I completely get that Marriott is a large sprawling corporation, and it’s likely that the right hand often does not know what the left hand is doing. I get that. I’ve worked in much smaller organizations where that has been the case. I also get that their response is a typical, old school public relations gloss over the problem—without any satisfying transparencyas to how the problem came to be or any meaningful details about how it was ameliorated.
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/HotelInternet Services didn’t want that feature, then they probably could have requisitioned cheaper, less specialized, and more robust networking hardware.
Which means that the optimal solution to this snafu wasn’t simply that “we’ve disabled the functionality”—it has to be “we’ve removed/replaced the offensive hardware”. Nothing less is sufficient. Otherwise, what’s to stop someone from accidentally (or otherwise) re-enabling it later?
