One of the tools I expect to see gain in popularity in the wild is DNS rebinding. DNS rebinding is a technique that turns a victim’s browser into a proxy for attacking private networks. Attackers can change the IP associated with a domain name after it has been used to load JavaScript. Since same-origin policy (SOP) is domain-based, the JavaScript will have access to the new IP.

This blog post outlines some of what I’ve learned while preparing a DNS rebinding lab exercise for Black Hat and SecTor.

There are two general challenges we must overcome to attack network devices:

  1. Attackers do not know private network address ranges ahead of time.
  2. Cross-domain access is restricted by the same-origin policy.

Finding Network Devices

The most common technique is to simply guess common network addresses. This can be quite effective for certain devices like routers. This is why I suggest using non-default IP ranges on home routers. There is also a more sophisticated technique I’ve previously referred to as Smart CSRF. This process uses STUN on supported browsers to recover a local IP. (Interestingly, Chrome may be the only browser supporting this in a current release.)

Working Around the Same-Origin Policy (SOP)

Armed with knowledge of a device IP address, some attacks become quite trivial to carry out. For example, the NETGEAR cgi-bin command injection can be exploited with a simple IMG tag to trigger a GET request. Other attacks, however, require that the attacker has more interaction with the vulnerable system than simply sending data and, therefore, traditional CSRF techniques fail. The same-origin policy prevents attackers from reading this response data, so we must use DNS rebinding.

Tavis Ormandy has a domain,, which is running his Simple DNS Rebinding Service, but I opted to create a small (Read more...)