DNS rebinding attacks seem rather trivial to exploit once you get someone to click your link or visit a site that you have a banner ad on, but the behavior required by the authoritative DNS server is what I want to understand. Let take a look:
It seems like it would require an unusually coordinated effort on the part of the initial malicious website and the corresponding authoritative DNS server. How does victim make a request to malicious dot com, receive a DNS message with the IP address of malicious dot com, then send out a refresh request to malicious dot com because of the very low TTL and get a response containing the attack payload? — This needs to be figured… It seems like the attack vector requires victim interaction with an initial HTTP request through social engineering, a specially configured DNS server and an advanced knowledge of the victims interior network. How are these things managed?
We get the malicious request that serves up malicious dot com — and it can embed a JavaScript scanner in it to do discovery, per this website here: http://rebind.network/rebind/index.html, courtesy of Brannon Dorsey where his site scans for some well known IoT devices. The way this is accomplished is also very interesting as the browser is able to collect information about your network hosts through a side-channel discovery technique which allows it to find out if something is at a particular address by making a request to it and gauging the response time — no content would be discovered at this time as the Same Origin Policy will prevent that, save the website has CORS enabled.
So, we have established the method of ingress and discovery, but still not the tooling of your DNS server to serve up the locally addressed DNS message attack payload. How is this done?
And we found something awesome! Here is a complete framework for setting up this attack:
— https://kalilinuxtutorials.com/singularity-dns-rebinding-attack/
Okay… pay dirt. This is what I was looking for. When you implement this framework, you are deploying a dynamic DNS service that can be configured based upon a host and timing strategy that you can designate. This is how you get the DNS server to play ball when it comes time to poison the victims DNS cache by serving up a subsequent request that points into their own network.
When the service is launched, you get full access to DNS twisting functionality that you can see in the instructions to set it up:
Launch the Singularity binary, (singularity-server), with the -h parameter to see its parameters.
DNSRebindStrategy string : Specify how to respond to DNS queries from a victim client. The supported strategies are:
DNSRebindFromQueryRoundRobinDNSRebindFromQueryFirstThenSecond(default)DNSRebindFromQueryRandomDNSRebindFromQueryMultiA(requires Linuxiptables)
This represents the gearbox for how the DNS cache on the victim host is poisoned when reaching out for another FQDN hostname resolution after the 10 second TTL message has indicated its expiry. Brilliant