Opened 3 years ago

Last modified 2 years ago

#20214 needs_information defect

Ultrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

Reported by: VasiliosMavroudis Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-proxy-bypass
Cc: yanick@…, shuanghao@…, federico.maggi@…, gk@…, jackiam2003@…, VasiliosMavroudis, francois@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Emerging cross-device tracking technologies based on ultrasound could be used to fully deanonymize TOR users.

Advertisers started using ultrasounds to link multiple devices owned by the same user (i.e., perform ultrasound cross-device tracking, uXDT). For this purpose, they release advertising frameworks that can be incorporated in apps (e.g., android apps). These frameworks listen for series of tones in the ultrasonic spectrum, and once one is detected, they report it to the advertiser's servers.

It is easy to see how this could be exploited. The attacker sets up a hidden service playing such a beacon on the background and lures the victim to visit it using Tor browser. Once the victim loads the page, the tone is played through the speakers, and his/her phone picks the inaudible tone up and reports it to the advertiser's server. A state level adversary can then easily retrieve the Tor user's IP (and other unique identifiers) from the advertiser.

Since the technology is emerging, we believe that taking action now rather than later would be preferable.

One solution would be to filter-out all inaudible frequencies emitted by each visited webpage. We have developed such an extension for Chrome and a similar addon can be easily developed for the Tor browser. However, since there are similar tracking technologies using the audible spectrum: it may be a good idea to disable audio by default when using the Tor browser, or ask for user permission each time. In practice, this could be done by asking the user through popups, similarly to those used when requesting access to the user's location and the microphone.

We would be happy to provide more details and/or help in the development of a countermeasure for the Tor browser.

Child Tickets

Change History (19)

