[Q] WiFI Data Leak Fix - Nook Color General

Any ideas how to get the patch for the open WiFi Authentication Token flaw?

I believe this is a server side patch.
edit: or maybe not.

It is server-side. Google has said there will be no need to actually push a fix to the Android devices themselves.

Seriously, who would connect to an open Wifi? It's pretty brain-dead stuff.

Related

ActiveSync via wifi?

Does anyone know how to set this up? I'd like my phone to automatically update when it connects to my home wireless network.
WiFi connection has been removed from the newer versions of ActiveSync, which are required with WM5/6, due to "Security" concerns.
but is there any third solution ?
Hosted Exchange is all I'm aware of.
As in a full business-type solution? Sounds like Microsoft gave us the bird with that decision...
with out exchange is there any possible solution for wifi synch ?
tirosa said:
with out exchange is there any possible solution for wifi synch ?
Click to expand...
Click to collapse
Like he said, Microsoft on the heels of lots of bad P.R. about lapses of built in security with Windows, decided that information synced by WiFi was just asking to be " sniffed " so they just eliminated the possibility.

[Q] VPN options on a D3 with CM9

I'm running Hash's ICS on my D3, and can't seem to do anything with any VPN connections. On MavROM 3.5, I was able to make un-encrypted PPTP connections, because for some reason, MPPE support is missing in the Kernel. I know what an absolute pain in the neck getting a PPTP server up and working on Linux can be, so I can't imagine what a pain getting it running on Android is like.
Has anyone been able to make any kind of VPN connection on their D3 with a CM9 based ROM? I have yet to hit my logs, and start capturing packets, but before I did, I wanted to see if its even possible, since having a locked bootloader makes things a little tougher..
Anyone have anything for this? 3rd party options? This is one area where the iPhone just works, and I have had a hell of a time getting various Android flavors connected to our VPN. Either PPTP or L2TP. It's just not as easy as an iPhone or iPad.
This is certainly been a decision factor for Tablet provisioning for our sales guys. One guy did buy his own Android tablet, and just can't get the VPN working, where all of our iPad's work without modification.
I hear crickets chirping...
I've been searching for months.. I have found no viable fix for VPN on either CM7 or CM9, and from what I've found it's an upstream issue in Android itself. Only solutions I've found connect to other service providers to provide anonymity. i have not tried paid solutions.
Not sure if this is an option, but OpenVPN works flawlessly. Unless you strictly require a PPTP/L2TP solution, try it out. I've got an OpenVPN server running on my router at home so I can connect from my phone at any time and have quasi-LAN access to my home network, comes in really handy. Not to mention it's a billion times more configurable than either of the built-in (and outdated) VPN types.
Android has never been known for its VPN compatibility, surprisingly enough. You'd think it would be a major focal point in terms of customer requirements, but I guess it's sort of slipped through the cracks.
Nevertheless, try searching the Market (or Play, whatever they've called it now) for OpenVPN Installer and OpenVPN Settings, the first app does what you'd think and the second is where you initialize and configure your connections.

Rooted Chromecast with Web Panel = Problems with security

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.

[Q] Can't turn fingerprint scanner back on after using VPN

I was just getting used to the fingerprint scanner after setting up my phone and went to add my VPN connection. It seems there is a bug(feature?) where you can not enable VPN connections while using the fingerprint scanner lock screen. Why it would force you to disable a main selling point of the device to use the VPN connects is beyond me...
Aside from how strange the request was I switched to passcode lockscreen protection and was able to add a VPN connection. However, now I can not seem to turn VPN support OFF or to get the fingerprint scanner back ON. The option is grayed out in my options menu with this message "Turned off by Administrator, encryption policy or credential storage"
Any ideas? As a bonus the VPN connect did not even work! It connects perfectly from my S3, but this S5 seems to hate VPNs?
Can't speak to the built-in vpn settings, but perfectly able to use OpenVPN and fingerprint security without any problems.
SOLVED!
quordandis said:
Can't speak to the built-in vpn settings, but perfectly able to use OpenVPN and fingerprint security without any problems.
Click to expand...
Click to collapse
I was just going to post an update saying I solved it by switching to OpenVPN. Updated my pfSense router, setup the server and exported the client file to my OpenVPN app.... Worked!
However, I still was not able to set the fingerprint lock screen back. It turns out you must delete ALL your VPN profiles(the one I had that didn't work) in the settings menu for the option to become available again. Moral is avoid the built in VPN support like the plague if you can and use OpenVPN,
But that would be true anyway OpenVPN is arguably one of the more secure VPN protocols....IPSEC is probably another good one, but with such....umm....not great implementation of it in android OS, always happier to use another very safe and secure alternative....
Fingerprint and VPN on S5
The answer to the original post is that Android requires a higher level of security to store secure access gateways like VPN's that could grant access to entire business data systems. Samsung rates its finger print sensor as medium. Perhaps medium might even be a step too high especially after it was fooled soon after launch with lifted fingerprints on tape and rubber blocks. Its akin to the facial recognition security option of earlier Android models that was bypassed using printed photos held up in front of the phone.
If you want a VPN in your S5, then you will have to forget fingerprint security and go for the higher level pin or password.
If you have made this mistake and ended up in this forum because your fingerprint option is now disabled, then you will have to delete all of the manual VPN's that you have entered. You then need to reboot your phone and re-check that all VPN are now missing because if you have an updated security profile, it may make the VPN profiles hidden and you will only see them on reboot.
Once the VPN profiles are all fully deleted the fingerprint option will return as a medium security.
I agree with earlier suggestions that if you want the fingerprint to work along with having VPN access, then the best option is to setup an OpenVPN connection. It works fine.
Help!
mikecbig said:
The answer to the original post is that Android requires a higher level of security to store secure access gateways like VPN's that could grant access to entire business data systems. Samsung rates its finger print sensor as medium. Perhaps medium might even be a step too high especially after it was fooled soon after launch with lifted fingerprints on tape and rubber blocks. Its akin to the facial recognition security option of earlier Android models that was bypassed using printed photos held up in front of the phone.
If you want a VPN in your S5, then you will have to forget fingerprint security and go for the higher level pin or password.
If you have made this mistake and ended up in this forum because your fingerprint option is now disabled, then you will have to delete all of the manual VPN's that you have entered. You then need to reboot your phone and re-check that all VPN are now missing because if you have an updated security profile, it may make the VPN profiles hidden and you will only see them on reboot.
Once the VPN profiles are all fully deleted the fingerprint option will return as a medium security.
I agree with earlier suggestions that if you want the fingerprint to work along with having VPN access, then the best option is to setup an OpenVPN connection. It works fine.
Click to expand...
Click to collapse
I found this post after I installed FoxFi on my Galaxy S5. I've heard that FoxFi creates a VPN, so I thought this fix might work for me. I uninstalled FoxFi and removed FoxFi's admin access then tried a reboot but I'm still not able to use the fingerprint. Do I need to do a hard reboot? Any thoughts?
Samsung S5 solutions
I'd just like to chime in and thanks to those who suggested the change to OpenVPN. This worked:
1) Deleted current VPN
2) Change screen lock to fingerprint (or whatever you like, I suppose)
3) I changed from PPTP to OpenVPN (I use StrongVPN), downloaded their client app for Android
4) Using their client app, I can now login to VPN using OpenVPN
5) lock screen still functions as normal.
What a pain. So lucky I enabled the Samsung remote before this happened as I got a bug where the phone crashed at the PIN entry screen and I was unable to unlock the phone with the PIN. So, S5 users, do enable "Remote Control" in your settings so you can unlock your phone via internet.
Ken
security certificate
diggory's wardrobe said:
I found this post after I installed FoxFi on my Galaxy S5. I've heard that FoxFi creates a VPN, so I thought this fix might work for me. I uninstalled FoxFi and removed FoxFi's admin access then tried a reboot but I'm still not able to use the fingerprint. Do I need to do a hard reboot? Any thoughts?
Click to expand...
Click to collapse
If you delete/remove the security credentials it will work again. It took me a while just trying everything to get it to work again but this fixed it. You just have to do that after using VPN.
Is there any other way to enable the finger print unlock option?
I use StrongVPN too... and I am in China right now. OpenVPN doesn't work well here somehow (confirmed by StrongVPN support staff), and it would disconnect or get no internet access randomly. I was forced to use PPTP for a more stable connection. I have set up a VPN router using the main account (PPTP now, but I am able to change it to openVPN if I want...but then it won't be stable), and I have an addon account (extra $2 per month) and it can only be PPTP (I won't be able to change it to anything else). Right now I have the addon PPTP account set up on my S5.
Basically I can only use PPTP right now. Is there any other way to enable the finger print on screen lock?
Is it a bug or done on purpose by the manufacturer? Will it be fixed in the near future?
similar problem
Hi. I just bought my S5 around new years, after having iPhone for a long time, so im quite new at android devices. My problem is i've done something so that i cannot activate any kind of security except for a password. All others is greyed out
Do you know how i can make my security options work again? I dont know what i've done, and i would be sad if i had to reset my whole phone just for that...
PhilBxda said:
I was just getting used to the fingerprint scanner after setting up my phone and went to add my VPN connection. It seems there is a bug(feature?) where you can not enable VPN connections while using the fingerprint scanner lock screen. Why it would force you to disable a main selling point of the device to use the VPN connects is beyond me...
Aside from how strange the request was I switched to passcode lockscreen protection and was able to add a VPN connection. However, now I can not seem to turn VPN support OFF or to get the fingerprint scanner back ON. The option is grayed out in my options menu with this message "Turned off by Administrator, encryption policy or credential storage"
Any ideas? As a bonus the VPN connect did not even work! It connects perfectly from my S3, but this S5 seems to hate VPNs?
Click to expand...
Click to collapse
I have the same issue here, I was able to connect once to the VPN... Let us if you find a solution
Brocheuse said:
I have the same issue here, I was able to connect once to the VPN... Let us if you find a solution
Click to expand...
Click to collapse
Hi guys,
Let's put this into context for a minute. Android is assuming that if you're using the built-in VPN functionality of the phone, then it's for corporate use/access. As such, the security on the phone needs to be at a maximum in order to avoid a potential security vulnerability if you lose your phone. If you lose your phone, or if it gets stolen, a malicious user may intentionally access your corporate network via the VPN connection and this can result in some serious issues. Therefore, if you're going to use the BUILT-IN VPN, the the phone requires you to change the lock method to one that is considerably more secure than the fingerprint scanner, which has very easy and known work-arounds and much easier to hack than a PIN or password.
If you delete your VPN account from the system settings, then you will be able to re-enable the fingerprint security on your lock screen. Pretty simple.
If you REALLY want to use the fingerprint scanner along with a VPN connection, you can see if the VPN you want to use supports OpenVPN, as that protocol is not supported by the OS natively, and therefore, there are no security restrictions on the phone to use the app. Alternatively, you can try to find a VPN Client app that doesn't rely on the phone's built-in VPN functionality.
Hope that makes sense....
quordandis said:
Hi guys,
Let's put this into context for a minute. Android is assuming that if you're using the built-in VPN functionality of the phone, then it's for corporate use/access. As such, the security on the phone needs to be at a maximum in order to avoid a potential security vulnerability if you lose your phone. If you lose your phone, or if it gets stolen, a malicious user may intentionally access your corporate network via the VPN connection and this can result in some serious issues. Therefore, if you're going to use the BUILT-IN VPN, the the phone requires you to change the lock method to one that is considerably more secure than the fingerprint scanner, which has very easy and known work-arounds and much easier to hack than a PIN or password.
If you delete your VPN account from the system settings, then you will be able to re-enable the fingerprint security on your lock screen. Pretty simple.
If you REALLY want to use the fingerprint scanner along with a VPN connection, you can see if the VPN you want to use supports OpenVPN, as that protocol is not supported by the OS natively, and therefore, there are no security restrictions on the phone to use the app. Alternatively, you can try to find a VPN Client app that doesn't rely on the phone's built-in VPN functionality.
Hope that makes sense....
Click to expand...
Click to collapse
Thanks for your explanation and yes it make sense, I have a question, I hope you'll know how to fix it: I installed the VPN on my Samsung s5 tablet and it works fine no issues, did the same thing on my cell phone (s5 also) somehow the cell will work only once, if I delete the VPN and restart over same thing works only once... any ideas?
Brocheuse said:
Thanks for your explanation and yes it make sense, I have a question, I hope you'll know how to fix it: I installed the VPN on my Samsung s5 tablet and it works fine no issues, did the same thing on my cell phone (s5 also) somehow the cell will work only once, if I delete the VPN and restart over same thing works only once... any ideas?
Click to expand...
Click to collapse
That is strange and I'm not sure. What kind of VPN did you set up? OpenVPN? L2TP/IPSEC? PPTP? I would contact the VPN provider and see if they can help you troubleshoot. Sorry, wish I was of greater help....
I have the same problem, I installed the openVPN connect app which forced me to switch to password on the lock screen. I then uninstalled the app but that still did not restore the fingerprint option. I checked the built-in VPN and there are none. I can't figure out how to restore the fingerprint option. I hope someone can please help me!

Wired warns of Chromecast takeover vulnerability

"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!

Categories

Resources