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.

Background

Many Internet-of-Things (IoT) devices are exposed to the Internet. Attackers can scan the Internet, discover vulnerable devices, and exploit vulnerable devices at scale. A notable example to this class of attacks is the 2016 DDoS campaign by the Mirai botnet, which caused massive outages for several popular online platforms.

IoT devices that are not exposed to the Internet — such as those that are connected to your home network — are not safe from attacks either. Many IoT devices, including Google Home and Chromecast, have unauthenticated web interfaces that allow companion smartphone apps, device hubs, or home automation software to discover, query, and control them. This design, which favors openness and interoperability over security, leaves the door open to web-based attacks that use the browser to circumvent firewalls and network address translation (NAT).

How does our attack work?

For this attack to work a victim needs to visit a website that contains a malicious script while using her home network. The malicious JavaScript may be embedded by the website owner or served by a malicious ad.

The attack is composed of two stages: discovery and DNS rebinding.

• Stage 1 – Device Discovery: The malicious script scans local IP addresses in parallel using Web Workers and a cross-origin response status leak that we discovered. At the end of Stage 1, the attacker detects whether the victim has a particular device (e.g. Google Home or Chromecast), along with the IP address of the device. As shown in our demo video, it takes around seven seconds to scan all 256 local IP addresses.
• Stage 2 – DNS Rebinding: For each identified device, the malicious script attempts to perform DNS rebinding using Jaqen. Once the DNS rebinding is complete, the attacker can send commands to control the IoT device or extract personal information such as unique identifiers and WiFi access point BSSIDs (which can be used to gather the precise geolocation of the user).

Table 1. What an attacker can achieve using DNS rebinding.

Are these attacks limited to Google devices?

Unfortunately, no. We found other devices, including a smart switch, a smart TV and two network cameras, that are vulnerable to one more of the threats outlined in Table 1. We disclosed these vulnerabilities to respective vendors in April 2018. We plan to publicly disclose the details of these vulnerabilities at the end of the standard 90-day vulnerability disclosure period.

What are the potential risks?

• Identifying vulnerable software: IoT firmware model and version information can be used to detect IoT devices with known vulnerabilities. Users with outdated or vulnerable devices can be further targeted to compromise devices, spread malware, or conduct DDoS attacks.
• Location tracking: Nearby wireless network identifiers (BSSIDs) can be used to infer the precise location of a user via publicly available geolocation APIs such as Google Geolocation API. This is the technique we use in the demo video. See Young’s blog post for the details of this attack.
• User tracking: Unique device identifiers such as MAC addresses and device serial numbers can be used to track users across websites and devices even if they clear browsing data or use private/incognito mode.
• Deanonymization: An attacker can obtain the username of the victim for one of the network cameras in our study. If the username resembles the real name of the victim, the attacker can potentially identify the device owner.
• Intrusion: On Chromecast and a smart TV in our study, an attacker can play arbitrary videos.

How is our attack different?

Compared to two recently published attacks, our attack is much faster (taking around ten seconds [1]), and does not assume the knowledge of the device IP addresses. We take advantage of Web Workers and a cross-origin resource status leakage we discovered during our research to speed up the device discovery.

In comparison, Young’s attack takes approximately a minute to complete and it assumes the knowledge of the device IP addresses — an assumption we do not make. Dorsey’s attack sequentially performs DNS rebinding on all possible local IP addresses and all possible devices, which results in an even slower attack.

In addition, compared to prior work on web–based LAN scanning, the device discovery part of our attack does not require images (or stylesheets) to be present on the web interfaces, and it circumvents mixed content protections, making it usable on HTTPS websites. This, along with the speed of the attack, makes it a much more feasible attack compared to alternatives.

Who can mitigate this problem and how?

Here are a few examples of how each stakeholder in the IoT ecosystem can mitigate the problem [2]:

• IoT manufacturers can validate the Host headers of incoming HTTP requests.
• DNS providers or ISPs use dnswall or similar software to filter out private IP addresses from DNS replies.
• Home users can use ad-blockers or tracking protection extensions to block malicious ads. Also certain OpenWRT-based routers can filter private IP addresses in DNS replies.
• Browser vendors:  Past attempts to mitigate DNS rebinding in the browser broke some web services and led to new security vulnerabilities. We believe that a browser-based defense remains as an open research problem.

Responsible Disclosure

We reported vulnerabilities discovered throughout our research to respective browser (Mozilla and Chromium) and IoT vendors (Google and three other vendors) in April 2018. The Chromium project awarded a bug bounty for our disclosure. Google Home and Chromecast team told us that the reported issue “is a duplicate of an existing bug”. We plan to release our paper and the full technical details of the attack after the 90-days disclosure period.

Other IoT Projects At Princeton

To learn more about other IoT-related projects at Princeton, check out https://iot-inspector.princeton.edu/.

Endnotes

[1] Exact duration of the attack depends on factors including the particular IP the device is on, and how fast the device responds to our queries.
[2] For a more elaborate study of DNS rebinding defenses, see, https://crypto.stanford.edu/dns/.