Alexa and Google Home expose users to vishing and eavesdropping

That seems like a strange workaround. Wouldn't the burden of proof to subpoena to Amazon be the same as a warrant to the user?

Subpoena is the wrong word. Amazon gives up your video willingly to law enforcement without your consent or even knowledge.

They can do this because it hasn’t yet been determined unlawful.

We are in a dire need of cyber ethics framework that enshrines user privacy.

What's the opt-in process like - specifically, what mechanisms are in place to protect those for which English might not be a first language?

It's not, just another channel with its own inherent rate of success, maybe around non-technical users who might mistakenly trust the speaker but not a person on the phone.

Back in 1966, the makers of the Eliza AI chatbot program were shocked to learn people inherently trusted the program and told it things they didn't want other people to hear. So I propose vishing capitalizes on this phenomena.

https://en.wikipedia.org/wiki/ELIZA

A decent chunk of computer security work seems to be around finding these same exploits in new devices, since we haven't convinced ourselves to stop reinventing and selling new connectivity devices :)

i.e. - it's not a new technique, but a new instance of the problem, and that makes it worthwhile (especially for something widely used in private environments) to explore and expose.

It'd be nice if we could reach some kind of device/phone capability plateau and reduce consumption of new equipment. And ideally settle on a small set of software to use on those, which could be hardened and made reliable over time.

Until then, ...

It's not really any different -- changing server behavior after app review is possible for any server-based app. The one thing they exploited that is unique, though, is that when a user talks to a smart device, they generally don't know at any given time if their commands are going to Google/Amazon or are being passed to Google/Amazon and the third-party developer.

As far as many users are concerned, they're talking to Alexa. The third party app is Alexa, too.

And because of the opaque single-dimensional nature of voice interfaces, even a savvy user doesn't know who's really receiving their intent -- there are enough glitches where you think you're sending to the active skill, but you're back in Alexa's lobby again, so the inverse case the researchers are playing with is a good vector.

I think they could solve some of this because Amazon/Google are gatekeepers -- they get user input no matter where it goes -- they could easily automate detecting anomalous user input and flag for review (that would of course miss the first victims, but it's better than nothing).

I think the "Who's listening?" part is a little harder to solve. Maybe by forcing the third party app to always announce itself as itself? But that does add some friction to the "experience" they want to provide...however, a little friction is better if it means protecting your users.

I'll take a stab at it. What's different here is that an audio-only UI makes it particularly hard for the user to know what program they're interacting with.

Visual UIs generally offer a host of cues to indicate what program is running, and take special efforts to make security-sensitive interactions and dialogs hard to fake. Using these techniques in a voice UI is tricky. There's no good way to tell where the last output came from, or where the next input is going. How can a user be certain that a request for privileged information is coming from a trusted source? In this example, Google clearly tried to create a signature sound (the "Bye earcon") that lets the user know when an app has exited, but an app was able to fake it. The attack leverages the user's trust that was built up by Google.

I think this article provides a useful example that highlights the particular difficulties securing a voice UI system from phishing attacks.

I don't know for sure about Google, but with Alexa skills are simply implemented as a web service. There is no way for Amazon to know that you've deployed new code on your web service. There are a lot of limits to what you can change though, the prompts / intents are specified in a manifest you have to upload. But what the device does for an existing intent, and the responses it sends, can be changed without their knowledge.

You could do the same thing with almost any type of app where you run your own web service; it's kind of a black box to the app market's test group...you could change everything but the domain name and security certificate (and most app stores don't pin the cert as they expire and you wouldn't want to recertify at every cert switch).

One thing Amazon or Google could do here for voice apps, though, that Apple and Google (Android) can't for standard phone apps, is audit voice responses for anomalies or user input that matches a suspicous pattern and flag apps that trigger it.

They can do this because every utterance a user sends a voice assistant passes through Amazon or Google systems. If an app has access to user PII, they could add some automation to flag suspicious user responses or anomalous activity that differs from x days previous and pass it up the chain for review.

One thing I do like about Alexa development is that if you, as a developer, are privacy-minded (and don't need nor want user data for anything), you can protect your users by configuring your apps not to collect any of your users' info . As a developer, you don't even get IP addresses as everything goes User > Amazon > Developer > Amazon > User.

You always get session and Amazon-assigned user id, but they're typically pretty anonymous unless the user says "I am Jane Doe" -- which, I guess we should be honest, probably does happen more than it should, and this is what the OP researchers are exploiting.

It probably did prompt the second round review, but someone in head office is going too many reviews could lead to a congress led inquiry, so they stay quiet until a a contractor spills the beans on the nastiness happening behind the scenes.

vishing is defined as using social engineering with the intention to get access to the user's vi session. The article is obviously using the term incorrectly.

This makes no sense. Phishing comes from phreak + fishing, but the "ph" in phreak is already from the word phone (phone + freak) -- so the ph in "phishing" already comes from the word phone! The telephone version of phishing should be... "phishing."

But thanks for the explanation.

They record only after the trigger word. It's the same as Android phones and iPhones that have "OK Google" or "Hey Siri" enabled.

In practice we know that trigger words for all these devices occasionally misfire (There was also an issue with one type of google home device a while ago which was shipped with a faulty physical button that caused it to be turned on at intervals as if the user had pressed the physical button to start speaking).

The more important question is: how do we know whether these devices (or a particular subset of them) record all the time or only after the trigger word?

The device has to record all the time in order to "listen" for the wake word.

It's got a small couple-second buffer (enough to store "Amazon" or "Computer" or "Alexa" or "Echo") where it takes what it hears and compares it with its internal model for a match.

If there's no match, the buffer is overwritten with the next bit of noise. Once the device gets a wake word match, it transmits the statement that follows to home base to transcribe and handle.

You don't need linux support to put a switch on a microphone

The Google Home Mini has a physical hardware mic mute switch. Other Google and Amazon smart devices have similar switches.

Like your phone?

Please forgive (and remedy?) my ignorance, but are you saying all hardware speakers can be used as microphones?

I can't wait for linux mobile! Imagine making calls from a command line: Just type dial voice +1-555-1212 -ntwk verizon -prot cdma2000 -ssh-version 2 -a -l -q -9 -b -k -K 14 -x and away you go!