How to hack DNS
Gary Hawkins
Views are my own, may be exaggerated for dramatic effect, and subject to change without warning or reason.
"It's always DNS" has become a running gag amongst sysadmins. With alarming frequency, broken DNS is found at the heart of a catastrophic failure, often manifesting in cruel and unusual ways.
However, there's a vast difference between broken DNS and insecure DNS. Insecure DNS gets a lot of attention from some quarters so here I'll explore what it would take to compromise insecure DNS. If you're reading this then I'll assume you have at least some familiarity with DNS, what it is and how it works. If not, Cloudflare provides a decent intro here.
First up, we're focusing here on DNS Cache Poisoning in the absence of DNSSec. There are various other attacks relating to DNS which typically fall under 1) compromising a DNS provider/account to alter DNS records (not per se an attack on the DNS protocol or insecure DNS records) 2) using DNS as a control channel (also not an attack on DNS) or 3) DDoS against DNS providers (a la Mirai botnet against DynDNS, still not an attack on DNS).
What is DNS Cache Poisoning? Cloudflare has a good primer here but in summary, it's tricking a DNS server into remembering the wrong IP address for a target domain name so it returns that wrong IP address the next time someone queries that domain name.
Is it as simple as that? No. A successful attack is technically complex, requires extensive research, guessing random large numbers, brute force, and a fair amount of luck. If you succeed then you've compromised one DNS record on one of the millions of DNS resolver servers around the web. The attack only works if the target DNS record doesn't already exist on the resolver, and your compromise only lasts for the TTL (time-to-live, the period of time that a DNS record remains valid before being refreshed) window which is typically five minutes, but could be as long as one day.
Sounds tricky. Anything else to consider? After all of that, you still have no control over who might use that resolver or what domain names they might query. If you're targeting a known individual, even if you're able to work out which DNS resolver they're likely to use, you then need to persuade them to visit the target website within that narrow window of opportunity, so you need a second vector like phishing or social engineering. A plausible but distinctly different skill-set that brings greater likelihood of detection.
Let's assume all of that happens, what next? Against the odds you've snuck in a fake DNS record and lured your victim. They think they're visiting a known and trusted website but they're really visiting your spoofed copy of the website. So you need to have created and hosted a spoof of the target website. That's a different skill set, not so difficult but another opportunity to leave a paper trail.
领英推荐
Great, I've got them! Right? Not so fast. Chances are that any worthwhile website uses HTTPS and HSTS, so what do you do? It's not impossible to obtain a valid HTTPS certificate for a domain you don't actually own, but it's far from trivial. You could use a self-signed certificate, but the web browser will likely paint a big red [untrusted] warning. You could downgrade the connection to HTTP, but the web browser would almost certainly paint a big red [insecure] warning. Neither of these are absolute gotchas but they drastically increase the likelihood of the victim getting suspicious.
Let's assume they're an idiot and ignore the warnings. What then? Well, then perhaps the victim falls for your ruse, visits your spoofed website and hands over something important, like credentials. Congratulations, you've compromised one single, solitary user account. That's all assuming that the genuine website doesn't have additional obstacles like device validation, trusted locations, or security monitoring. The more valuable the target website, the higher the likelihood of there being additional mitigations, protections, detections.
That's a lot of dominos that need to fall in your favour for very little reward. It's like trying to hit a bullet with a smaller bullet whilst wearing a blindfold, riding a horse, to win a fairground goldfish.
?
?
There you have it. It is entirely possible to compromise a DNS record that's not using DNSSec, but claiming that it's the root cause of any real harm is like dropping a pebble in the ocean and calling it a tsunami.