Validating resources located at non public ip addresses
Imagine a scenario where you’re browsing the web and all of a sudden your Google Home factory resets.
What if your roommate left their web browser open on their laptop and an HTML advertisement sends your Chromecast into reboot loops while you are trying to watch a movie?
He actually created a Po C for the geolocation attack scenario that I described above, but never implemented!
His work, and Brian Kreb's commentary on it are both excellent 👏👏👏.
I notified Google about this vulnerability when I discovered it in March and again in April after receiving no response.
According to Kreb's post, Young reported the bug to Google in May and his ticket was closed with "Status: Won’t Fix (Intended Behavior)." It wasn't until Krebs himself contacted Google that they agreed to patch the vulnerability.
Google Home, Chromecast, Roku, Sonos Wi Fi speakers, and certain smart thermostats could all be interfaced with in some way by an unauthorized remote attacker. I’ve been in contact with the vendors of these products and all of them are working on or have already released security patches (more on that disclosure in this essay).
Those are just the companies whose devices I’ve personally tested in my spare time.Fast forward five years and it seems that Google has integrated that same mysterious API into all of its Google Home products, and as you can imagine, that undocumented API is fairly well documented by amateurs and hobbyists at this point.In fact, earlier this year Rithvik Vibhu published detailed API docs to the public.One of my favorite attack scenarios targeting this API is an abuse of the Wi Fi scanning capability.Attackers could pair this information with publicly accessible wardriving data and get accurate geolocation using only your list of nearby Wi Fi networks.This scenario is an actual exploit (CVE-2018–11315) that I’ve found and used against my Radio Thermostat CT50 “smart” thermostat.