Practical Attacks with DNS Rebinding

[steven36]

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, rbndr.us, which is running his Simple DNS Rebinding Service, but I opted to create a small Python implementation and varied my approach slightly. Whereas Tavis’ rbndr implementation alternates between targeted addresses, I had better results when my server responded only once with my public IP.

 

My implementation packages a very basic HTTP server and DNS server in about 100 lines of Python. Example output (with my domain name redacted) is shared below:

 

 

 

Putting the Pieces Together

As a proof-of-concept, I exploited VERT’s NETGEAR Centria router using an authentication bypass to exploit command injection on a form including a CSRF token.

Successful end-to-end exploitation includes:

1. Victim loads an IFRAME from an attacker controlled domain.
2. The IFRAME loads JavaScript to identify the local IP via WebRTC.
3. Each IP on the victim’s /24 is queried for a path expected to exist on the router.
4. The JavaScript submits this IP to the attack server and receives a token value.
5. The token value is used to construct a domain name and update the IFRAME location.
6. JavaScript loaded from this source sets an interval timer.
7. The timer callback makes requests to the crafted domain.
8. After the DNS entry expires, the domain is resolved to a LAN IP.
9. The timer callback can now fetch the CSRF token with an auth bypass.
10. An attack payload is sent with the observed timestamp.

 

 

Here is a view of what the exploit looks like in my browser:

 

Once this is complete, I am able to telnet to the router on port 1234:

 

 

Attack Performance and Lessons Learned

This is not a fast attack, but it is quite powerful. The specific attack duration varies based on the timer interval (step #6) as well as the browser and OS combination. In my testing with Chrome on OS X, I’ve found that the rebinding can be as fast as 1 minute with a short enough interval (hundreds of ms) or as much as 5 minutes when the interval is 3000 ms. This is a trade-off between speed and stealth.

Conclusions

DNS rebinding is quite usable in real-world attacks.

As of now, IoT attack campaigns have been quite successful attacking only publicly exposed devices, but it is only a matter of time before there is too much competition for this low-hanging fruit. Botnet operators will then seek out better techniques for reaching valuable targets on private corporate and home networks.

Network administrators and product vendors need to adopt the mentality that anything available on the local network via HTTP is also available to remote attackers. If any of these servers allow anonymous/unauthenticated access, an attacker will likely seek out these systems and steal, manipulate, or even destroy the data they provide or the systems they control.

To learn more about the techniques I use for finding and exploiting IoT vulnerabilities, please check out my 2018 class offerings at Black Hat USA and SecTor.

 

Written by Craig Young

 

Source