Over the last couple of days there has been some coverage in Wired about DNS rebinding attacks against IoT devices.

The methodology for DNS rebinding has been known for some time, but at the moment is a very unused attack method for malicious users. With a proliferation of IoT devices coming to market, it is likely to become a more widely used attack method which also has implications for devices beyond the IoT world where trust is assumed because it is on an internal network.

DNS rebinding allows a remote attacker to bypass a firewall and use the web browser as a proxy to communicate directly with devices on a private network.

What is DNS Rebinding?

DNS rebinding is an attack method which aims to break out of the browser’s in-built "same-origin" security policies.

These policies were put in place by browser vendors in the early days of the World Wide Web when it was decided that it wouldn't be a good idea for pages served from one domain to be able to make requests to another domain without explicit permission. To put this another way, it’s how 'sessions' work in a browser, meaning if you have your bank website open in one tab and a malicious website open in another tab then these are treated as separate browsing 'sessions' to those specific domains ensuring the malicious website can't use your open session to the banking website to access your accounts.

DNS plays into this by being the middle-man between the domain name (for example, yourbank.com) and the IP address of the servers that sit behind that domain to serve the website (for example, 8.8.8.8). When your browser needs to serve the web page for 'yourbank.com' it will first check its DNS cache and local DNS to see if it has recently resolved the domain, if it hasn't then your browser will look up the authoritative name servers for the domain name in order to find out the IP address of the server it needs to communicate with in order to serve the web page.

Now, if you had a malicious website (i.e. evilsite.com) on an IP address of 1.1.1.1 which quickly changed its DNS entry to match that of 'yourbank.com' on 8.8.8.8, your browser wouldn't have noticed anything had changed because the domain names are still the same which matches the "same-origin" policies. In fact, instead of talking to the server that hosted the files for 'evilsite.com' your browser would be talking to 'yourbank.com' and has been successfully tricked into talking to a completely different server under the same session.

Example of a DNS Rebinding attack

  • An attacker controls the domain 'evilsite.com' along with the DNS servers that control the DNS records for that domain name.
     
  • A user is tricked into going to 'evilsite.com' through phishing, cross-site scripting or even through an HTML banner advert.
     
  • The user’s browser will request the DNS records for 'evilsite.com' to find the IP address of the server it needs to talk to in order to load the web page. On the first few requests the "real" IP address for 'evilsite.com' (1.1.1.1) is returned but with a very low "Time to Live" (TTL) value.
     
  • The web page is loaded from 'evilsite.com' which includes malicious JavaScript that will execute in the browser. This JavaScript contains a payload that the attacker wants to execute on your private network – If it's targeting an IoT device or an open API then this might be a HTTP POST request to something like http://evilsite.com/thermostat with JSON of {"temperature": on, "heat": 60}.
     
  • Initially this JavaScript would be running against the original IP address of 1.1.1.1 as the HTTP POST request is to the domain name 'evilsite.com', but after a point the DNS cache in the browser will time out and it will make another request for the DNS records of 'evilsite.com'.
     
  • At this point the DNS server that the attacker controls will change the DNS record for 'evilsite.com' to have an internal IP address of 192.168.0.55. This IP address could change with every new request for the DNS record if the attacker is trying private IP addresses out to see if there is any response.
     
  • This is the important part- because the domain name hasn't changed, the browser is still working within its "same-origin" policy. However, the POST requests for http://evilsite.com/thermostat will now resolve on the users computer to an internal IP address of 192.168.0.55 which happens to be your smart thermostat.
     
  • Since most IoT devices currently have unauthenticated web servers and APIs, they rely on everything within a private network being trusted and the firewall to protect them. As such, that POST request is now sent to the thermostat which processes the (supposedly trusted) request and increases the temperature to 60 degrees.

What is at risk?

The vast majority of IoT devices rely on the concept of the 'walled garden' where every device on a private network can be trusted and so there has not been authentication put into the web servers or APIs which run on these devices.

While increasing the temperature in your home might be annoying, consider if that smart thermostat was controlling the temperature in an industrial refrigeration plant. Or, that devices such as Google Home utilise an undocumented API which doesn't have authentication, allowing an attacker using this method near unrestricted access to be able to launch apps, reboot the device, perform factory resets or scan available WiFi networks.

The last option for scanning available WiFi networks has serious implications for secure browsing, this information could be used with publicly available WiFi location data to get an accurate location for the user – This would work even if you had all geo-location APIs disabled and are using a VPN or Tor to tunnel your traffic.

Outside of IoT, there is a risk to routers with UPnP enabled by default – UPnP provides administration control of the router configuration to any device on the network. By using this attack method, it would be possible for an attack to use UPnP to reconfigure your routers DNS, NAT, port mappings and access the router’s IP as well as traffic information. This would allow an attacker with the ability to permanently open a hole in your firewall for TCP or UDP traffic to attack devices supposedly protected by the firewall directly without requiring the HTTP proxy limitations of the DNS rebinding attack method.

While the DNS rebinding attack is limited to HTTP requests and so home user IoT or routers are the obvious target, there is also a risk to SMBs in particular. If you have unauthenticated APIs running on your private office network or storage (think consumer grade / mid-tier NAS) which responds to HTTP with the assumption of trust because the request came from within the network then it exposes your business to this attack method.

This gets worse because a lot of SMBs use consumer grade routing hardware within their office networks which opens up the possibility of using the DNS redirection attack to attack UPnP and opening a permeant route into your private office network which would likely go unnoticed by many businesses for a significant period of time.

What can be done?

There are a few things that should help to mitigate the possibility of this attack:

  • Use a trusted DNS service as the default resolver on your router. OpenDNS Home provides a free DNS service that can be configured to filter suspicious IP addresses (such as a private range coming from a public domain name) from the DNS responses. To implement this, you would need to change your router’s default DNS servers from your ISPs to the OpenHome DNS IP addresses.
     
  • You can take filtering and control into your own hands by running your own trusted DNS that acts as the default DNS server and provides the filtering of suspicious IP addresses. Dnsmasq or an open router firmware (DD-WRT) would let you do this.
     
  • Ensure that devices within your network (if they support it) only answer to authenticated HTTP requests and API calls.
     
  • Longer term, we need a change in the security practices of developers to move away from trusting all devices on a network by default. A very simple initial step in this is to implement 'host header' validation on the HTTP server that is serving the requests. This can be a domain or an IP address, but it should ensure that the server that receives the HTTP request will validate that its own host matches the host being requested.