comment:1 Changed 3 years ago by cypherpunks

  1. Why wouldn't this work with audible sound? Audible sound ranges have been shown to be able to covertly issue voice commands to nearby mobile devices (https://www.georgetown.edu/sites/www/files/Hidden%20Voice%20Commands%20full%20paper.pdf). The core issue is not addressed by filtering out non-audible sound.
  1. If a user is presented with a choice to play the media file or not and if they *believe* that they want to play it, they will play it. The prompt would only serve as an annoyance that the user would learn to ignore. If your attack involves tricking a user to visit a website, tricking a user to view or allow the media on the website to play would not be significantly more difficult.
  1. The security slider at 'High' already makes video/audio content click-to-play, with the current exception of MediaSource video (see: #19200).

comment:2 Changed 3 years ago by VasiliosMavroudis

Why wouldn't this work with audible sound? Audible sound ranges have been shown to be able to covertly issue voice commands to nearby mobile devices (​https://www.georgetown.edu/sites/www/files/Hidden%20Voice%20Commands%20full%20paper.pdf). The core issue is not addressed by filtering out non-audible sound.

It can absolutely work in the audible spectrum, and indeed there is one framework doing so already.

However, our argument is not that ultrasounds are a plausible convert channel. Instead, we argue that the audio channel is already being used by frameworks embedded in apps, and that they are gaining traction in the market.

Two examples of such frameworks:

Inaudible: Silverpush (http://www.forbes.com/sites/thomasbrewster/2015/11/16/silverpush-ultrasonic-tracking/#7b5f70824024)

Audible: Intrasonics (http://www.intrasonics.com/technology-faqs/

 

If a user is presented with a choice to play the media file or not and if they *believe* that they want to play it, they will play it. The prompt would only serve as an annoyance that the user would learn to ignore. If your attack involves tricking a user to visit a website, tricking a user to view or allow the media on the website to play would not be significantly more difficult.

Absolutely. There are many possible ways to go about it. A prompt/popup comes with the advantage of actually educating the user, but indeed the user may get "blind" after a while. Same holds for all major browsers that use prompts to ask the user if access to a given resource should be permitted.

 

 

The security slider at 'High' already makes video/audio content click-to-play, with the current exception of MediaSource video (see: #19200).

We totally agree with this choice. I'm not very familiar with the rationale behind each setting on the security slider. However, our suggestion would be to extend this feature to the low-default security setting (this may not be technically straightforward though, if you want to keep JS). Of course, from a usability perspective this is not very good for the user, but with such frameworks gaining traction it seems a reasonable reaction.

Last edited 3 years ago by VasiliosMavroudis (previous) (diff)

comment:3 Changed 3 years ago by bugzilla

Keywords: tbb-proxy-bypass added
Summary: Ultrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some usersSonic Cross Device Tracking techniques could be used to launch deanonymization attacks against some users
Version: Tor: unspecified

At a first glance it looks like OP came here with a tinfoil hat, especially as most 44.1/48 kHz formats are not ultrasound capable. But, in general, there is some chance to become deanonymized during playback of watermarked media (e.g. from YouTube) in a range where compromised devices can record the differences in sound.

The prompt would only serve as an annoyance that the user would learn to ignore.

Warning as for maximization should be enough.

comment:4 Changed 3 years ago by gk

Keywords: tbb-proxy-bypass removed

comment:5 Changed 3 years ago by VasiliosMavroudis

Summary: Sonic Cross Device Tracking techniques could be used to launch deanonymization attacks against some usersUltrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

comment:6 in reply to:  3 ; Changed 3 years ago by VasiliosMavroudis

Replying to bugzilla:

At a first glance it looks like OP came here with a tinfoil hat, especially as most 44.1/48 kHz formats are not ultrasound capable. But, in general, there is some chance to become deanonymized during playback of watermarked media (e.g. from YouTube) in a range where compromised devices can record the differences in sound.

The prompt would only serve as an annoyance that the user would learn to ignore.

Warning as for maximization should be enough.

You seem to imply that it's not possible to use ultrasounds to perform this attack. However, there are already a few companies using this technology, e.g., SilverPush, Lisnr.

comment:7 in reply to:  6 ; Changed 3 years ago by bugzilla

Replying to VasiliosMavroudis:

You seem to imply that it's not possible to use ultrasounds to perform this attack. However, there are already a few companies using this technology, e.g., SilverPush, Lisnr.

Impossible on non ultrasound-capable hardware/software.

comment:8 in reply to:  7 Changed 3 years ago by VasiliosMavroudis

Replying to bugzilla:

Replying to VasiliosMavroudis:

You seem to imply that it's not possible to use ultrasounds to perform this attack. However, there are already a few companies using this technology, e.g., SilverPush, Lisnr.

Impossible on non ultrasound-capable hardware/software.

That is correct. Unfortunately, most commodity devices such as smartphones, desktop/laptop speakers, and TVs are all ultrasound-capable, making this attack relevant.

comment:9 Changed 3 years ago by Dbryrtfbcbhgf

What is the current status on addressing this possible attack?
Here is the source code to a browser extension that can prevent this Ultrasound Cross Device Tracking by blocking by filtering ultrasound frequencies.
https://github.com/mavroudisv/Silverdog/

Last edited 3 years ago by Dbryrtfbcbhgf (previous) (diff)

comment:10 Changed 3 years ago by Dbryrtfbcbhgf

Cc: jackiam2003@… added

comment:11 Changed 3 years ago by flyingbird

Ultrasound can also be easily generated and emitted with JavaScript using the Web Audio API (without the need to encode it into any media files). Also it can easily be encoded in a 44,1khz wav file, which is supported by Firefox. I think that filtering out the inaudible frequencies by default would be a good idea.

Last edited 3 years ago by flyingbird (previous) (diff)

comment:12 Changed 3 years ago by cypherpunks

Priority: MediumHigh
Severity: NormalMajor

It's a good point that prompting for all audio on low-security would hinder usability.
But blocking sounds over or under the human hearing range would hurt nothing. There are other attacks but why leave this one in when it can be fixed so easily?
This attack worls even on pags that seem 100% quiet to people. The other attacks are harder to carry out, the barrier to entry is raised from "everywhere" to "only websites with sound".

There is even a good argument for prompting on normal audio; yes, many users will be tricked, but at least you'll be able to browse places that require javascript like Reddit which you know should never require audio privileges. The prompt would make it harder for China to track people reading about Christianity or the Dalai Lama.

comment:13 Changed 3 years ago by VasiliosMavroudis

Cc: VasiliosMavroudis added

comment:14 Changed 2 years ago by fmarier

Cc: francois@… added

comment:15 Changed 2 years ago by gk

Status: newneeds_information

Vasilios: Is there a demo page showing the attack somewhere? I was wondering whether setting dom.webaudio.enabled to false, as we did for #13017, would mitigate your attack as well and thought about testing that.

comment:16 Changed 2 years ago by VasiliosMavroudis

This is a good question, I need to look more into it... but for now our demo is here!

We have collected all our material here: http://ubeacsec.org/

comment:17 in reply to:  16 Changed 2 years ago by gk

Replying to VasiliosMavroudis:

This is a good question, I need to look more into it... but for now our demo is here!

We have collected all our material here: http://ubeacsec.org/

Yes, I looked at the resources but could not find the source code of the attacker controlled website which is why I asked. :)

comment:18 Changed 2 years ago by VasiliosMavroudis

There are various ways to do it using HTML5/JS.

Two that come to mind (and I've tried myself) are:

  1. Playing an audio file in the background through html. For instance, sth like this:
<audio controls>
  <source src="horse.ogg" type="audio/ogg">
Your browser does not support the audio element.
</audio>
  1. JS as seen here:

https://github.com/MAVProxyUser/SilverPushUnmasked/blob/master/aud.js

Happy to provide more samples in private :)

comment:19 Changed 2 years ago by gk

Keywords: tbb-proxy-bypass added
Note: See TracTickets for help on using tickets.