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:
- Attackers do not know private network address ranges ahead of time.
- 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:
- Victim loads an IFRAME from an attacker controlled domain.
- The IFRAME loads JavaScript to identify the local IP via WebRTC.
- Each IP on the victim’s /24 is queried for a path expected to exist within the router.
- The JavaScript sends this IP to the attack server & receives a token value.
- The token value is used to construct a domain name and update the IFRAME location.
- JavaScript loaded from this source sets an interval timer.
- The timer callback makes requests to the crafted domain.
- After the DNS entry expires, the domain is then resolved to a LAN IP.
- The timer callback can now retrieve the CSRF token with an auth bypass.
- 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