APKTool Updated with Android Lollipop Support

One of the beauties of Android is the level of flexibility we have over our devices. Whether … more

Lollipop Leak for Sprint Galaxy S5, TWRP for Micromax Canvas Magnus – XDA TV

Android 5.0 Lollipop has been leaked for the Sprint … more

Velocity is Like OpenTable on Steroids

We all enjoy a night out with friends or our significant other from time to time. However, there is … more

Android Lollipop Lands for the Sony Xperia Z Ultra

The undisputed king of the beasts–at least in Sony’s current stable,is the … more

Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

Wired warns of Chromecast takeover vulnerability

OP DJames1

16th July 2014, 04:59 PM   |  #1  
OP Senior Member
Thanks Meter: 104
 
316 posts
Join Date:Joined: Oct 2013
"Rickroll Innocent Televisions With This Google Chromecast Hack"
http://www.wired.com/2014/07/rickrol...romecast-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.
16th July 2014, 08:38 PM   |  #2  
Junior Member
Thanks Meter: 3
 
1 posts
Join Date:Joined: Jul 2014
Quote:
Originally Posted by DJames1

"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!
The Following 3 Users Say Thank You to 2600AltF4 For This Useful Post: [ View ]
16th July 2014, 11:16 PM   |  #3  
Senior Member
Thanks Meter: 319
 
1,847 posts
Join Date:Joined: Dec 2007
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,
17th July 2014, 02:26 AM   |  #4  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 873
 
2,237 posts
Join Date:Joined: Oct 2010
Donate to Me
More
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 by bhiga; 17th July 2014 at 02:28 AM.
17th July 2014, 03:06 AM   |  #5  
OP Senior Member
Thanks Meter: 104
 
316 posts
Join Date:Joined: Oct 2013
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.
17th July 2014, 05:19 AM   |  #6  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 873
 
2,237 posts
Join Date:Joined: Oct 2010
Donate to Me
More
Quote:
Originally Posted by DJames1

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
  1. 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.
  2. 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.
17th July 2014, 08:08 AM   |  #7  
Senior Member
Thanks Meter: 319
 
1,847 posts
Join Date:Joined: Dec 2007
Quote:
Originally Posted by DJames1

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!

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes