Malicious Use of the HTML5 Vibrate API

http://shkspr.mobi/blog/2014/01/malicious-use-of-the-html5-vibrate-api/

by edent • 13 years ago

156 66 13 years ago

Udo• 13 years ago

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.

andyroid3• 13 years ago

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.

Shaanie• 13 years ago

Which app, if you don't mind me asking?

jheriko• 13 years ago

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.

gcp8• 13 years ago

It is not impossible to conceive of malicious code being able to exploit an unpatched browser flaw and overdrive the motor to destruction.

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

edent5• 13 years ago

(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.

callum85• 13 years ago

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.

gus_massa• 13 years ago

My mayor concern was:

Autoplaying sound on adverts in annoying - auto-vibration could be just as irritating.

Sound can be mutated. I don’t know how difficult could be to turn off the vibration.

grrowl• 13 years ago

Hopefully a Chrome-like "prevent this page affecting vibration" dialog.

egeozcan• 13 years ago

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.

gcp8• 13 years ago

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

illyism• 13 years ago

You can't do this on a phone however as far as I know. The vibrate API is build for mobile devices.

anuraj2• 13 years ago

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.

TeMPOraL2• 13 years ago

What about ads? The ones that now e.g. pretend to be Skype pop-ups.

anuraj2• 13 years ago

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.

AshleysBrain• 13 years ago

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.

Qworg• 13 years ago

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.

michaelmior3• 13 years ago

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.

freehunter• 13 years ago

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.

pilif• 13 years ago

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.

Karunamon• 13 years ago

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.

robmcm• 13 years ago

It's easy, just disable plugins!

oh wait...

hartator• 13 years ago

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.]

corobo• 13 years ago

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

thrillgore2• 13 years ago

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.

gcp8• 13 years ago

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.

thrillgore2• 13 years ago

Compared to having your phone vibrate ad nauseum for no determinable reason whatsoever?

basicallydan• 13 years ago

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.

exodust• 13 years ago

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.

edent5• 13 years ago

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.

judah5• 13 years ago

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.

theg2• 13 years ago

Windows Phone, once again safe from the dangers of the Internet standards and features!

judah5• 13 years ago

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.

edent5• 13 years ago

Nope. Just standard .mp3 in the demo.

gcp8• 13 years ago

I'm guessing the demo used OGG or some other audio format not supported by mobile IE.

The demo uses MP3.

judah5• 13 years ago

Strange, because I am able to play native HTML5 MP3 audio on other sites just fine.

judah5• 13 years ago

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...

gcp8• 13 years ago

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.

avighnay• 13 years ago

Good one! :-)

kordless• 13 years ago

This could be another vector for transmitting data out of a device without detection.

gcp8• 13 years ago

Without detection? Are you serious?

Semaphor• 13 years ago

Without detecting that actual data is transmitted and not just some random vibration.

I don't know how exact those motors are, but I could imagine it is possible that even 2-3s of vibration could easily transmit a password.

Zikes• 13 years ago

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?

yuubi• 13 years ago

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.

shubb• 13 years ago

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.

crystaln• 13 years ago

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.

sgarman• 13 years ago

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

coin• 13 years ago

ASCII control-G all over again

WiseWeasel• 13 years ago

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.

jlebar• 13 years ago

(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. :)

userbinator• 13 years ago

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.)

Malicious Use of the HTML5 Vibrate API

Related Stories