Google in the coming weeks is expected to fix a location privacy leak in two of its most popular consumer products. New research shows that Web sites can run a simple script in the background that collects precise location data on people who have a Google Home or Chromecast device installed anywhere on their local network.
Craig Young, a researcher with security firm Tripwire, said he discovered an authentication weakness that leaks incredibly accurate location information about users of both the smart speaker and home assistant Google Home, and Chromecast, a small electronic device that makes it simple to stream TV shows, movies and games to a digital television or monitor.
Young said the attack works by asking the Google device for a list of nearby wireless networks and then sending that list to Google’s geolocation lookup services.
“An attacker can be completely remote as long as they can get the victim to open a link while connected to the same Wi-Fi or wired network as a Google Chromecast or Home device,” Young told KrebsOnSecurity. “The only real limitation is that the link needs to remain open for about a minute before the attacker has a location. The attack content could be contained within malicious advertisements or even a tweet.”
It is common for Web sites to keep a record of the numeric Internet Protocol (IP) address of all visitors, and those addresses can be used in combination with online geolocation tools to glean information about each visitor’s hometown or region. But this type of location information is often quite imprecise. In many cases, IP geolocation offers only a general idea of where the IP address may be based geographically.
This is typically not the case with Google’s geolocation data, which includes comprehensive maps of wireless network names around the world, linking each individual Wi-Fi network to a corresponding physical location. Armed with this data, Google can very often determine a user’s location to within a few feet (particularly in densely populated areas), by triangulating the user between several nearby mapped Wi-Fi access points. [Side note: Anyone who’d like to see this in action need only to turn off location data and remove the SIM card from a smart phone and see how well navigation apps like Google’s Waze can still figure out where you are].
“The difference between this and a basic IP geolocation is the level of precision,” Young said. “For example, if I geolocate my IP address right now, I get a location that is roughly 2 miles from my current location at work. For my home Internet connection, the IP geolocation is only accurate to about 3 miles. With my attack demo however, I’ve been consistently getting locations within about 10 meters of the device.”
Young said a demo he created (a video of which is below) is accurate enough that he can tell roughly how far apart his device in the kitchen is from another device in the basement.
“I’ve only tested this in three environments so far, but in each case the location corresponds to the right street address,” Young said. “The Wi-Fi based geolocation works by triangulating a position based on signal strengths to Wi-Fi access points with known locations based on reporting from people’s phones.”
Beyond leaking a Chromecast or Google Home user’s precise geographic location, this bug could help scammers make phishing and extortion attacks appear more realistic. Common scams like fake FBI or IRS warnings or threats to release compromising photos or expose some secret to friends and family could abuse Google’s location data to lend credibility to the fake warnings, Young notes.
“The implications of this are quite broad including the possibility for more effective blackmail or extortion campaigns,” he said. “Threats to release compromising photos or expose some secret to friends and family could use this to lend credibility to the warnings and increase their odds of success.”
When Young first reached out to Google in May about his findings, the company replied by closing his bug report with a “Status: Won’t Fix (Intended Behavior)” message. But after being contacted by KrebsOnSecurity, Google changed its tune, saying it planned to ship an update to address the privacy leak in both devices. Currently, that update is slated to be released in mid-July 2018.
According to Tripwire, the location data leak stems from poor authentication by Google Home and Chromecast devices, which rarely require authentication for connections received on a local network.
“We must assume that any data accessible on the local network without credentials is also accessible to hostile adversaries,” Young wrote in a blog post about his findings. “This means that all requests must be authenticated and all unauthenticated responses should be as generic as possible. Until we reach that point, consumers should separate their devices as best as is possible and be mindful of what web sites or apps are loaded while on the same network as their connected gadgets.”
Earlier this year, KrebsOnSecurity posted some basic rules for securing your various “Internet of Things” (IoT) devices. That primer lacked one piece of advice that is a bit more technical but which can help mitigate security or privacy issues that come with using IoT systems: Creating your own “Intranet of Things,” by segregating IoT devices from the rest of your local network so that they reside on a completely different network from the devices you use to browse the Internet and store files.
“A much easier solution is to add another router on the network specifically for connected devices,” Young wrote. “By connecting the WAN port of the new router to an open LAN port on the existing router, attacker code running on the main network will not have a path to abuse those connected devices. Although this does not by default prevent attacks from the IoT devices to the main network, it is likely that most naïve attacks would fail to even recognize that there is another network to attack.”
For more on setting up a multi-router solution to mitigating threats from IoT devices, check out this in-depth post on the subject from security researcher and blogger Steve Gibson.
Update, June 19, 6:24 p.m. ET: The authentication problems that Tripwire found are hardly unique to Google’s products, according to extensive research released today by artist and programmer Brannon Dorsey. Check out Wired.com‘s story on Dorsey’s research here.
Facebook and Google are “Skynet”
No surprise to me. Any device or service offered by Google, YouTube, Facebook, Twitter is always a privacy suspect. It is what they do.
^Amazon
You could use a Guest Wifi network for IoT devices instead of 2 routers. Better still is to prevent guest devices from being able to see each other. Not sure which, if any, routers offer that as a feature. Netgear used to offer it. Found this,
https://www.routersecurity.org/vlan.php
about a router that definitely can keep devices on the LAN from seeing each other
Netgear still utilizes guest networks on their latest routers, but I’m just so tired of their ‘Netgear Genie’ GUI for router configuration, but I guess it fits the needs I require for my small home network.
Mis-understanding. I was referring to isolating guest users from each other. I found this discussion about how Netgear changed their software in this regard:
“One complaint we’ll make about the guest network feature on the Nighthawk X6 that we also made about the original Nighthawk is that the guest network option for network isolation and local network access is the same toggle labeled “allow guests to see each other and access the local network.” Yet in older Netgear routers we’ve owned/tested the option was split into “allow guests to access my local network” and “enable wireless isolation.” There are numerous, and perfectly valid, reasons for wanting to enable one and not the other (e.g. your kids want to play network games with their friends on the guest network so network isolation must be disabled, but you don’t want them to access to your LAN) and there’s no good reason why the settings aren’t more granular on such a high-end router.”
https://www.howtogeek.com/211927/htg-reviews-the-netgear-nighthawk-x6-a-beefy-tri-band-router-for-a-busy-modern-home/
The chromecast was designed to work primarily from the same network as the “controlling” device.
It does have a guest mode for mobile devices not on the network where you use a direct wifi connection to control it, but not direct stream, and the mobile device has to have it’s own internet connection.
Chromecast does not work with wifi port isolation or between a wifi guest segment and the main segment.
The options for using a chromecast on an isolated IoT segment are extremely limited.
The article made me think that the same could be done using a mobile device, or computer to obtain the wifi SSID list. The chomecast/home device having easy access to the nearby wifi is only part of the problem. The databases of locations to wifi SSIDs is big part of the problem.
Good points. But, why do you assume Chromecast has to be on the main network segment? The Chromecast and any other device needing to talk to it, could be on their own, hopefully isolated, SSID. No? Some Asus routers can create 8 SSIDs, 4 regular and 4 guest.
That is correct. The Chromecast must have internet access and must be on the same network as (and visible to) the controlling device. That doesn’t mean that the Chromecast has to be on the same network as the rest of the household. As long as you connect your device (phone, tablet, etc) to the same network as the Chromecast it should work.
That Gibson thing is such a convoluted solution, it’s crazy.
What we _REALLY_ need is for major SOHO/consumer router manufacturers like Cisco, Asus, Netgear, etc, to assign IoT devices to untrusted VLANs.
Untrusted VLANs should have full internet access but no access to trusted VLANs. And trusted VLANs should have access to everything, including devices on the untrusted VLAN. This is essentially what I have setup in my home with PFsense.
They need to make this configuration easy to do, too, using something like nmap to discover devices on the network, figure out what they are, and then automatically assign them to the right VLAN. If they can’t discover a device, it should go on the untrusted VLAN by default.
IMO, this would be a killer app for a SOHO router. I would immediately buy them for all my relatives.
+1. Perfect! This is the best solution.
That wouldn’t have stopped this attack though since it was browser -> device.
The device would have been on a separate VLAN, meaning it wouldn’t be in the same address block. While packets to the chromecast’s address would be routed, the malware would need to somehow know where it’s located. That is possible via some sort of multicast maybe, but unlikely to see that in the wild as it’s not a common target.
For everyone praising this comment please read: Security through obscurity is not security!
The malware could just scan all of RFC1918 address space and it would not take much time. Nothing related to multicast… Shoving your IoT device into another subnet is not security!
The real solution is multilayer – You could use something like a honeypot address (dummy host) that when scanned, trigger some blocking action. You could use a firewall to rate limit requests and block requests to specific hosts. You could use an IDS to detect scanning traffic.
In this case it feels like application-level and OS-level firewalls are the best option. If I’m a typical home user, Javascript running on anything but maybe netflix.com and google.com should be allowed to access other local networks. Browser vendors need to implement some better tools for having more granular control over this type of behavior.
It’s all very clever to parrot the security through obscurity bit, and of course that is technically true. But lets put it this way.
WordPress is a very attractive target, as it comprises a sizable portion of the internet. I admin two wordpress sites. One, an enthusiast site, has its admin directory in the /front/wp-admin rather than /wp-admin. The other, a corporate site, doesn’t. The corp site is attacked several hundred times more often.
Same deal with a bunch of servers I run, where I move SSH from port 22 to 17022. Attacks drop by orders of magnitude.
These things are the very definition of security through obscurity, and of course a determined attacker spear-fishing would immediately switch to the right directory or port. But that doesn’t make it worthless. All the worms and poorly designed automated attacks fail. I’m not a low-hanging fruit.
All that said, I agree that a packet inspecting network IDS combined with host-based IDS on servers is a much better solution, but that’s a ton of overhead for consumer hardware. My VLAN solution could actually be done with reasonable effort.
Of course security by obscurity doesn’t work. That’s why Russian tanks are painted day-glo orange.
Factory painted tanks are not orange. Russia never had orange tanks. The only ones that are orange are for parades, decommissioned units.
Some day someone will invent a sarcasm tag for the internet. That person will become a billionaire overnight.
Security through obscurity doesn’t work that’s why you’re using your real name “RealityCheck” to post on random internet forums right?
You seem to have forgotten to leave your home address, phone number and email address.
thanks
I’ve attempted to implement IoT networks a number of times for Chromecast and Google Home by using mdns repeaters between networks to allow devices to use them and have had nothing but crappy results. IOT devices drop out and go unresponsive without warning or reproducible symptoms.
It’s just not possible to use these Chromecast based devices as intended from a separate network for casual users like wives and kids.
Many home wireless routers will grant an IP address using DHCP, and then drop it if they haven’t had a communication from that IP address in a certain amount of time. A lot of times, you can fix that by having the IoT device ping somebody on a cron so the router remembers it as still being attached.
I can’t get my Google Chrome cast to work in my home
The grandt brother working
would adding _nomap to your SSID take care of this?
Adding _nomap would fix it if and only if no other wifi networks can be detected from your location, if you were out in a rural environment.
OK, while I understand the “severity” of the supposed issue, I would like to know how likely the researcher thinks it is that a website or malicious ad is going to be able to guess the IP address of a Chromecast or Google Home device on the network in order to direct the requests to it. It seems highly unlikely that this is ever going to be something that would ever be seen outside of lab conditions.
I do not know how likely it is that advertisers or scammers will do this, only that they can.
Chrome and Firefox reveal the client LAN IP as part of WebRTC. From there it is easy to try all 254 addresses that would be in that /24 and this is where IoT devices will probably be.
There are also some ways of determining this in safari and or/edge
Continuing that comment…
On safari, ie, and edge, there are other techniques that will reveal active networks.
Beyond that, it is trivial to get a strong educated guess that Google devices are on a particular IP.
Multicast packets my man… Multicast.
No need to know Chromecast IP. That is how the system works, it is a promiscuous little thing, and like to communicate with anybody on the network.
QUESTION:
If I connect my Chromecast to Wired Ethernet using the optional adapter… is it smart enough not to map out SSIDs using the builtin Wifi? I don’t know if Wifi turns off when connected to Wired Ethernet.
What about Google’s mesh wifi product…
A bug? right. No such thing as this being a bug. Google and many others are obsessed with knowing where you are at all times. I refrain from allowing too many IoT devices into my home.
This is absolutely a bug. Google wants to know your location and everything else about you, but they don’t want to give that information away to third-parties. They want them to pay for it, to target ads.
As someone who has multiple segregated WLAN networks, let me explain the s— show that is trying to isolate IOT/consumer type devices on different wifi network segments. It’s literally a nightmare when you attempt to use these devices on one WLAN from a different WLAN or LAN. You can thank the manufacturers for this as they don’t provide detailed documentation for what protocols/ports are required for communication. I’ve spent many hours packet sniffing in tandem with features like IP Helper to cram broadcast domain only packets into different broadcast domains to get things working. They can’t be bothered to create documentation because it’s far simpler to say “All devices must be on the same network segment”.
It’s not just a “Google” thing. Name a product, that accesses the internet, that does not want your information. Come on now, and don’t just blame Google or Facebook or maps applications. It’s a built in tracking mechanism. The phone call software, the ringer software, all depend on location data to send the call to the correct tower so that you receive the phone call, same with texts and map directions. And you didn’t know this? It’s not a feature, it’s a function. My only question is why is it added to so many devices?? Or why was security ignored? After all, in the 90’s we had wireless heart monitors,
Can’t you just adjust your wireless network SSID so that your Google and other IoF Kit uses has an SSID that ending in “_nomap”
Probably for Craig Young. Would it be possible for some one to use this “bug” / IP information to target a house that has its front door locks, home lights and security cameras tied to their IoT? If so, this becomes more than just an inconvenience of unwanted eMails and ads.
From my understanding of Brannon’s article (https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325) Only if the IoT device has an unauthenticated or default authenticated http API, which honestly might not be as unlikely as it sounds if you buy cheap ones online somewhere (pure speculation on my part based on a couple of cheap IP cameras I’ve played with).
And if the malicious javascript makes quick enough requests, you could theoretically execute a dictionary attack against the devices on a home network since people aren’t exactly known for secure passwords — especially if they think they’re safe in their home LAN.
I think the fix may have been released 2018-06-27 00:00:00 UTC. My chromecast device is not performing it’s primary function, It is not visible to all but the Google Home app. Oops.