Document the Story of Your Social Life with 8tory

The different forms of social media are growing every day. It’s hard to imagine a day … more

Make Calling Your Loved Ones Easier and Cheaper this Diwali

Diwali, or Deepawali as some Indians call it, is the pride and joy of Indian … more

Big Android BBQ 5.0 Recap – XDA TV

This fifth annual Big Android BBQ has come and gone. The speakers have spoke, the sponsors have … more

Microsoft to Counter “OK Google” with Bing Torque

When Microsoft is making apps for Android, users should be aware that something … more
Post Reply

[Q] Could it be possible to install an OTA update from a different OTA server?

OP trascendence

10th April 2014, 11:36 AM   |  #1  
OP Junior Member
Thanks Meter: 0
 
11 posts
Join Date:Joined: Feb 2011
Is there anyway of installing an OTA update from a different OTA server? Maybe routing the OTA server's address to a local personal OTA server address and forcing the Chromecast to install a rooted ROM?
Last edited by trascendence; 19th May 2014 at 06:58 PM.
10th April 2014, 03:21 PM   |  #2  
Senior Member
Thanks Meter: 15
 
175 posts
Join Date:Joined: May 2008
Yes, but you have to be rooted to do it.
10th April 2014, 05:13 PM   |  #3  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 866
 
2,225 posts
Join Date:Joined: Oct 2010
Donate to Me
More
Quote:
Originally Posted by MadBob

Yes, but you have to be rooted to do it.

Hence the chicken-and-egg scenario...

The OTA server communication goes through HTTPS, so Chromecast has its security certificate.
If you were to do a MITM attack, you don't have Google's certificate, so the HTTPS request will fail.

It would be easy if you could add your server's certificate to Chromecast.
But that requires having root, which we don't have.

Also, the secure bootloader will only load Google-signed code.
So you'd need to have Google's private key, which nobody but Google has.

Running a custom player app (that runs on Chromecast) to find a vulnerability is challenging too.
In order to run a "custom" player app, you need to sign up to be a Google dev.
The player app will only run for your registered Chromecast(s), not anyone else's.
Adding to that, almost all apps run in a Chrome sandbox.

In order for a player app to run for everybody, it Google has to put it on their whitelist.
Which essentially means even if you were to find a vulnerability, Google would be able to yank your player app almost immediately.

Then Google would patch the exploit and release a new firmware...
Stock Chromecasts auto-update and you can't (yet) choose not to accept the update, so you can't avoid the update while still being able to use Chromecast (this might be possible through router blocking/redirection - not sure).

So what does that leave?
A client-side app that somehow takes advantage of a vulnerability in an existing Chromecast player app or service.
Google would still be able to force the developer to update the app, or they themselves could update the firmware, but at least a client-side app could be available for Chromecasts with builds still vulnerable to it, similar to how FlashCast is available for Chromecasts that still have the vulnerable bootloader.
...and of course the existing FlashCast for those few Chromecasts that still have the vulnerable bootloader.

Wish I was artsy enough to make an infographic, heh.
The Following 2 Users Say Thank You to bhiga For This Useful Post: [ View ]
10th April 2014, 05:30 PM   |  #4  
OP Junior Member
Thanks Meter: 0
 
11 posts
Join Date:Joined: Feb 2011
...
Last edited by trascendence; 19th May 2014 at 06:56 PM.
10th April 2014, 07:22 PM   |  #5  
Senior Member
Thanks Meter: 313
 
1,829 posts
Join Date:Joined: Dec 2007
Quote:
Originally Posted by bhiga

In order for a player app to run for everybody, it Google has to put it on their whitelist.
Which essentially means even if you were to find a vulnerability, Google would be able to yank your player app almost immediately.

You know that fact poses an interesting question....

We already have people redirecting DNS to change location...

How hard would it be to redirect a call to the Whitelist server and redirect it to another that has a Whitelist that is not controlled by Google?

It would have to be done at the router since you can't change it in the CCast without root but it should be possible to redirect the link to some other Whitelist that we could add any app we wanted to it.

Are there any other security checks tat would prevent it? I tend to doubt it as we have been able to download the App list via PC and I'm pretty sure that App list is the main Whitelist (I could be dead wrong here)
10th April 2014, 09:39 PM   |  #6  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 866
 
