September 24, 2018

Fast Web-based Attacks to Discover and Control IoT Devices

By Gunes Acar, Danny Y. Huang, Frank Li, Arvind Narayanan, and Nick Feamster

Two web-based attacks against IoT devices made the rounds this week. Researchers Craig Young and Brannon Dorsey showed that a well known attack technique called “DNS rebinding” can be used to control your smart thermostat, detect your home address or extract unique identifiers from your IoT devices.

For this type of attack to work, a user needs to visit a web page that contains malicious script and remain on the page while the attack proceeds. The attack simply fails if the user navigates away before the attack completes. According to the demo videos, each of these attacks takes longer than a minute to finish, assuming the attacker already knew the IP address of the targeted IoT device.

According to a study by Chartbeat, however, 55% of typical web users spent fewer than 15 seconds actively on a page. Does it mean that most web users are immune to these attacks?

In a paper to be presented at ACM SIGCOMM 2018 Workshop on IoT Security and Privacy, we developed a much faster version of this attack that takes only around ten seconds to discover and attack local IoT devices. Furthermore, our version assumes that the attacker has no prior knowledge of the targeted IoT device’s IP address. Check out our demo video below.

[Read more…]

Exfiltrating data from the browser using battery discharge information

Modern batteries are powerful – indeed they are smart, and have a privileged position enabling them to sense device utilization patterns. A recent research paper has identified a potential threat: researchers (from Technion, University of Texas Austin, Hebrew University) devise a scenario where malicious batteries are supplied to user devices (e.g. via compromised supply chains):

An attacker with brief physical access to the mobile device – at the supply chain, repair shops, workplaces, etc. – can replace the device’s battery. This is an example of an interdiction attack. Interdiction attacks using malicious VGA cables have been used to snoop on targeted users. Malicious battery introduces a new attack vector into a mobile device.

Poisoned batteries are thus capable of monitoring the victim’s system use, leading to the recovery of sensitive user information, such as: visited websites (with around 65% precision, better than a random guess), typed characters (accuracy better than random guess), when a camera shot is made, and incoming calls. Detection of the sensitive user data is an example of power analysis, exploiting a side channel information leak. Finally, the battery is also used to exfiltrate information to the attackers.

The whole attack is rather technically complex, and it is subject to debate how practical it could be to real-world attackers at this moment. But it is nonetheless very interesting, as it highlights how complex our computing devices really are, and that there is an inherent need to trust the components of our devices.

I’d like to call special attention to the exfiltration channel using the battery. It is a very interesting covert channel.

The W3C Battery Status API, implemented by major web browsers, notably Chrome, allows websites to query the information about the current battery level, as well as to disclose the rate of charge/discharge. The paper describes an exploitation of the Battery Status API in order to remotely exfiltrate acquired data. All the victim user has to do is to visit a sink website that is reading the data. Malicious batteries can detect when the browser enters this special website, and enable the exfiltration mode.

And how is the exfiltration done? It works by manipulating of “charging” states – the 0/1 state informing a website that the battery is either charging or discharging. But how to induce a steady stream of “charging” event changes in a way that encodes information? The employed technique is very interesting: it uses wireless charging, i.e. by placing a resonant inductive charger into the battery chip. What needs to be done is to place a charging coil close to the battery hardware.

Sounds complicated? It does not need to be, since we assume that an attacker is able to deliver a malicious battery in the first place. Then all the user has to do is to visit a website that would read the information using the standard W3C Battery Status API, when supported by the web browser (e.g.. Chrome is vulnerable but Firefox is immune). In principle, everything is done without any interaction with the Operating System – it is oblivious to the OS.

There is also this interesting observation:

Since the browser does not seem to limit the update rate, the state change depends entirely on the phone’s software and the charging pad state transition rate. We find that the time to detect the transition from not charging to charging (Tdc) is 3.9 seconds.

This allows the attacker to obtain a covert channel with a bandwidth of 0.1-0.5 bits/second. Of course there is no reason for browsers to allow frequent switches between charge/discharge events. So the Privacy by Design methodology here would be to cap the switch rate.

The attack may seem like a stretch (requires physical battery replacement – or poisoning hardware at a factory), and at this moment one can imagine multiple simpler methods. Nonetheless it is an important study. Is the sky falling? No. Is the work significant? Yes.

For more information, please see the paper here.

For more information about the privacy by design case study of the Battery Status API, see here.

No boundaries for Facebook data: third-party trackers abuse Facebook Login

by Steven Englehardt [0], Gunes Acar, and Arvind Narayanan

So far in the No boundaries series, we’ve uncovered how web trackers exfiltrate identifying information from web pages, browser password managers, and form inputs.

Today we report yet another type of surreptitious data collection by third-party scripts that we discovered: the exfiltration of personal identifiers from websites through “login with Facebook” and other such social login APIs. Specifically, we found two types of vulnerabilities [1]:

  • seven third parties abuse websites’ access to Facebook user data
  • one third party uses its own Facebook “application” to track users around the web.

 

Vulnerability 1: Third parties piggyback on Facebook access granted to websites

Diagram of third-party script accessing Facebook API

When a user clicks “Login with Facebook”, they will be prompted to allow the website they’re visiting to access some of their Facebook profile information [2]. Even after Facebook’s recent moves to lock down the feature, websites can request the user’s email address and  “public profile” (name, age range, gender, locale, and profile photo) without triggering a manual review by Facebook. Once the user allows access, any third-party Javascript embedded in the page, such as tracker.com in the figure above, can also retrieve the user’s Facebook information as if they were the first party [3].

[Read more…]