Update: Attacks with DNS Rebinding

One of the tools we expect to see gain in popularity in the wild is DNS rebinding.

What is DNS rebinding? It’s a technique that turns a victim’s browser into a proxy for attacking private networks. 

Basically, 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.

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 guess common network addresses. This can be quite effective for certain devices i.e routers. There is also a more sophisticated technique previously referred to as Smart CSRF. This process uses STUN on supported browsers to recover a local IP. (Chrome is the only browser supporting this in a current release.)

Working Around the Same-Origin Policy (SOP)

Armed with knowledge of a devices IP address, some attacks become quite tricky to carry out. For instace, the NETGEAR cgi-bin command injection can be exploited with a simple IMG tag to trigger a GET request.

Other attacks require that the attacker has more interaction with the vulnerable system than simply sending data and, therefore, traditional CSRF techniques will fail. The same-origin policy prevents attackers from reading this response data, so we have to use DNS rebinding.

Tavis Ormandy has a domain named rbndr.us, which is running his Simple DNS Rebinding Service, but we 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 the server responded only once with our public IP.

My implementation packages a very basic HTTP server and DNS server in about 100 lines of Python. Example output (with domain redacted) is 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 within the router.
4. The JavaScript sends this IP to the attack server & 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 then resolved to a LAN IP.
9. The timer callback can now retrieve 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

This is not a quick attack, but it is powerful. The specific attack duration varies based on the timer interval (step #6) as well as the browser and operating system combination.

In our testing with Chrome on OS X, I’ve found that the rebinding can be as fast as one minute with a short enough interval (hundreds of ms) or as much as five minutes when the interval is three thousand ms. This is a trade-off between speed versus stealth.

 

Olé Crypto,

CBNN