Discovering and hacking IoT devices using web-based attacks

DNS rebinding attacks have been the topic of ongoing discussion for twenty years. Despite their efforts, browser vendors still can’t find a stable defence against these attacks. They were reported to have been be fixed eight years ago. However, this type of attack has resurfaced against a new attack vector.

In general, it’s safe to say that the upcoming trend for malicious hackers will consist of a combination of multiple existing attacks, forming new attack vectors. The DNS rebinding attack that made the cryptocurrency wallets vulnerable is a good example of these new attack vectors.

In this article, we discuss the research conducted at Princeton and UC Berkeley on web-based attacks carried out against Internet of Things (IoT) devices which led to the discovery, hacking and takeover of these devices. The research was published in August 2018.

Devices and methods used in the discovery and hacking of IoT devices

Researchers aimed to test 15 IoT devices. Only seven of these devices were found to have local HTTP servers, so the research focused on them. They included: Google Chromecast, Google Home, a smart tv, a smart switch, and three cameras.

The attack method they used aimed to:

1. Deceive the victim in order to make them visit an attacker controlled website
2. Discover the IoT devices on the victim’s local network
3. Take control of them using web-based attacks.

Duration of the attack

Technically, this isn’t a new vector. The research paper cited earlier studies that discovered that it takes a minute, on average, for attackers to use these attack vectors to get results. Curiously, the results of a well-known study (What You Think You Know About the Web is Wrong) revealed that 55% of users spend no more than 15 seconds on a website. It appears that most users will not be affected by the IoT vulnerability.

However, in the Princeton and UC Berkeley study, researchers significantly decreased the duration of the attack. They stated that, using the method they discovered, devices in the local network could be discovered and accessed quicker than the previous studies – except in the case of Chrome, as it caches DNS requests and ignores the TTL, if it's under a certain threshold. It is important to note that devices in a Demilitarized Zone (DMZ, internal network, behind a firewall) are generally considered to be secure, because users assume that outsiders cannot reach these devices. However, in the attack described here, the attacker already had access to the browser in the victim’s internal network!

HTTP endpoint discovery

Researchers analyzed the devices by connecting them to a Raspberry Pi wireless access point. The packets sent to and received from the devices, and the packets sent to and received from the mobile applications tied to each device, were observed and analyzed. As a result of this analysis, 35 GET request endpoints and eight POST request endpoints were discovered. These endpoints were used to identify the IP addresses in the discovery phase of the research.

Phases of research on IoT devices

Researchers conducted the study in two different phases, Discovery and Access:

• The Discovery phase aimed to find IoT devices on the local network that contained HTML5 elements on the browsers
• The Access attack phase aimed to reach the HTTP endpoints using DNS rebinding and discovered IP addresses

Discovery phase: Identifying IoT devices

These are the steps taken in the Discovery attack phase of the study:

1. Obtain local IP address with WebRTC.
2. Send requests to all IP addresses within the IP range on port 81. Since port 81 isn’t generally used, active devices would respond with a TCP RST packet immediately. For non-active devices on the IP range, the request packets would time-out.
3. Each active IP address received the requests collected at the initial phase for the 35 GET endpoints using HTML5. Depending on the error messages returned, the attack script discovered whether the IP address matched with any of the seven devices.

The researchers planned to use three different operating systems (Windows 10, MacOS, and Ubuntu) and four different browsers (Chrome, Firefox, Safari, Microsoft Edge). However, Chrome and Firefox were the only two browsers that were a suitable fit for the study. Therefore, Safari and Edge browsers were discontinued because (quoting the research paper):

On Safari, all the Fetch requests timed out, so the attack script considered all IP addresses as inactive. In contrast, the script could use Fetch to correctly identify the active IP addresses on Edge, but the Edge browser did not expose detailed HTML5 error messages. Thus, the attack script was unable to identify any devices on Edge.

Access phase: Taking control of the IoT devices

Here are the steps in the Access attack phase of the study:

1. The victim visits the attacker controlled domain (domain.tld) and the victim’s browser executes the malicious JavaScript found on the attacker’s site. The domain still resolves to the attacker’s server IP.
2. JavaScript requests another resource on domain.tld that is only present on the attacker's server (e.g. the message 'hello' on http://domain.tld/hello.php).
3. If the victim’s local DNS cache still resolves to the attacker’s remote IP, the result of the query to /hello.php will yield the string 'hello', and the JavaScript repeats step 2.
4. However, if domain.tld is expired in the victim’s cache, a new DNS query will be sent to the attacker’s name server.
5. Eventually, instead of the attacker’s remote IP, the local IP obtained from the Discovery attack will be returned, and /hello.php won't reply with the string 'hello', but with something different, like a 404 error, which tells the malicious script that the DNS rebinding attack was successful.

As a result of this attack, the malicious script circumvented the Same-Origin Policy and gained access to the web application running on the device. Now the attacker could reboot and launch video or audio files on Google Chromecast, Google Home, the smart TV, and smart switch devices.

How to prevent DNS rebinding attacks on IoT devices

According to the researchers, the user, browser vendors, IoT manufacturers, and DNS providers each have to take precautions in order to avoid a DNS rebinding attack. Here are some of the countermeasures listed in the research:

1. The user can disable WebRTC on their browser, and prevent private IPs from disclosure. The attacker will then be able to discover the user’s private IP by sending requests to all the *.1 addresses (router’s address) in the private IP range.
2. The attacker assumes that all the IoT devices have the same IP range as the victim's PC. The user can configure their home router's DHCP server to give out IP addresses on another subnet, such as /16.
3. The user can install dnsmasq, which prevents DNS rebinding by dropping the RFC 1918 address from DNS replies. The user can also use OpenWRT routers which use dnsmasq.
4. IoT manufacturers can control the Host header in the requests sent to web interfaces. If there isn’t a private IP that complies with RFC 1918, they can block access.
5. DNS providers can use a mechanism such as dnswall to filter private IPs from DNS replies.
6. The browser vendors can develop extensions that limits the access of public websites to private IP ranges.

Further information

For detailed information on the Princeton and BC Berkeley research discussed in this blog post, see Web-based Attacks to Discover and Control Local IoT Devices.

To read more about web based attack vectors on applications and devices inside your local network, see Vulnerable Web Applications on Developers' Computers Allow Hackers to Bypass Corporate Firewalls.

Article written by Netsparker security researchers:

Ziyahan Albeniz
Sven Morgenroth
Umran Yildirimkaya