Dear Team Eureka there is one thing you may do with security of Chromecast that Google did not.
You may add the missing security feature:
"if there is no connection to preset network" - "do not enable unprotected wifi ap mode" unless user will press reset button for short time (something like enable/disable wifi feature with openwrt)
There is plenty of things you ma use button for in future
(you may use different functions within different interval)
press
1-5 seconds
6- 15... and so on
I like this feature!
I agree that the way it is currently working is not as secure as it could be...
But I think the better way to do all of this is the following:
1 - Never have the CCast automatically connect to an Open Wireless unless specifically told to via Setup (not sure if it does this now or not)
2 - (and this would be the alternative to your suggestion) CCast doesn't leave any unprotected network sans AP connection for setup. It's default setup mode is a protected WiFi either WEP or WPA
CCast should instead set a random pin/pass and WPA/WEP connection for use in setup when it can't find an authorized AP.
Since you should have access to the screen it is plugged into and hackers would not, you would make the connection to the CCast in protected mode using the PIN that is displayed on the screen to make the connection to the protected network. Once connected you set up the device normally.
Much better than walking over to the TV and device to press a button and much more secure because the only way to set up or take over the unit requires access to the TV it is plugged into.
As far as the Button is concerned I would really like to see it used to switch modes and add a DLNA device mode to the custom rom. Unless the ROM could add this feature while still in CCast mode.
Asphyx said:
1 - Never have the CCast automatically connect to an Open Wireless unless specifically told to via Setup
2 - (and this would be the alternative to your suggestion) CCast doesn't leave any unprotected network sans AP connection. It's default setup mode is a protected WiFi either WEP or WPA
CCast should instead set a random pin/pass and WPA/WEP connection for use in setup when it can't find an authorized AP.
Since you should have access to the screen it is plugged into and hackers would not, you would make the connection to the CCast in protected mode using the PIN that is displayed on the screen to make the connection to the protected network. Once connected you set up the device normally.
Click to expand...
Click to collapse
AFAIK Chromecast never does #1 - it won't auto-connect to any AP unless it's already set up.
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Since the serial number is easily accessible on the unit itself and its box, that could be an easy-to-get password, and the 4-character alphanumeric ID shown on the TV could be a secondary confirmation for Setup, not just a convenient way to make sure you're connected to the correct Chromecast (does Google really think/hope there will be that many Chromecasts out there being set up at the same time?).
Also if http will be protected with https also passwords it may be better to config Chromecast wireless options via https/ssh.
Is there any way to implement power save for example trigger via ssh/https?
bhiga said:
AFAIK Chromecast never does #1 - it won't auto-connect to any AP unless it's already set up.
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Since the serial number is easily accessible on the unit itself and its box, that could be an easy-to-get password, and the 4-character alphanumeric ID shown on the TV could be a secondary confirmation for Setup, not just a convenient way to make sure you're connected to the correct Chromecast (does Google really think/hope there will be that many Chromecasts out there being set up at the same time?).
Click to expand...
Click to collapse
Thats why I think whenever it can't find an AP to connect to it shouldn't take anything for it to generate a random password (changes everytime) that can be used until setup is complete...
As for HTTP access i it is not connected to an AP there really is no HTTP available until you have connected to it in some way.
I would be happy if Google allowed us some config tools but I don't think they are all that interested in us having control over the unit for DRM purposes.
The devs at Plex have even said that Google will not allow them to implement sending to CCast as part of their Local PlexWeb (Plex.TV is fine though)
This suggests they really do not want anything they can't approve or any usage that could expose how the device is talked to being left open to the public.
I guess they figure that if we can see how linkage and communication is done we will reverse engineer it to play and do things they don't want us doing or bypassing DRM schemes as they currently work.
bhiga said:
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Click to expand...
Click to collapse
WEP is broken for over 10 years now! No sane human being is using it. Cracking WEP is extremely fast and easy. WEP is a false protection, illlusion of security. Using WEP is BLASHEMY.
mathorv said:
WEP is broken for over 10 years now! No sane human being is using it. Cracking WEP is extremely fast and easy. WEP is a false protection, illlusion of security. Using WEP is BLASHEMY.
Click to expand...
Click to collapse
Obviously you feel strongly about WEP.
I'm not going to argue that, because you are right that WEP is easily broken. WPA can be broken too, but with more effort.
That said, WEP is an illusion of security only if you expect it to be unbreakable, just like passwords and everything else.
Seat belts won't save you in every accident, but if you don't expect them to, they are still helpful in the event of an accident.
Now if you're driving recklessly because you think seat belts and air bags will save you, then yes it is a false sense of security and you're foolish to take extra risks.
But for the Chromecast setup AP that is temporary by nature, are you suggesting that it is better to not use any security at all, just as it is right now?
You know what I always say.....
"Just because you are Diagnosed Paranoid doesn't mean people aren't out to get you!"
LOL
This is the second conversation regarding CCast vulnerability and so far all we have identified as a REAL security concern is that someone could set up the CCast to connect to some WiFi other than yours which would lead to the grand total tragedy that they could send content to your TV.
The other conversation was in regards to the Rooted ROM having SSH and Telnet installed that could be used to hack your Router Password provided you had already hacked the router password to make the connection to the CCast in the first place to use those tools to get what you already have!
Here is something folks should take into account....NOTHING IS SECURE EVER!
Even the Servers in Iran's Nuke Plant that had no connection to the outside world whatsoever were compromised, Hacked and attacked by Stuxnet!
There is no security ever the only thing you can ever really do is make the hack hard enough and as time consuming as possible that they will move onto someone else's system to pry into their Word Docs and that private folder you keep your IFriends profile pictures in instead. LOL
Yes WEP can be hacked. Imagine how much fun someone will have after they set up your CCast to use their network and try to send content to a TV never knowing if you actually noticed it or not because they can't see your TV.
It's still a damn site better than leaving an Open WiFi AP on the CCast until setup which takes no hacking skill at all to crack.
The way I look at it if the person is smart enough to hack they are also smart enough to know there is no point in hacking a CCast...Not when there is a WiFi router that gets them a hell of a lot more personal info and much more access than just displaying content to your TV.
Asphyx said:
This is the second conversation regarding CCast vulnerability and so far all we have identified as a REAL security concern is that someone could set up the CCast to connect to some WiFi other than yours which would lead to the grand total tragedy that they could send content to your TV.
Click to expand...
Click to collapse
While this would be a great dorm prank, at least with the current functionality of Chromecast, that's all they get to do... turn on the TV and send whatever video to the TV they want, which would be quite scary/annoying. Think of the beginning of Back to the Future Part II where all the screens in the house turn on with Marty's boss telling him he's fired.
Asphyx said:
The other conversation was in regards to the Rooted ROM having SSH and Telnet installed that could be used to hack your Router Password provided you had already hacked the router password to make the connection to the CCast in the first place to use those tools to get what you already have!
Click to expand...
Click to collapse
Actually I think the scenario @mathorv described is a little different and easy to exploit.
Chromecast is in setup mode and broadcasting an open AP
Attacker connects to the open AP
Attacker connects to Web Panel and enables ADB/Telnet/SSH (because web panel currently does not require authentication, Team Eureka said authentication is coming)
Attacker connects to Chromecast via ADB, Telnet, or SSH and gets access to the root filesystem, where they can see the cleartext password and SSID of the AP that Chromecast normally connects to (because password is stored in supplicant config file which is accessible)
So the attacker does not need anything more than to see the Chromecastnnnn AP.
Sadly, the WPA authentication seems to be stored the same way on phones/tablets as well. The only thing that shields phones/tablets from the same type of attack is not all of them have root and they usually aren't accessible from the network. Hence, with root comes extra responsibility, which is why root often is made difficult.
Asphyx said:
Here is something folks should take into account....NOTHING IS SECURE EVER!
Click to expand...
Click to collapse
Yup. What we commonly call "security" is really just a deterrent. It increases the effort and the hope is that the attacker will pick an easier target. It's why we put locks on doors when it's often relatively simple to bypass them.
bhiga said:
Chromecast is in setup mode and broadcasting an open AP
Attacker connects to the open AP
Attacker connects to Web Panel and enables ADB/Telnet/SSH (because web panel currently does not require authentication, Team Eureka said authentication is coming)
Attacker connects to Chromecast via ADB, Telnet, or SSH and gets access to the root filesystem, where they can see the cleartext password and SSID of the AP that Chromecast normally connects to (because password is stored in supplicant config file which is accessible)
So the attacker does not need anything more than to see the Chromecastnnnn AP.
Click to expand...
Click to collapse
Except for the fact that if it is not connected to the router then that means the router is unavailable, and or the Password saved in cleartext isn't working. If it was it would be connected and not in Setup mode.
Thats the point I was trying to get across there....
Sure you could find passwords to APs the CCast was connected to...
But if it isn't connected at the time of the hack then those APs are not available if they were you would not be able to connect to the CCast.
And if they are available then anything saved in the CCast is worthless since the CCast couldn't use it to connect either.
And I told him how to plug that hole far better than via the ROM....
Turn on Mac Filtering so not only do you need the password but need to clone a MAC address as well.
And all of this to get at what?
Your last will and testament and some compromising Pictures?
If you make it difficult enough that the payoff isn't worth the effort they will move on....
Asphyx said:
Except for the fact that if it is not connected to the router then that means the router is unavailable, and or the Password saved in cleartext isn't working. If it was it would be connected and not in Setup mode.
Click to expand...
Click to collapse
Ahh, I see your point now.
At least for me, sometimes Chromecast will "miss" the connection shortly after boot, so the setup AP is available for a few minutes after a reboot. To exploit that, someone would need to be sitting and listening for it to pop up - not a "juicy" target, but still possible. People do strange things "just because they can" - at least that's what YouTube teaches me.
As you say, MAC filtering provides an additional deterrent level. Unfortunately the target customer is probably not sophisticated enough to do that. I'm not sure all ISP-provided devices (I avoid integrated hardware that I can't configure) allows setting MAC restrictions though.
Asphyx said:
But if it isn't connected at the time of the hack then those APs are not available if they were you would not be able to connect to the CCast.
And if they are available then anything saved in the CCast is worthless since the CCast couldn't use it to connect either.
Click to expand...
Click to collapse
Well, in theory, you could connect to the CCast when it is in unprotected AP mode, enable ssh, and write a shell script which gets started every boot and sends out the saved wifi password somewhere to the internet. Then, when the CCast owner sets up is wifi, and sometimes later reboots, the wifi passwords will be sent out.
But... since there are probably only a few thousand rooted Chromecasts, and the time window in which to push the script to the Chromecast is so narrow, I doubt anyone would spend any time to try this.
bhiga said:
Unfortunately the target customer is probably not sophisticated enough to do that. I'm not sure all ISP-provided devices (I avoid integrated hardware that I can't configure) allows setting MAC restrictions though.
Click to expand...
Click to collapse
I'm sure thats true but if your not sophisticated enough to control your own Network or let an ISP do it all for you the least of your issues are what might happen in the odd chance CCast is disconnected or in the 30 seconds before it connects to an AP during Bootup. Locking up the holes in a CCast sure isn't going to help you much LOL
frantisek.nesveda said:
Well, in theory, you could connect to the CCast when it is in unprotected AP mode, enable ssh, and write a shell script which gets started every boot and sends out the saved wifi password somewhere to the internet. Then, when the CCast owner sets up is wifi, and sometimes later reboots, the wifi passwords will be sent out.
Click to expand...
Click to collapse
Well in theory you could have it do location checks with Google and map location, SSID and Password of every AP it ever connects to...
Like I said to what end would someone do that?
What is the PAYOFF in the end?
I could understand it if your living next to Bill Gates and wanted to steal banking info....
The Average Joe doesn't have anything worth seeing that would make someone go through all of that especially when they could get it much easier by just sniffing WiFi packets and finding the same data and decrypting it.
They could sit there all day and hack the Router but they have such a small window to work with on an unconnected CCast either because they have to catch it rebooting or catch it in a location that it isn't setup for and unless you have written a program to do all of that without Human Intervention you still got a snowballs chance in hell of getting any worthwhile information...
Security only happens when there are multiple layers of protection that make it so difficult to breach that they won't bother unless the payoff is worth it.
Someone really has to hate you in order to go through all that so some of the best security practices you can implement is don't be an AZZ and no one will have it out for you enough to want to get something on you via a Hack! LOL
(Not suggesting anyone in this discussion is just saying in General LOL)
Asphyx said:
Like I said to what end would someone do that?
Click to expand...
Click to collapse
Well, would you give me your WiFi password?
I can think of a few things you could do with access to someone's WiFi... Free internet, torrenting on someone else's responsibility, or just messing with someone.
Asphyx said:
I could understand it if your living next to Bill Gates and wanted to steal banking info...
Click to expand...
Click to collapse
The real question here is... Would Bill Gates buy a Google Chromecast? :laugh:
frantisek.nesveda said:
Well, would you give me your WiFi password?
I can think of a few things you could do with access to someone's WiFi... Free internet, torrenting on someone else's responsibility, or just messing with someone.
The real question here is... Would Bill Gates buy a Google Chromecast? :laugh:
Click to expand...
Click to collapse
Sure! I could very easily give you my router password and you would still not be able to do anything you mentioned until you figured out a MAC address one of my networked devices actually uses.
And to my other point...Is Free Internet or messing with someone really worth the risk of going to a Federal Pen for hacking?
As for what Bill Gates has I wonder if he is even running Windows 8 cause I don't know anyone who has it that likes it! LOL
Asphyx said:
Sure! I could very easily give you my router password and you would still not be able to do anything you mentioned until you figured out a MAC address one of my networked devices actually uses.
Click to expand...
Click to collapse
Good point.
I guess that if we really wanted, we could play this cat and mouse game for quite some time, but the outcome would be that if you really care about security, you can make your network secure enough. But that would be just spamming the thread.
frantisek.nesveda said:
but the outcome would be that if you really care about security, you can make your network secure enough. But that would be just spamming the thread.
Click to expand...
Click to collapse
Actually I think what I was trying to say is that no matter how much you care and try to be secure...
If they want you they WILL get you and they don't need nor would they do it through your CCast when there are far better tried and true methods to attack a wireless router directly that doesn't require LUCK of a device not connecting or the timing of catching it while it is booting up in order to catch the weakness.
Any security hole that results from the CCast will likely never amount to anything more than the Prankish "Look what dirtyPorn I put on your screen"
If they want dirt they will go to the router which is always up and doesn't require some act of god or electronics to happen.
You secure your router the best you can and if that isn't enough then you need to keep your wireless off until you need it to be TRULY secure....
And even then there is nothing to stop them from tapping into the pole where your Internet connection comes in and getting you that way!
Security is nothing more than an illusion and a deterrent...Truth is your never secure no matter how much you worry which says to me...Worrying is pointless. Unless you have enemies that really want to get you...and if thats the case all the security in the world won't stop them!
Asphyx said:
Actually I think what I was trying to say is that no matter how much you care and try to be secure...
If they want you they WILL get you and they don't need nor would they do it through your CCast when there are far better tried and true methods to attack a wireless router directly that doesn't require LUCK of a device not connecting or the timing of catching it while it is booting up in order to catch the weakness.
Any security hole that results from the CCast will likely never amount to anything more than the Prankish "Look what dirtyPorn I put on your screen"
If they want dirt they will go to the router which is always up and doesn't require some act of god or electronics to happen.
You secure your router the best you can and if that isn't enough then you need to keep your wireless off until you need it to be TRULY secure....
And even then there is nothing to stop them from tapping into the pole where your Internet connection comes in and getting you that way!
Security is nothing more than an illusion and a deterrent...Truth is your never secure no matter how much you worry which says to me...Worrying is pointless. Unless you have enemies that really want to get you...and if thats the case all the security in the world won't stop them!
Click to expand...
Click to collapse
MAC access list = joke, blacklist is also a illusion changing MAC address(spoofing MAC) is extremely easy on any platform.
In case of whitelist Attacker will look into it just a bit for a longer, to know list of allowed devices.
At home you will have to whitelist every new device...
In corporate environment it will take you more time also WPA2-PSK is not suitable for serous corporate use.
About absolute security.
Security is relative term. Its just like healthy life style, it will not make you immune to diseases, it will make you generally healthier, less likely to get ill.
Related
So apparently, I can't bring my laptop everywhere to get my thing done, but I had a thought of referring that to my phone. I find any trusted app/script to get the packets to cap file that would sit down in my sd card for further use. I'm not some evil mastermind that would go stealing anything(don't need anything now dough) This is purely for learning since I'm still learning about IT but trying to get ahead and since android is something that I'm still not sure of how it works.
And my other question: How can I get video calling on skype? I'm assuming it should work with GindgerDX but it doesn't.
Bahurs1 said:
So apparently, I can't bring my laptop everywhere to get my thing done, but I had a thought of referring that to my phone. I find any trusted app/script to get the packets to cap file that would sit down in my sd card for further use. I'm not some evil mastermind that would go stealing anything(don't need anything now dough) This is purely for learning since I'm still learning about IT but trying to get ahead and since android is something that I'm still not sure of how it works.
Click to expand...
Click to collapse
The question is ... why would you want to run a packet capture? The payload data in the packets is encrypted anyway - so there's no real way to (assuming evil intentions) crack down on the convos of other users being in the same WLAN/LAN segment. If you're worried about Man-in-the-middle attacks take my word that it won't work. If you wiretap a Skype<->Skype chat/call via a man-in-the-middle attack the connection would fail as Skype would recognize that the end-to-end encryption is borked.
Anyhow, whatever your idea is ... Google for "Pixie" ... that's a network sniffer for Android, and the only one I happen to know (as real men use tcpdump or Wireshark for network analysis anyway).
Bahurs1 said:
And my other question: How can I get video calling on skype? I'm assuming it should work with GindgerDX but it doesn't.
Click to expand...
Click to collapse
No. Skype Video only works on a selected range of devices (read up on the description in the Market) having a FRONT camera (a camera that's facing you and not a camera that's at the back of your device facing away from you).
Look around on XDA/Google (in other words: SEARCH!) and you will find out that there's a hacked version that has Video enabled for some additional devices, though I don't know if that would support the back camera of the W8/X8.
Yeah I'm kinnda sorry for the dumb question about skype cause I just always forget to look it up when I sit down on the web.
As for the sniffer thing. I dont know who would ever need to investigate packets affcourse I need to get the password. The sicuation is hard to explain, but lets say I need to prove that 14digs of just numbers is a stupid idea for long range wifi access password.
I cant get my laptop there so I need an alternative to get some packets and then easily get the password at home and as I sayed I'm not a genius in IT but I know how to use some of the features that backtrack provides.
I have my Chromecast already set up, and am forging ahead with learning and reading tricks on here, but I was curious about the set up process itself.
Think about it - I have an encrypted WiFi, and there's no open WiFi around me... But somehow when I was setting up the device, the program on my laptop knew the code that the device was broadcasting. The device clearly communicated out to the internet BEFORE I set up my WiFi password in the setup program. I'm wondering what the trickery was that managed that, or am I missing something critical in the process here?
FractalSphere said:
I have my Chromecast already set up, and am forging ahead with learning and reading tricks on here, but I was curious about the set up process itself.
Think about it - I have an encrypted WiFi, and there's no open WiFi around me... But somehow when I was setting up the device, the program on my laptop knew the code that the device was broadcasting. The device clearly communicated out to the internet BEFORE I set up my WiFi password in the setup program. I'm wondering what the trickery was that managed that, or am I missing something critical in the process here?
Click to expand...
Click to collapse
Pretty sure the device uses ad-hoc WiFi and/or Bluetooth to perform the initial sync. There is a thread about how your desktop must have a WiFi card in order to set up the chromecast (but Streaming from Chrome over ethernet works after initial setup).
Louer Adun said:
Pretty sure the device uses ad-hoc WiFi and/or Bluetooth to perform the initial sync. There is a thread about how your desktop must have a WiFi card in order to set up the chromecast (but Streaming from Chrome over ethernet works after initial setup).
Click to expand...
Click to collapse
Didn't think about an ad-hoc solution. And the setup program could be set to look for its broadcasts... Nor did I even consider using anything other than my laptop on WiFi to sit RIGHT IN FRONT OF THE TV and play while setting it up.
That sounds plausible, though it felt like wizardry at the time.
FractalSphere said:
Didn't think about an ad-hoc solution. And the setup program could be set to look for its broadcasts... Nor did I even consider using anything other than my laptop on WiFi to sit RIGHT IN FRONT OF THE TV and play while setting it up.
That sounds plausible, though it felt like wizardry at the time.
Click to expand...
Click to collapse
I thought the same thing at first, but after setting up my second Chromecast using the Android application, you can see it messing with your WiFi/Bluetooth settings in the status bar when initially searching for Chromecast devices.
I was playing with it only for one few hours...
and I am concerned with current level of security of rooted Chromecast.
If you
reboot wireless router(wireless access point)
OR
wireless router is down/malfunction
OR
communication between Chromecast and wireless router is jammed
OR
someone used Aircrack-ng suite to disconnect Chromecast from wireless router
your Chromecast just created open wireless network for configuration purposes...
and Team-Eureka http panel is accessible at most likely default IP address 192.168.255.253,
also provides you with an IP adress via internal dhcp.
look a bit at config:
http://192.168.255.249/?page=status
and than
http://192.168.255.249/?page=settings
be sure that telnet, ssh, adb are running.
Just connect with telnet or SSH, privledged user is root, there is no password
cat /data/wifi/wpa_supplicant.conf
Code:
ctrl_interface=/data/wifi
update_config=1
country=US
network={
ssid="my wifi essid"
scan_ssid=1
psk=my password on a silver plate in WPA PSK HEX(64 characters)
proto=RSN
key_mgmt=WPA-PSK
}
You just owned someone's Chromecast and can abuse his wireless network.
Still got time tinker with Chromecast? Maybe plant some android type of backdoor... NSA style...
How to fix this?
1. be sure that internal web server is not vurnelable.
2. https
3. Http panel accessible only after providing password that is by default for instance sha-1 hash of serial number.
(user may take a picture of his own chromecast and use tool/service to generate hash), it should be changed at first login
4. adb, telnet, ssh disabled by default
5. root password
Basic stuff...
First off, if you are worried about our panels security it is open source, so feel free to audit it for any vulnerabilities.
Also, we are working on a new revision of the panel which not only includes password support, but also the ability to set a SSH password. The reason none is set ATM is because by default the root acc on the chromecast has none, so we have a modified dropbear binary that will allow any password to work.
As for HTTPS over the web panel, that will be available, but it will not be "enforced". (at least that is the current plan). We may add a panel option that enforces https though, for users who are concerned about security on their local wireless network.
Now telnets another story, because its generated with busybox its hard to have a password enforced, but you can just disable it. same goes with ADB.
We know right now our services are not the most locked-down, but trust me most of it has already been fixed on our end and these changes will be out with the next OTA
ddggttff3 said:
First off, if you are worried about our panels security it is open source, so feel free to audit it for any vulnerabilities.
Also, we are working on a new revision of the panel which not only includes password support, but also the ability to set a SSH password. The reason none is set ATM is because by default the root acc on the chromecast has none, so we have a modified dropbear binary that will allow any password to work.
As for HTTPS over the web panel, that will be available, but it will not be "enforced". (at least that is the current plan). We may add a panel option that enforces https though, for users who are concerned about security on their local wireless network.
Now telnets another story, because its generated with busybox its hard to have a password enforced, but you can just disable it. same goes with ADB.
We know right now our services are not the most locked-down, but trust me most of it has already been fixed on our end and these changes will be out with the next OTA
Click to expand...
Click to collapse
Thank you for fast and exhaustive answer.
Any "ETA" of build with features you mentioned ?
Is there any roadmap for Eureka-ROM?
Any chance for something dedicated to LAN streaming?
(Chrome full screen is buggy, Plex is $ app, Fling is written in JAVA and no longer in developement.)
If there will be any beta or rc I am willing to participate.(not so many things to test there)
mathorv said:
Thank you for fast and exhaustive answer.
Any "ETA" of build with features you mentioned ?
Is there any roadmap for Eureka-ROM?
Any chance for something dedicated to LAN streaming?
(Chrome full screen is buggy, Plex is $ app, Fling is written in JAVA and no longer in developement.)
If there will be any beta or rc I am willing to participate.(not so many things to test there)
Click to expand...
Click to collapse
We don't really do ETA's but we try to have updates out right after google OTA's, or when there is a severe bug. As for a roadmap, we currently don't have one public due to it constantly changing.
LAN streaming still works with Fling (as we have fling added back to our roms through our whitelist service), but that is all I know of. If other users want to create apps that can utilize fling, that would be awesome.
And last for testing, currently I have more then enough testers for when beta updates roll out. keep your eyes open in the future as I may do open signups again at a later date.
Well the scenarios you set would apply to non rooted CCasts as well...
If they hacked your wireless with Aircrack to set a disconnect, then you were exposed long before they reconfigured the CCast and they can do a lot more damage with that access without you ever noticing than they could through the CCast.
Your would notice the CCast changing but you wouldn't notice someone hacked your Wireless without looking at the Router Logs or noticing a degraded Network performance.
If these things are a concern for you then I suggest you turn on MAC Filtering on our Router, Set Allows for the CCast and all the devices you own and deny all others.
But the concerns you have exist regardless of a rooted CCast. Leaving a CCast unconnected might expose the CCast to be taken over since it will be an open AP anyone can connect to....And they can Airtcrack you router even with a stock CCast.
But if you see that just look out the window because they would probably have to be sitting on your Porch or parked in your Driveway to do it!
I don't know many Hackers who are THAT Brazen! LOL
Asphyx said:
Well the scenarios you set would apply to non rooted CCasts as well...
If they hacked your wireless with Aircrack to set a disconnect, then you were exposed long before they reconfigured the CCast and they can do a lot more damage with that access without you ever noticing than they could through the CCast.
Your would notice the CCast changing but you wouldn't notice someone hacked your Wireless without looking at the Router Logs or noticing a degraded Network performance.
If these things are a concern for you then I suggest you turn on MAC Filtering on our Router, Set Allows for the CCast and all the devices you own and deny all others.
But the concerns you have exist regardless of a rooted CCast. Leaving a CCast unconnected might expose the CCast to be taken over since it will be an open AP anyone can connect to....And they can Airtcrack you router even with a stock CCast.
But if you see that just look out the window because they would probably have to be sitting on your Porch or parked in your Driveway to do it!
I don't know many Hackers who are THAT Brazen! LOL
Click to expand...
Click to collapse
Reconfiguring stock Chromecast is one thing and that's not so much a problem. Attacker don't get password, just info about name of connected network. In that scenario attacker gets essid and handshakes or reconfigure Chromecast wireless settings(essid/password).
Problem is that with rooted attacker has access to adb/telnet/ssh. In that scenario attacker has easy access to essid/password in plain text and may do this unnoticed.
About ranges:
What if someone lives in center of a city? Skyscrapers area?
About suburban area, I am not convinced that people in US live in houses with brick/concrete block walls, this is not EU.
Have you ever used Aircrack-ng suite and some gnu/linux wireless pentesting distro?
You can attach high gain directional antenna to 2000mW wireless card(Alfa brand for instance) and use software tweaks.
Ranges are much higher than you would anticipate.
About Chromecast setting security - yes it is ridiculous.
It asks if you see XYZ9 on a screen. (always click yes - right?)
It should at least ask for some automatically generated password that is visible on the screen...
So for now we may create additional wireless network/VLAN with max one client and connection restrictions...
mathorv said:
Have you ever used Aircrack-ng suite and some gnu/linux wireless pentesting distro?
You can attach high gain directional antenna to 2000mW wireless card(Alfa brand for instance) and use software tweaks.
Click to expand...
Click to collapse
Yes many times and the loopholes you suggest in your scenario are not limited to the Rooted version at all...
Sure there are extra tools in the rooted version that do not exist in the non-rooted....
But the scenario suggested gives you about 30 seconds to get what you want before the router is back up, CCast re-connects and shuts down your session!
And they still have the problem of how to shut down your router or know when it will happen to start working the hack.
Sure someone could probably get what they want in that timeframe..
But someone that good really is not going to be interested in hacking YOU!
Not Unless your some Cartel leader or Bank Executive.
People who have no business rooting anything if they want security....LOL
Asphyx said:
Yes many times and the loopholes you suggest in your scenario are not limited to the Rooted version at all...
Sure there are extra tools in the rooted version that do not exist in the non-rooted....
But the scenario suggested gives you about 30 seconds to get what you want before the router is back up, CCast re-connects and shuts down your session!
And they still have the problem of how to shut down your router or know when it will happen to start working the hack.
Sure someone could probably get what they want in that timeframe..
But someone that good really is not going to be interested in hacking YOU!
Not Unless your some Cartel leader or Bank Executive.
People who have no business rooting anything if they want security....LOL
Click to expand...
Click to collapse
@but someone that good really is not going to be interested in hacking YOU!
World is full of sick people, besides, over the years it has become easy, primary school kid can do it, every hacking soft has a GUI now
@ features - it would be nice to override wifi from panel - sometimes chromecast indicates connecting status. at the same time is connected to secure wifi and has open configuration wifi.
@ alpha builds, I would be glad to flash anything newer that does not totally brake chromecast and is safer for now
Is web panel risky?
Sorry it's even worse:
1. connect to device if its in open network AP state
2. http://192.168.255.249/?page=debug
3. cat /data/wifi/wpa_supplicant.conf
4. SEND
Gone in less than 30 seconds.
mathorv said:
Sorry it's even worse:
1. connect to device if its in open network AP state
2. http://192.168.255.249/?page=debug
3. cat /data/wifi/wpa_supplicant.conf
4. SEND
Gone in less than 30 seconds.
Click to expand...
Click to collapse
Good thing devices only are in AP mode for setup. Besides, once the new web panel is released, this will be a non issue.
"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.
DJames1 said:
"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.
Click to expand...
Click to collapse
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!
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,
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.
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.
DJames1 said:
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.
Click to expand...
Click to collapse
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.
DJames1 said:
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.
Click to expand...
Click to collapse
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!
Now the guest mode have been enabled and also the screen mirroring on all devices.. They don't work together though. Any solution to this?
What do you mean by they don't work together?
Guest mode was never meant to allow Cast Screen just allow devices who are not on the local WiFi to connect to stream content and play games (aka jump onto the Controller channel).
Since the Guest connection doesn't use WiFi (at least I don't think it does) it would never work for casting a screen.
That's how it work right now, yes you are right. But I whant it to be able to send screen to. I whant to be able to screen cast my whole screen using guest mode.
cowsick said:
That's how it work right now, yes you are right. But I whant it to be able to send screen to. I whant to be able to screen cast my whole screen using guest mode.
Click to expand...
Click to collapse
Without a Wifi sized bandwidth to send the data it would never work.
I'm interested for schools who has a lot of sub nets. And the chromecast will never be on the same broadcast domain as the client. Guest mode will make the cast thing work... But not screen cast
cowsick said:
I'm interested for schools who has a lot of sub nets. And the chromecast will never be on the same broadcast domain as the client. Guest mode will make the cast thing work... But not screen cast
Click to expand...
Click to collapse
Domains don't really matter if it works the way I think it does....
WiFi must be unconnected and only mobile data is used in order for it to work.
And besides it is unlikely the school will allow guest mode to work as someone could hijack a CCast if they wanted.
1. Broadcast domains do matter.
2. WiFi should not be unconnected. This is already tested.
3. I'm responsible for a couple of schools IT department. And a couple of thousands of computer. And yes this is a very big question for us.
cowsick said:
1. Broadcast domains do matter.
2. WiFi should not be unconnected. This is already tested.
3. I'm responsible for a couple of schools IT department. And a couple of thousands of computer. And yes this is a very big question for us.
Click to expand...
Click to collapse
Then you are going to have to rely mDNS throughout all domains to be able to see these devices.
Have you any idea what guest mode on the [email protected] work like? Please check it out and come back later and try to understand my question and need