Practical Protection Against DNS Rebinding Attacks

Tuesday. July 31, 2018 - 4 mins

Background

DNS rebinding is a known attack against the same origin policy of modern browsers.

The attack abuses DNS, where a request with a small TTL is set. After the TTL is reached, another query resolves to another IP address (a local or internal IP address in typical cases). This way, an unauthorized party can bypass the same origin policy by loading malicious code on browsers and executing it against local or internal networks. Theoretically speaking, SOP prevents this from happening. However, DNS rebinding can bypass this protection in certain circumstances.

There has been much research on exploiting DNS rebinding attacks in the previous years.

Problem

Although this attack has been known for years, securing an environment against DNS rebinding is typically done on the application level only.

This is not the best approach, as there is a larger surface that we can control to block these attacks.

Proposed Solution

A DNS rebinding attack that exploits a local service shows that the domain name is pointing to a loopback address. Similarly, if it’s exploiting a service in the internal network, the domain name will be shown to be pointing to a private address.

In a well-structured environment, we should not rely on public DNS records to point to a loopback or private address; there is no reason to do so.

Idea

If the DNS query response is a record that points to a loopback address, then this is a potential DNS rebinding attack. This should be blocked.

This will effectively block DNS rebinding attacks against local addresses if done correctly.

Implementation

DNS resolvers have this feature built-in. For example, you can configure BIND to block a query where the DNS record is on the IP range.

IPtables can help with applying a patch, too. The problem is that there is no direct way to use it.

“bash $ iptables -I INPUT -p udp --sport 53 -m string --algo bm --hex-string '|7f000001|' -j DROP``

This will block any DNS UDP inbound traffic on port 53 that holds “127”.

Why not “127.0.0.1”?

The internal loopback is /8 range. Any IP address on the range is pointing to the associated local machine.

Will this IPtable rule 100% mitigate against the attack?

This is a starting point for research on protecting against DNS rebinding attacks. It initiates a starting point for security vendors and endpoint security solution vendors to apply it to customers.

All IANA-private IP ranges should be blocked within the local network using the abovementioned approach.

This is, of course, in addition to the IPV6 address that points to the internal loopback.

The IPtable command is a simple proof of concept.

Blocking DNS queries that resolves to Private IP addresses via DNS resolvers

DNS resolvers can block this attack. For example, BIND9’s RPZ (Response Policy Zone) can be configured to block responses of queries resolving to specific IP addresses via “Policy Trigger - IP Trigger”.

This can be a stable solution for production environments.

How about QUAD9 Secure DNS Resolver?

I have tested QUAD9 Secure DNS resolver, and they do not protect DNS Rebinding attacks.

Other DNS resolvers are assumed not to provide protection, as this is not their goal. However, QUAD9 should block attempts of DNS rebinding attacks.

Acknowledgment

I want to thank Andzej Valcik for his contribution to the research.

Update (September 16th, 2018):

NCC Group released research regarding DNS rebinding attacks and a “ Singularity” tool.

An interesting bypass that NCC group demonstrated in the research is the usage of a CNAME that points to “localhost”. Since “localhost” is already registered in the typical local resolver (at hosts file, for example) as 127.0.0.1, this will also be required to be blocked using the same approach mentioned in my research.

Blocking this bypass will be straightforward. The rule should block any DNS query that responds with a CNAME of “localhost”.

Link to NCC group research: Link

Mazin Ahmed

Thoughts of a hacker