Malicious Use of the HTML5 Vibrate API(shkspr.mobi)
shkspr.mobi
Malicious Use of the HTML5 Vibrate API
http://shkspr.mobi/blog/2014/01/malicious-use-of-the-html5-vibrate-api/
22 comments
(OP here)
It's certainly not "crucial" - but it's a lot easier to trick someone by exploiting their brain's heuristics.
Phone vibrating means alert. I think that could be enough to trick people into overlooking elements like the title bar being visible, etc.
For example, I've noticed that some dodgy web adverts play the default Windows Error.wav when displaying a fake "Your codecs need updating" error dialogue. Not crucial, but adds credence.
I agree that the browser hacking is unlikely and probably shouldn't be mentioned.
It's certainly not "crucial" - but it's a lot easier to trick someone by exploiting their brain's heuristics.
Phone vibrating means alert. I think that could be enough to trick people into overlooking elements like the title bar being visible, etc.
For example, I've noticed that some dodgy web adverts play the default Windows Error.wav when displaying a fake "Your codecs need updating" error dialogue. Not crucial, but adds credence.
I agree that the browser hacking is unlikely and probably shouldn't be mentioned.
> I agree that the browser hacking is unlikely and probably shouldn't be mentioned.
It's not that it's unlikely, it's just irrelevant. "We might accidentally introduce a security flaw" could be used as an argument against building absolutely anything.
It's not that it's unlikely, it's just irrelevant. "We might accidentally introduce a security flaw" could be used as an argument against building absolutely anything.
It doesn't even have to be a website. Phone scammers have been doing stuff like this for ages with pretty low tech. A general rule of dealing with spam like this is "if the source is unknown and it's from a pretty woman or an investment firm, it's a scam". My phone's black list is quite long.
Of course, HTML-based ones can reach a larger number of users with little investment, so it's reasonable to expect this will occur more frequently in the future.
Of course, HTML-based ones can reach a larger number of users with little investment, so it's reasonable to expect this will occur more frequently in the future.
How do you know if the woman on the other end is pretty? :)
There's a great app for Android (in Sweden, I suppose there are similar apps for other countries) that searches digital phone registries on an incoming call and after about a second displays whatever data it has found on the incoming call screen (such as Telemarketing Company, Salesperson, etc) It also uses some form of rating system so if enough users have flagged a number, it will warn me about it. This has saved me countless of calls.
There's a great app for Android (in Sweden, I suppose there are similar apps for other countries) that searches digital phone registries on an incoming call and after about a second displays whatever data it has found on the incoming call screen (such as Telemarketing Company, Salesperson, etc) It also uses some form of rating system so if enough users have flagged a number, it will warn me about it. This has saved me countless of calls.
Which app, if you don't mind me asking?
It's called "Vem ringde" ("Who called" in swedish). I believe the iOS does not grant enough permissions during an incoming call so when using the app on an iPhone one can only do the lookup after the call has finished (answered or missed) which explains the name (past tense). This is of course inferior to the Android functionality, but this might have changed since last time I checked.
iOS version: https://itunes.apple.com/us/app/cia/id580455042?mt=8
Thanks cangelis! It's not really clear (or I'm a lousy reader) wether it displays the information while the call is incoming or only when you've picked up (or missed) the call. If it's the former, I'm glad to hear that it's possible for iOS too!
Are any of those examples really only convincing if they can vibrate the phone? Surely a scam that just involved that fake call screen while playing a fake ringtone would be more or less just as effective? I can't imagine it's a lot of people who wouldn't be fooled because they think "oh, it's fake, it's not vibrating" who would suddenly be fooled by this.
I think the vibrate would catch people who aren't really looking at their phone and the x% of people who don't know how to really use their phone.
I think the percentage of people browsing the Web while not looking at their phone is pretty low. I'm also not sure how the vibration would convince people who don't know how to use their phone. I would suspect this group would require less effort to manipulate.
not many people click legitimate ads. but a low enough percentage do, to make marginal gains in their effectiveness highly sought after
I suspect malware works the same. It costs little to deploy, so even if 1 in 10,000 people are fooled, it can be lucrative.
I suspect malware works the same. It costs little to deploy, so even if 1 in 10,000 people are fooled, it can be lucrative.
My point was that I don't think the vibration would make much of a difference. But you're right that a small gain in the effectiveness could be worthwhile.
How many people only have their phones on vibrate and are used to feeling a phone call come in versus hearing/seeing it? Many professional workers would have their phones set up this way. A sudden absence of vibration would just feel weird.
I'm surprised to learn that a web site doesn't need to ask for your permission to access the Vibrate API. I think there must be a warning screen with the list of permissions the web site wants, like the ones we're getting when installing apps from app stores but with a twist so you can disable individual permissions for a web site.
In Firefox right-click a page -> Page Info -> Permissions.
Some APIs are allowed by default and some aren't. For the discussion about Vibration, see: https://wiki.mozilla.org/WebAPI/Security/Vibration
Some APIs are allowed by default and some aren't. For the discussion about Vibration, see: https://wiki.mozilla.org/WebAPI/Security/Vibration
You can't do this on a phone however as far as I know. The vibrate API is build for mobile devices.
Firefox OS phones already have support for this and yes, the phone vibrates without asking permissions.
Personally I don't see this as a big problem at all.
Personally I don't see this as a big problem at all.
I was replying to the question about getting a list of permissions a page uses/wants.
Neither Vibrate nor WebAudio require permissions from the webpage. Like basic JavaScript they always run. They're not security/privacy risks per se, just something that, like so many other things, could be used to support a phishing attack.
Neither Vibrate nor WebAudio require permissions from the webpage. Like basic JavaScript they always run. They're not security/privacy risks per se, just something that, like so many other things, could be used to support a phishing attack.
I don't understand this statement. A phone is a mobile device.
And, on mobile Firefox, there's no way to see the permissions of a page. Certainly no that I can see of FF for Android.
Firefox for Android developer here, you can long-tap on the location bar while on the page and select 'Edit Site Settings'. Is that what you're looking for?
That is only used if the API requires user confirmation. So things like geolocation, camera, and microphone access will be shown. Adding the feature from desktop should be a bug already. If not then we should file one.
Just says "There are no settings to clear."
So no way to disable vibrate or autoplaying audio.
I can't wait to see this being exploited by advertisements.
I'm already seeing this really bad trend of ads redirecting to the app store which makes the page that did it completely unreadable (going back to safari shows an empty page) and now there's the prospect of the phone vibrating to the blinking of the various ads wanting my attention?
If this goes on like this, I'll really need an adblocker on my phone.
I'm already seeing this really bad trend of ads redirecting to the app store which makes the page that did it completely unreadable (going back to safari shows an empty page) and now there's the prospect of the phone vibrating to the blinking of the various ads wanting my attention?
If this goes on like this, I'll really need an adblocker on my phone.
Firefox on Android has plugin support, and Adblock Plus is one of those supported. I'd definitely recommend it, makes mobile browsing suck so much less.
Windows Phone, once again safe from the dangers of the Internet standards and features!
Hahah. I just tested this on my Windows Phone, Nokia 925, and yeah, not only does it not vibrate, but it doesn't play the audio.
The audio was a surprise, since it runs my HTML5 radio software just fine. I'm guessing the demo used OGG or some other audio format not supported by mobile IE.
The audio was a surprise, since it runs my HTML5 radio software just fine. I'm guessing the demo used OGG or some other audio format not supported by mobile IE.
As a side note to web developers dealing with audio: MP3 is really the "plays everywhere" audio format for HTML5 audio.
Firefox was the last holdout, and they capitulated last year [1]; FF for XP and up and FF for Mac now support MP3. There are very few practical reasons not to use MP3.
[1]: http://stackoverflow.com/questions/4923136/why-doesnt-firefo...
Firefox was the last holdout, and they capitulated last year [1]; FF for XP and up and FF for Mac now support MP3. There are very few practical reasons not to use MP3.
[1]: http://stackoverflow.com/questions/4923136/why-doesnt-firefo...
You'll block out some Linux users who don't want to violate patents, though. And as the other branch of this discussion painfully illustrates, Windows Mobile.
Yeah, it is not possible to please every person.
MP3 has native HTML5 audio support on web browsers (Chrome, FF, IE, Safari) for Windows XP and up, modern Macs, and any modern Droid, iOS, or Windows Phone sold in the last 5 years.
It makes MP3 the broadest supported format out there.
MP3 has native HTML5 audio support on web browsers (Chrome, FF, IE, Safari) for Windows XP and up, modern Macs, and any modern Droid, iOS, or Windows Phone sold in the last 5 years.
It makes MP3 the broadest supported format out there.
Good one! :-)
It's clear that this could easily become the new "YOU HAVE ONE NEW MESSAGE" popup alert that fools, I suppose, many naive users. Not entirely sure what we can do about this except properly educating people or hoping that people will be savvy enough.
this is already very possible if you create a phone app - its even more dangerous perhaps due to the lack of expectation of spam or traps from an app (although this is a perception which is changing I'm sure), but its already there as a risk.
> It is not impossible to conceive of malicious code being able to exploit an unpatched browser flaw and overdrive the motor to destruction.
Are there not restrictions at the OS or hardware level to prevent this?
Are there not restrictions at the OS or hardware level to prevent this?
In the Dark Ages phone I saw, the processor got to turn on a transistor that passed current to the vibrator. Normal operation was either off or full on; there wasn't a way to write a bit greater than 1 to the port pin that controlled the vibrator.
(I designed and implemented the vibration API in Firefox.)
FWIW I liked this article. But one thing to note is that -- at least in Firefox/Firefox OS -- a page/app can only vibrate the phone if it's "visible". In the browser, a page is visible if it's in the topmost tab, if the browser app is the currently-focused app, and if the screen is not locked/off.
At least, that's how it's supposed to work. :)
FWIW I liked this article. But one thing to note is that -- at least in Firefox/Firefox OS -- a page/app can only vibrate the phone if it's "visible". In the browser, a page is visible if it's in the topmost tab, if the browser app is the currently-focused app, and if the screen is not locked/off.
At least, that's how it's supposed to work. :)
When he says it would be possible to completely imitate a real call using web rtc and vibrate, what I hear is that this API combined with webRTC could replace phone calls.
Sure you could install a skype ap, but this opens the way to companies running a private, webapp based voip system. In much the same way as they might use Jabber now. All we need now is a decent opensource desktop voip ap to pair it with.
Sure you could install a skype ap, but this opens the way to companies running a private, webapp based voip system. In much the same way as they might use Jabber now. All we need now is a decent opensource desktop voip ap to pair it with.
Since HTML pages cannot open up by themselves, and user can navigate away, the risk is lower compared to a native app which can do far more damage. Never the less, permission mechanism should have been enabled.
What about ads? The ones that now e.g. pretend to be Skype pop-ups.
HTML Popups have always been a problem and with re targeting the Ads are a menace. And some clever spoofing is definitely possible. A proper ad/popup blocker for native browsers would help.
I sometimes wonder why AdBlock doesn't silently simulate click on all ads in the background. This way you not only protect users from ad bloat, you also make an incentive for people to stop doing website ads.
It ALWAYS needs to be an "Ask First" approach in the browser. I'm starting to have flashbacks of the days when people had music players that autoplay on websites, and how I hated that.
This gets obnoxious very quickly. Current Firefox excludes Flash from click-to-play because user were outraged against it. And note that Flash can do all of these things.
Compared to having your phone vibrate ad nauseum for no determinable reason whatsoever?
Look at this way: pages using Vibrate won't necessarily obnoxiously vibrate for no determinable reason.
But all of them will pop up the permission prompt.
But all of them will pop up the permission prompt.
> It is not impossible to conceive of malicious code being able to exploit an unpatched browser flaw and overdrive the motor to destruction.
The vibrator motors used in phones are not that fragile and vibrate being stuck on will more likely just annoy you and drain the battery faster than usual -- that is, until you get annoyed enough to pull it out.
(Maybe annoy you, as a quick search shows plenty of people who want their phone to vibrate continuously... for whatever reason.)
The vibrator motors used in phones are not that fragile and vibrate being stuck on will more likely just annoy you and drain the battery faster than usual -- that is, until you get annoyed enough to pull it out.
(Maybe annoy you, as a quick search shows plenty of people who want their phone to vibrate continuously... for whatever reason.)
Most use of the vibrate API will obviously be malicious if it's implemented without spam prevention; otherwise I won't be able to disable the feature fast enough.
The only way this could be workable is if there were something like an HTML meta tag for requesting vibrate support for scripts running from your domain, and that would prompt a one-time dialog to white-list that domain for vibrate support in JS.
The only way this could be workable is if there were something like an HTML meta tag for requesting vibrate support for scripts running from your domain, and that would prompt a one-time dialog to white-list that domain for vibrate support in JS.
These are interesting hacks and there should probably be some ways to help users avoid being deceived in this way.
However they don't have much to do with the introduction of the vibrate API. What this assumes is that the phone vibration is something the user should or could generally rely on to distinguish between genuine system functions and fakes. That's just not true for many reasons.
However they don't have much to do with the introduction of the vibrate API. What this assumes is that the phone vibration is something the user should or could generally rely on to distinguish between genuine system functions and fakes. That's just not true for many reasons.
I thought HTML audio couldn't be auto-played without first receiving a tap from the user? If true, the fake phone call trick wouldn't be possible.
That's the limitation I noticed anyway when I had a quick go at an audio web app a year ago. I couldn't get sounds to play on load without first a tap from user - this was on iOS Safari anyway, I didn't test on other browsers.
That's the limitation I noticed anyway when I had a quick go at an audio web app a year ago. I couldn't get sounds to play on load without first a tap from user - this was on iOS Safari anyway, I didn't test on other browsers.
This is really a limitation on iOS, see my blog post on the subject here: http://debuggerdotbreak.wordpress.com/2012/06/12/apple-pleas...
It's a limitation that makes it quite annoying to build HTML5 audio apps, which is what my startup does. I have several hacks in my code to accomodate iOS's crippled HTML5 audio implementation.
It's a limitation that makes it quite annoying to build HTML5 audio apps, which is what my startup does. I have several hacks in my code to accomodate iOS's crippled HTML5 audio implementation.
It depends on the browser. In Firefox, it will autoplay.
But, that said, there's nothing to stop you adding an onClick() event to any part of your page which will then play the audio.
But, that said, there's nothing to stop you adding an onClick() event to any part of your page which will then play the audio.
"No one cares about Windows Phone or BlackBerry - so I didn't test them."
Often these forgotten platforms have the most issues with attackers/exploiters. There was just an article on here the other day about the wave of Windows XP exploits we are bound to see now that it no longer gets patched.
Often these forgotten platforms have the most issues with attackers/exploiters. There was just an article on here the other day about the wave of Windows XP exploits we are bound to see now that it no longer gets patched.
Can't wait for Adblock for IOS.
[However we get less annoying ads because safari don't play flash. Advertisers are obviously moving to different kind of ads adapted to mobile. Anyway it's reasonable to dread for the time that they'll catch up with the desktop ones.]
[However we get less annoying ads because safari don't play flash. Advertisers are obviously moving to different kind of ads adapted to mobile. Anyway it's reasonable to dread for the time that they'll catch up with the desktop ones.]
More annoying ads because they redirect to some random app in the store, blanking the page in the process so you can't even go back to it
This could be another vector for transmitting data out of a device without detection.
It's easy, just disable plugins!
oh wait...
oh wait...
ASCII control-G all over again
Uhm, if your argument against a HTML5 API is "it's possible that the browser is hackable" then I don't see the discussion going very far. Like, you can use the same argument against HTTP support.
Combine it with a WebRTC call and you're looking at a very convincing scam.
WebRTC does require explicit user permissions.
I honestly don't see how the buzzing is in anyway crucial in in the explained examples. You can mimic real UI and trick users. This has been around on desktop for ages with fake Windows dialogs. Take away the buzz in the example on the webpage and the majority of people will still "pick up the phone".