Wired warns of Chromecast takeover vulnerability

Search This thread

DJames1

Senior Member
Oct 10, 2013
385
115
"Rickroll Innocent Televisions With This Google Chromecast Hack"
http://www.wired.com/2014/07/rickroll-innocent-televisions-with-this-google-chromecast-hack/

In short the video shows:
- remote device forces disconnect of Chromecast by sending deauth command over WiFi
- Chromecast reverts to Reconnect Me mode with its own WiFi
- remote device connects and takes over Chromecast

But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?

The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.
 

2600AltF4

New member
Jul 16, 2014
1
3
"Rickroll Innocent Televisions With This Google Chromecast Hack"

In short the video shows:
- remote device forces disconnect of Chromecast by sending deauth command over WiFi
- Chromecast reverts to Reconnect Me mode with its own WiFi
- remote device connects and takes over Chromecast

But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?

The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.

Hey! This is Dan, the researcher behind the story. To answer some of your questions:

The "access code" that the Chromecast shows is never actually used to authenticate people on the Wi-Fi. its only purpose is to make sure users don't accidentally connect to their neighbor's chromecast on accident. You can verufy this yourself: If you go into the Chromecast Android app and reconfigure your own Chromecast, you'll see that the app pops up with a message that says "Do you see the code 'X1B8'" (or whatever). You can just say "yes" and ignore it. The user never has to enter and verify the code itself.

As for the buffer overflow, it's true that there's no good evidence of it yet. I just haven't finished exploiting the vulnerability. Until I actually have a working exploit, there's no way to be sure that it really exists. The buffer overflow for sure exists, and it's in a remotely accessible location. But who knows, maybe there's some other wrinkle that keeps it from being exploitable. Exect to see more on that soon.

Hope that helps!
 

Asphyx

Senior Member
Dec 19, 2007
2,158
378
Android Wear
Google Pixel Watch
yep that PIN system they have is a pretty useless one considering it is more of a CHECK than a security feature....

If it was like a BT PIN where you had to enter the pin you see on the screen before you could connect it would be a real security system.

I wonder why Google hasn't thought of that,
 

bhiga

Inactive Recognized Contributor
Oct 13, 2010
2,501
1,018
Yup, any Chromecast is vulnerable to "takeover" whenever it gets disconnected from its configured WiFi AP.
Why? Because its setup mode is completely open and requires no challenge, just a response. It's like if you call a credit card company, put in a number that isn't yours, then the agent comes on the line and asks
"Are you Joe Smith?" [Yes]
"Is your password 'ChocolateMilkGivesMeGas'?" [Yes]

Because a simple reconfiguration does not seem to delete the existing WiFi supplicant data (Google could easily fix this by erasing the stored WiFi credentials once a device connects for setup), if the noted buffer overrun bug or another exploit could gain root, user's WiFi credentials are easily accessed.

Factory reset does delete the stored WiFi credentials, but nobody's going to factory-reset their Chromecast until it's already too late.

This particular issue is an issue for those running rooted Chromecasts, as all the attacker needs is a way in (which includes the Team Eureka Web Panel for those running Eureka-ROM, as the current web panel is not secured).

IMO, Google needs to make the setup more secure - ease of use should never data trump security.
 
Last edited:

DJames1

Senior Member
Oct 10, 2013
385
115
Ah, so it's not an access code, it's just an ID to help you match up the Chromecast the app sees on WiFi with the one you see on the TV screen. That certainly seems insecure, especially since there are so many other devices and apps that link up securely via a very similar-appearing access code.

Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
 

bhiga

Inactive Recognized Contributor
Oct 13, 2010
2,501
1,018
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
Yeah, Google seems to think being on the WiFi network is "secure" enough and anything else public/school/hotel is not the place for Chromecast... that logic may work in a single-family living situation, but it definitely does not work in a shared environment, and the fact that it automatically goes into Setup mode when it loses its configured AP is where the risk lies, since someone can reconfigure it to connect to their WiFi network and it still has the original user's AP credentials stored.

Google can lock things down by changing the behavior so either
  • Clear the stored WiFi credentials when the setup process begins, before Chromecast connects to another network
    This wouldn't stop some kind of remote-access exploit that can break in during setup mode, but it does stop any normal-mode exploits.
  • Require a factory reset to enter Setup mode when Chromecast is configured to connect to a WiFi network.

IMO the second one is more of the expected user behavior - when it arrives it has no credentials stored so it automatically proceeds to setup mode, but once configured it stays configured and requires reset to start configuration again.

Right now it says configured but can be reconfigured - by anyone any time the configured AP goes unavailable.
 

Asphyx

Senior Member
Dec 19, 2007
2,158
378
Android Wear
Google Pixel Watch
Ah, so it's not an access code, it's just an ID to help you match up the Chromecast the app sees on WiFi with the one you see on the TV screen. That certainly seems insecure, especially since there are so many other devices and apps that link up securely via a very similar-appearing access code.

Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.

Yeah if the made the Pin System an integral part of allowing connection then it would be MUCH more secure even if it was in open AP mode because you would still need to be in front of the TV it is plugged into to see the pin!

Odd isn't it how Google seems to have spent so much effort and time into securing what can RUN on the damn device yet took little to no interest in who could connect to it!

The fact that the worst thing possible is a bad Video Picture being displayed I guess they thought it wasn't worth the effort and was maybe too difficult for an idiot to use if it was secure!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    "Rickroll Innocent Televisions With This Google Chromecast Hack"

    In short the video shows:
    - remote device forces disconnect of Chromecast by sending deauth command over WiFi
    - Chromecast reverts to Reconnect Me mode with its own WiFi
    - remote device connects and takes over Chromecast

    But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?

    The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.

    Hey! This is Dan, the researcher behind the story. To answer some of your questions:

    The "access code" that the Chromecast shows is never actually used to authenticate people on the Wi-Fi. its only purpose is to make sure users don't accidentally connect to their neighbor's chromecast on accident. You can verufy this yourself: If you go into the Chromecast Android app and reconfigure your own Chromecast, you'll see that the app pops up with a message that says "Do you see the code 'X1B8'" (or whatever). You can just say "yes" and ignore it. The user never has to enter and verify the code itself.

    As for the buffer overflow, it's true that there's no good evidence of it yet. I just haven't finished exploiting the vulnerability. Until I actually have a working exploit, there's no way to be sure that it really exists. The buffer overflow for sure exists, and it's in a remotely accessible location. But who knows, maybe there's some other wrinkle that keeps it from being exploitable. Exect to see more on that soon.

    Hope that helps!