2,225 posts
Join Date:Joined: Oct 2010
Donate to Me
More
Quote:
Originally Posted by Asphyx

You know that fact poses an interesting question....

We already have people redirecting DNS to change location...

How hard would it be to redirect a call to the Whitelist server and redirect it to another that has a Whitelist that is not controlled by Google?

It would have to be done at the router since you can't change it in the CCast without root but it should be possible to redirect the link to some other Whitelist that we could add any app we wanted to it.

Are there any other security checks tat would prevent it? I tend to doubt it as we have been able to download the App list via PC and I'm pretty sure that App list is the main Whitelist (I could be dead wrong here)

Essentially it's the same problem as redirecting the Google OTA server.
It's HTTPS and therefore requires that Chromecast has the server's certificate, adding the certificate requires root.

I do not believe HTTPS can be redirected in a simple rerouted response manner.
10th April 2014, 10:02 PM   |  #7  
Senior Member
Thanks Meter: 313
 
1,829 posts
Join Date:Joined: Dec 2007
Quote:
Originally Posted by bhiga

Essentially it's the same problem as redirecting the Google OTA server.
It's HTTPS and therefore requires that Chromecast has the server's certificate, adding the certificate requires root.

I do not believe HTTPS can be redirected in a simple rerouted response manner.

Yes but server certificates are enforced on the server side aren't they?

Perhaps not....
10th April 2014, 10:34 PM   |  #8  
Recognized Developer
Flag Waltham, MA
Thanks Meter: 215
 
188 posts
Join Date:Joined: Jul 2010
Donate to Me
More
Just to add to @bhiga's excellent explanation: it is actually possible to run a custom web-based player on an unrooted Chromecast, since several whitelisted apps (for example, Google's "TicTacToe" demo app) are served over plain, unencrypted HTTP. That means that a potential root exploit has the ability to load arbitrary HTML/JavaScript on the device. However, this gets us nowhere because of web apps' inherent lack of trust and Google's extensive sandboxing to prevent accidental vulnerabilities (I wrote more on this here).

With regard to the original question, even if we were able to bypass the HTTP certificate checking of the updater, the Chromecast's recovery would still refuse to apply our rooted update since it wouldn't be signed with Google's keys. If this weren't the case, we would simply be able to craft an update file that installed the original, vulnerable bootloader to the device and from there use FlashCast like we do now.

---------- Post added at 05:34 PM ---------- Previous post was at 05:25 PM ----------

Quote:
Originally Posted by Asphyx

Yes but server certificates are enforced on the server side aren't they?

Perhaps not....

The Chromecast contains a list of trusted certificates for "google.com" locally, and only Google has the private keys which allow them to serve files using those certificates (I'm simplifying quite a bit here; if you're interested in the actual "certificate authority" system used, Wikipedia has a good overview) . We can't modify the trusted certificate list without root, and we can't get root (using any of the methods discussed here, at least) without having the private key to a trusted certificate for "google.com". So it's a chicken-and-egg problem, just like any well-designed security model is. (If you already have the keys to the kingdom, it's easy to do whatever you want. Getting the keys is the hard part.)
The Following 3 Users Say Thank You to tchebb For This Useful Post: [ View ]
11th April 2014, 07:31 PM   |  #9  
Senior Member
Thanks Meter: 313
 
1,829 posts
Join Date:Joined: Dec 2007
Quote:
Originally Posted by tchebb

The Chromecast contains a list of trusted certificates for "google.com" locally, and only Google has the private keys which allow them to serve files using those certificates (I'm simplifying quite a bit here; if you're interested in the actual "certificate authority" system used, Wikipedia has a good overview) . We can't modify the trusted certificate list without root, and we can't get root (using any of the methods discussed here, at least) without having the private key to a trusted certificate for "google.com". So it's a chicken-and-egg problem, just like any well-designed security model is. (If you already have the keys to the kingdom, it's easy to do whatever you want. Getting the keys is the hard part.)

Thanks. I was under the (false apparently) impression that the Server was the one that did Cert checks not the client and if the client did not have the proper cert the Server could send one or deny sending it data.

But I guess your saying that the CCast will also check to see if the Cert is valid on the server side before it will accept communication.

Which would require a Google Cert on the Server side.

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

Advanced Search
Display Modes


Top Threads in Google Chromecast by ThreadRank