More Insecure IPTVs
Last year I blogged about how I had fairly easily "hacked" the IPTV setup at a hotel in Asia, using little more than some Google searching to find a default password.
If default password weren't bad enough, a few weeks ago I managed to find something worse - a hotel IPTV system with NO PASSWORDS!
The hotel in question - a relatively new Hilton-family hotel in the US - was using Enseo brand set-top boxes to drive the TVs. The system itself was fairly basic - normal cable channels and one or two hotel-specific channels only, but no on-demand or paid channels. The connection from the STB to the network was standard Ethernet, via a very visible socket on the wall behind the TV.
Connecting my laptop to the Ethernet socket immediately gave me an IP address via DHCP, with full Internet access via a default route that was some form of HP switch (thankfully WITH a password!). After trying a few IP addresses at the base of the IP range it was fairly easy to find the server for the environment, and hitting it with a web browser immediately gave me a status page :
This also showed the IP address of a second server which gave similar ("porta")
Read-only access to a status page without a password, whilst clearly not good, isn't the end of the world. However it didn't take too long to realize that this wasn't read-only, access, but FULL access to the system, with the ability to change anything :
And even access to shutdown or reboot the system :
Plus a full list of all of the set-top boxes in the hotel, including room numbers, IP addresses, and (for those that were turned on) what channel was being watched.
The set-top boxes themselves were refusing connections on the all the usual ports, but a quick nmap scan found port 2222 open (not surprisingly, SSH), and a few other high ports that seemed to be running SSLv3 but which I couldn't successfully connect to without getting a handshake error, even with OpenSSL.
Further digging on the server found a way to access the Unix-level logs on it :
Based on the URL that was being requested in the frame that actually contained the directory view, it was fairly clear that the web server was just sharing the entire root directory of the system. Sure enough, most any path worked, and basically the entire directory structure of the system could be accessed via the browser :
Enough digging finally bought me to a file with "stb_ssh_key" in the name :
Turns out the Dropbear SSH server/client use a different key format to OpenSSH/putty, so a conversion was required, but once that was done this key (with no passphrase) happily provided full root access to not just the STB's, but also the two servers.
Of course, I wasn't out to break anything - but it would have been trivial to do so. In addition to having the ability to reconfigure (including "factory default") or reboot/shutdown the system via the web interface, root access on both the servers and all of the STB's left the environment open to breaking things in ways that would potentially not be recoverable from without a lot of effort, if at all. Or I could have just uploaded my own firmware to take control over everything at an even deeper level than I already had :
The only partial saving grace with this environment was that it is NOT accessible from the Internet (as the previous system I blogged about was - and indeed still is over a year later!), and the TV network did not appear to be accessible from the guest wifi, meaning in order to gain access you'd need to be actually staying in the hotel.
As before, attempts to contact the relevant people at the hotel to report the problem fell on deaf ears. The manager did initially respond to my emails, but after I advised him I wanted to report an IT security issue he failed to reply, and has not responded to further email.