Blog: Android
New Chromecast & Chromecast Audio. Have they fixed their hijacking issue?
Written in partnership with Minh-dat Lam.
Back in 2013 the first ever Chromecast was released and shortly after in 2014 the first Chromecast was successfully hacked.
This vulnerability was discovered by Bishop Fox and was titled “The Rickmote Controller: Hacking One Chromecast at a Time” http://www.bishopfox.com/blog/2014/07/rickmote-controller-hacking-one-chromecast-time/.
We wanted to see if Google has addressed this security concern 2 years later in their new 2015 Chromecast and Chromecast Audio devices.
Chromecast Out The Box
Initially the Chromecast comes out the box with an open WiFi connection for pairing:
No change there!
We thought we’d have a look at what services were available on the Chromecast:
Not shown: 65531 closed ports
PORT STATE SERVICE VERSION
8008/tcp open http
8009/tcp open ssl/ajp13?
Supported Server Cipher(s):
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
8873/tcp open dxspider?
8879/tcp open unknown (Online Source Code: https://android.googlesource.com/platform/system/bt/+/4cac544/btcore/src/counter.c)
We spotted comments in the online source code such as “Disable opening network debug ports for security reasons” which appears to relate to a debug service:
(UNKNOWN) [192.168.255.249] 8879 (?) open
Welcome to counters
> help
help command unimplemented
> show
counter count registered:0
Google source code also mentions:
“By default, we open up to three TCP ports that are used for debugging purpose:
- TCP port 8872 – used for forwarding btsnoop logs at real time (Note: the port is open only if “Bluetooth HCI snoop log” is enabled in the Developer options)
- TCP port 8873 – used for HCI debugging
- TCP port 8879 – used for debugging the Bluetooth counters”
Shouldn’t these be disabled for security reasons?
Chromecast Pairing process
Although there was an SSL service, the Chromecast appeared to function over clear text:
Since the pairing all happens over the default open WiFi network on the Chromecast, we thought we could just intercept the WiFi key during the pairing process?
Not the case! The client uses the public key to encrypt the WiFi password which is then sent over the open WiFi.
Attacking the Chromecast again
After our initial review, we thought we would check the original vulnerability against the new versions released 2 years later.
The attack works by preventing a Chromecast from communicating with the internet. This can be performed through a disassociation attack (or any other way to prevent internet access to the Chromecast). When no internet connection is detected, the Chromecast starts a new open WiFi Access Point that allows unauthenticated configuration.
We initially started a scan using tools such as Airmon-ng for MAC addresses that belong to Google Devices:
or
We then scanned for the MAC address of the Access Point that the Chromecast was connected to, and launched a disassociation attack:
Now we just need to scan for the Chromecast’s new open Access Point. It would appear that Google has still not fixed this issue.
We can then connect to the Chromecast’s AP in setup mode and reconfigure the Chromecast with a set of POST requests we’ve captured or manually using the app.
We also noticed that it was possible to factory reset the device via an unauthenticated POST request. This could be sent from either the network that the Chromecast was connected to, or the setup WiFi network:
Origin: https://www.google.com
Content-Length: 16
Content-Type: application/json
Host: 192.168.255.249:8008
Connection: Keep-Alive
User-Agent: com.google.android.apps.chromecast.app/1.12.32 (Linux; U; Android 4.4.4; Nexus 4 Build/KTU84P)
{“params”:”fdr”}
Although we saw requests with a device ID, this was not required as a layer of authentication to factory reset the device.
~~~CUT~~~
{“app_id”:”E8C28D3C”}
Now what?
With access to the setup network, or the device in a factory-reset state, it would be possible to connect the Chromecast to the attacker’s network, and stream arbitrary content to the user’s screen. Anywhere that the Chromecast’s WiFi network extends to is vulnerable to this attack. It would be trivial to play content on your neighbours Chromecast within minutes. One notable feature of the Chromecast is the ability to switch on a television when content starts playing. This makes this attack particularly effective.
Conclusion
We understand that the Chromecasts reverts back to a “Setup” mode when it cannot detect a network, which is designed for transportability, however, we don’t understand why there is no “reset” or “sync” style button on the devices that would safely revert the devices back to a “Setup” mode instead. The device already has a button that could be used for this feature.
Surely this is a simple fix to prevent the de-authentication style hijacking attacks?
