Hacking 82 Hotel TV Systems in 82 Minutes or Less

Security is hard to get right, there's no question about that.  But sometimes you come across things that are just so simply insecure that it's clear nobody put any thought into security - and there's no excuse for that, especially when it's done by a company that claims to "specialise in [...] Networking Technologies".

I've blogged before about some of my digging into Hotel IP-based TV systems, where with minimal effort I was able to obtain everything from basic access right up to full, remote access to the hotels entertainment systems.  (4 years later that particular system is still up and running, and still remotely accessible with default passwords)

However when staying in a hotel in New Zealand recently I came across what could only be described as the motherlode - full root access not just to that hotels TV systems, but also to the equivalent systems in 81 other hotels.  And all of it accessible over the internet!

IPTV

I always love walking into a hotel room for the first time and seeing "Hello Mr Howard" on the powered-on TV screen.  It means that the hotel is using some form of intelligent TV system - one that can turn the TV on or off on-demand, and display custom content.  In the case of this particular hotel in New Zealand, there was no Set-top box, but just an IP-based TV.  In general these TV's themselves are fairly secure and uninteresting, which normally limits what can be found, but still leaves the potential for an insecure server driving them.

After a few seconds of network snooping I had the IP address of the server, and from the network snooping alone I could tell this was a system I'd come across before and not had any luck with, so I wasn't expecting much.  A nmap on the server showed a myriad of open ports - everything from the expected 22 (SSH) and 80/443 (used by the TV, if nothing else), through to a number of more interesting things like 3306 (MySQL), 2049 (NFS) and 139/445 (CIFS), as well as a number of seemingly random ports like 81, 82 and 5555.

Ports 80 and 443 as expected both had web servers running on them, but with no default page and no indication of valid paths other than those that I'd see on the network capture before (which were just TV-Server communication). MySQL and NFS also turned out to be uninteresting (no access and nothing shared respectively), but scanning CIFS showed a number of shares available :

Including one that allowed guest access :

Not surprisingly given the "back" in the name of the share, this contained a number of dated directories that contained backup copies of what appeared to be the entire server.  However very surprisingly, it didn't contain backups for the server in this hotel, but instead about 70 other unrelated hotels around the APAC region!

Digging through one of these backups turned out to be a goldmine in terms of understanding the system, and gave URL paths to access the IPTV system itself, to a copy of phpMyAdmin (a web-based MySQL admin tool), password files (both system and application level), as well many other interesting looking things.

phpMyAdmin, with default MySQL credentials of course, gave access to the MySQL data, and some tables that included user credentials.  To their credit, these were hashed. Not so much to their credit, most of the hashes were trivially reversed with a simple Google search - not surprising given that they were the same as the username in most cases...

These passwords could then be used to access the two main web GUI systems on the box - one called 'NTV-Admin' and a second called 'ADS'.

NTV-Admin

NTV-admin turned out to be a fairly typical Hotel TV admin GUI, and the password gathered above gave full admin access to it. This allowed access to a number of things such as hotel occupancy (128 rooms checked in) :

Listings of all of the movies available, plus the ability to add/delete movies, change prices, etc (not as interesting as it seems given that all movies were free to start with!) :

View details of which rooms were checked in, who was checked into them, and even when they had checked in :

And even a historic record for each room, including all guests checking in and out for the past >12 months - this time even with first names (masked) :

Plus the ability to remotely control the TV, or even send a message to be displayed on a single TV, or all TVs in the hotel.

ADS

However it is the 'ADS' system that turned out to be far more interesting.  I'm still not entirely sure what 'ADS' stands for, but it was the first few items on the menu that looked most interesting - "Root options" and "Cross-site Management" :

Root options

You can can probably already guess what an option called "Linux Console" under a menu with "Root" in it does, but for completeness...

From 1 to 81

A quick look at the Linux level showed a number of ssh processes being used to open TCP tunnels between this system and a master system at the softwares vendor, as well as some scripts to facilitate backing up between different customers - which explains the backup files that started it all.  This also showed that it was possible to jump between the systems at various customer sites via the vendors central system.  Not surprisingly, the systems all seemed to use the same passwords and the same root SSH keys for access, with all of the relevant private keys being stored on the system with no passphrase.

ie, access to one system gives full access to ALL of the other systems, located at other hotels around the world!

Coming back to the 'ADS' web interface and going to "Cross-site Management" gives us a list of all of those systems - with a total of 82 systems showing a "cloud_online" date within the last few hours, implying they were actively connected (there were a dozen others that had not connected for some time, including some demo systems) :

Remember those TCP tunnels I mentioned above?  Well clicking on the links in the table above takes us to a URL that points to the vendors system, with a unique port for each system - which then forwards over that SSH-forwarded TCP tunnel back to the relevant system.  ie, every single one of these systems is accessible via the internet, with the traffic being forwarded by the system vendor! What's more, after attempting to access the system they show up in the "Recent" list, where in addition to the forwarded URL being listed, for many systems so is a "direct_access" URL which provides access to the system directly without having to route through the vendor.

Summary

There's so much wrong here it's hard to know where to start.  There's the obvious security issues such as :

• Default passwords used everywhere
• Same SSH keys used on all systems
• Many systems directly accessible via the Internet
• ALL systems accessible over the internet via the vendors system
• All access over unencrypted HTTP.
• No additional authentication to obtain root access on the systems.
• CIFS shares containing backup data (including passwords/shadow files/etc) with guest access

And that's really just scratching the surface.  However there's the potentially bigger issues that each customers system seem to be being used as backup targets for others customers - many of which would be competitors. This data, which is stored without any form of encryption and (in at least the case of this system) zero authentication, could be mined to find out things like occupancy rates for a competing hotel given it contains checkin/checkout data.