Practically speaking, how easy difficult is it to spoof DNS?
What scenarios are more risky than others? For example:
A phishing email or twitter link that attracts users to click a hyperlink
A link on an internal sharepoint site on a different subnet
Where a malicious user may be on the same subnet.
other scenarios... (please add your own)
If the victim is using an open wireless network, spoofing DNS is easy. It is easy for the attacker to mount a man-in-the-middle attack and send forged DNS responses. Therefore, if you are using an open wireless network, you should not trust DNS at all: it is trivial to spoof.
Similarly, if the attacker is on the same subnet as you, spoofing DNS is easy: in this case, it is trivial for the attacker to eavesdrop on your DNS requests and then spoof responses and play man-in-the-middle games.
If the victim is using some other network, spoofing DNS is not easy but potentially feasible. If the victim is connected to the network via a wired network, in most cases the attacker can't easily arrange to eavesdrop on your network communication. In this case, the easy man-in-the-middle attack no longer applies, and the attacker has to work harder. There are still some other possible attacks, but they are not nearly as easy to mount:
Kaminsky attack. If you have an older DNS client (one that doesn't use source port randomization), the only protection against spoofing is a 16-bit ID field. 16 bits is not enough to defend against random guessing, and Dan Kaminsky showed how to spoof DNS under these conditions. Therefore, if you have an old DNS client that doesn't use source port randomization, you should assume it is easy to spoof DNS.
Fortunately, after Kaminsky discovered his attack, there was a concerted effort to add defenses against his attack (e.g., by randomizing source port IDs), and most modern clients do use source port randomization. Therefore, for modern DNS clients, while Kaminsky's attack is still possible in principle, it would require an awful lot of traffic, so it'd be possible but non-trivial to mount such an attack; unless you are a high-value target, you're probably pretty safe if your DNS client uses source-port randomization. However, there are still some systems that have not deployed protection against the Kaminsky attack, either because they are very old, or because they are embedded systems that haven't been updated, or because they are behind a NAT that destroys the source port randomization -- and those systems remain highly vulnerable.
DNS cache poisoning. In the past, many DNS caches were vulnerable to cache poisoning attacks, where an attacker could fool them into accepting a malicious reply to a DNS query and then cache that malicious reply. Then all subsequent clients who use that DNS cache who query that name would get the incorrect and malicious answer.
These days, modern DNS software has been updated to defend against all known cache poisoning attacks, so cache poisoning attacks should be difficult to mount today. It's possible there might still be a few DNS caches out there running very old software, but I'd expect them to be pretty rare.
Client-side malware. One thing that some client-side malware does is modify your system's configuration so that all DNS queries go to the attacker's DNS servers. Thus, if your machine has been infected with this malware, the attacker gets to spoof DNS easily.
Drive-by pharming. If you connect to the Internet via a consumer/SOHO-grade cable modem, DSL modem, personal wireless access point, or similar device, you may be vulnerable to a nasty attack known as drive-by pharming. In a drive-by pharming attack, the attacker reconfigures your router to change its DNS settings, so that all DNS queries go to the attacker's DNS servers. If the attacker can do this, it thereafter becomes easy for him to spoof DNS.
How can this happen? One way: If you run an open wireless network, an attacker who is physically nearby may be able to hop on your network, connect to your router at a standard address (e.g., http://192.168.0.1), and if you haven't set a strong password on it, guess your password and change its configuration. A little more subtly, even if you have chosen a strong password, if you are logged in, the attacker might still be able to change the configuration, by exploiting the fact that many routers' local web configuration interface does not defend against CSRF attacks.
Worse, in some cases these attacks can be mounted remotely, by an attacker who is on the other side of the world. If you are using a vulnerable router, and if you are currently logged into your browser or if you haven't set a strong password on your router, if you visit a malicious web site, the malicious web site may be able to use Javascript and Java to connect to your router (from the inside interface), guess your password or exploit a CSRF attack, and change its DNS configuration -- invisibly, in a way that you have no idea happened.
Unfortunately, many deployed routers are vulnerable to these attacks, and because there is no good channel for deploying security updates, this fact is not likely to change any time soon. I would rate this attack as medium difficulty; it's probably not too hard to find some users who you can attack in this way, but might be difficult to attack a targeted user (unless you are physically nearby).
Server-side hacking. If the attacker can hack a DNS server that is responsible for example.com, then the attacker can control the responses that are sent when clients ask for the IP address of example.com. This attack is probably relatively difficult for most sites, but the difficulty will vary depending upon the target. One study found that 17% of DNS servers have known vulnerabilities.
This attack is worse than it might first seem, because there is a great deal of transitive trust in the DNS. For instance, the Government of Ukraine's web site depends indirectly upon Dreamhost's DNS servers (kmu.gov.ua's DNS is served by servers at adament.net; adament.net's DNS is served by dreamhost.com), upon Norway's and Sweden's DNS servers (ua's DNS trusts sunet.se, which relies upon nordu.net, which relies upon no), and upon a number of other DNS servers. Therefore, if you can hack any of those DNS servers, you may be able to spoof DNS for the Government of Ukraine's web site. The amount of such trust varies significantly from site to site. One study found that 45% of DNS names are susceptible to hacking, due to indirect dependencies of this sort upon vulnerable DNS servers.
Bottom line. Overall, I'd say that if if you are using an open network where the attacker can eavesdrop on you, then spoofing DNS is trivial -- whereas if you are using some other network where the attacker can't eavesdrop upon you, then spoofing DNS is pretty hard but far from impossible.
Therefore, I think there are good reasons to use solutions like DNSSEC and SSL/TLS.
In a technical sense, DNS is easy to spoof. It (almost always) uses UDP as the transport protocol, which is trivial to spoof compared to TCP. And DNS itself offers no precautions against spoofing, so if the attacker can return their own packet first, they win. Note that DNSSEC is designed to address this issue and a couple of others.
Successful DNS spoofing, then, relies upon network access. An attacker who has access to the network in a way that allows them to see the client's requests, and spoof response packets, can fool the client into going somewhere other than they intended. Given that fact, you can determine how much of a threat it is. For example, a phishing email generally comes from someone without favored network access, and the threat of the two working together is lower as a result. A malicious user on the same subnet, on the other hand, might be able to gain the level of network access required to perform the spoofing, so that's a more likely danger.
DNS is a low level protocol, and some higher level protocols have protections against this sort of spoofing. For example, an attacker might be able to spoof DNS to redirect a user of https://bigbank.com to their own site, but they'll need a valid SSL certificate to avoid warnings, and if the user actually checks the certificate they'll detect the attack. Similarly, if the attacker spoofs with the goal of redirecting a client's SSH connections, they will get alerts that the host key has changed unless the attacker somehow managed to steal the true SSH server's host key. If they were using Telnet, they'd have no such protection...
To the best of my recollection, the majority of publicized compromises related to DNS were due to DNS poisoning of some sort, and generally not to spoofing. Of course, because poisoning is by it's nature much more public, and spoofing better suited to quiet targeted attacks, we can't assume that means spoofing isn't used. I would hazard a guess, however, that if an attacker has the required network access to spoof, they probably have a handful of other attack vectors which may be more attractive than DNS spoofing. Perhaps that's why we're still not using DNSSEC yet.
