Fall is officially here, and that can only mean that SecTor
is right around the corner! All summer long, I’ve been planning and prepping new ideas for this year’s IoT Hack Lab and training session. With just a few weeks to go until the conference kicks off, I’m more than a little excited about the new hacks we’ll be demonstrating, dissecting and discussing at the Hack Lab.
Although I’m not going to spill all the beans, I would like to take this opportunity to introduce just one of the devices making a first-time appearance at the SecTor IoT Hack Lab. Say hello to Roku Ultra, the very capable Internet set-top box boasting an estimated 50 million online devices.
You may be thinking to yourself that I’m only bringing a Roku to watch the Mr. Robot premiere from my hotel room…
Actually, you’re right. Partly. See, I usually do this kind of thing from my computer, but this time I wanted to do it AFK. In person.
We will be using the publicly available Dolos framework
to show how a fully patched Roku with the default configuration can be usurped by malicious web content to force attacker-controlled content onto the screen. This means that by simply opening the wrong web page, someone else can instruct all Rokus on your network to immediately start streaming an arbitrary video from the Internet, and it doesn’t take Elliot Alderson to see how this can end badly. TVs connected to the Roku can even be powered on by this attack if they are configured to use HDMI-CEC with Roku.
Roku fixed DNS rebinding attack vectors last year but made the decision to leave the default configuration exposed to cross-site request forgery. Capturing traffic
while initiating a stream to Roku from AllCast
reveals the HTTP request which is used to initialize a media player and load supplied URLs. (One might also find the same information by searching the Roku forums
.) The problem with the request being made is that every attribute (with the arguable exception of IP address) is known in advance to the attacker. The IP, however, is hardly a secret, and Dolos
Roku put in the effort to quickly fix their DNS rebinding problem but stopped short of preventing the CSRF “Rick Roll” style attack in the default configuration. I’ve discussed this behavior with Roku, who confirmed that this is a “design trade-off to enable third-party application development and ease of use” rather than a vulnerability. They further noted that the affected functionality can be disabled by going into:
Settings -> System -> Advanced System Settings -> Control by mobile app -> Network access -> change Default to Disabled
Starting with Roku OS 9.0 (May 2019), disabling this feature restricts the device to only allow the Roku mobile app
to control the device. Based on my testing, this means it is not possible to send content directly from Netflix, Hulu, etc. while also preventing this kind of screen hijack.
While some may classify this as a nuisance bug, it can, in fact, have many real-world impacts. Consider, for example, surfing the web and all of a sudden all of your TVs turn on and start playing a fake emergency broadcast. We’ve seen what Internet creeps will do with baby monitors
, so we can only imagine what they might do when realizing that TVs may also be at their whim. The problem only gets worse when considering a more determined attacker. Media parsers are notorious for memory corruption bugs allowing code execution, and this vector is allowing the attacker to supply Roku with a file to play. It is almost inevitable that a determined attacker could string together an RCE payload to completely take control of Roku through unauthenticated CSRF.
For more information about this or other hacks, reach out to me on Twitter
or, better yet, swing by the IoT Hack Lab at SecTor
, say hi and hang out for a hack or two!