By Peter Tippett and Russ Cooper

There is a huge amount of angst, discussion, testing and endless worry about the “new DNS vulnerability” whose existence was published a few weeks ago concurrent with a coordinated patch release. Its dastardly “vulnerability” or “threat scenario” will be disclosed in full in early August. The worry is that, once fully disclosed, the unprepared world will be at risk—or at least large portions will be—and whole new categories of exploit will suddenly be possible…or something like that.

Let’s get out a few facts, and then discuss some hypothetical attacks. We’ll assume the extremes and see just how a very old and well-understood vulnerability might behave differently if, for example, a simple cache poisoning attack tool or technique were released. [For a primer on DNS look here. For a primer on DNS Cache Poisoning look here.]

Facts:

First, we are unaware of any evidence of any new attacks in this realm. DNS cache poisoning is a very old attack technique. So far there is discussion and angst, but no new attack activity.

Second, the vulnerability/threat has nothing to do with the “authoritative” DNS servers, nor the high-level DNS servers on the backbone of the major ISPs. A cache poisoning attack would be directed at the BIND, Microsoft, and other DNS servers scattered among hundreds of thousands of enterprises, hosting centers, and among the public-facing consumer ISPs. It is these DNS servers which would, if successfully attacked, direct users to criminally-chosen IP addresses instead of legitimate IP addresses resulting in users going to a fraudulent site where malfeasance may occur.

Third, the tools in circulation to tell “good” from “poor” DNS software work largely by testing some notion of the randomization of the DNS implementation. This randomization, if significantly random, would tend to protect that DNS from the hypothetical attacks. Having looked at the results of such tools against many DNS systems, and knowing the actual story, it is clear that a great many DNS systems (especially those at ISPs) employ many other countermeasures which are not evaluated by these tools. Therefore these current tools very often suggest some DNS systems are “poor” (vulnerable) when in fact they are robustly protected.

Some Scenarios

BIND and other DNS systems are everywhere. They are treated and protected like the infrastructure they are, but in some cases they are among the least updated software on the planet. Old versions of BIND are also everywhere. Cache poisoning in “the old days” required many tens of thousands of attempts, which our world has learned to look for and protect against.

But what if the criminals have a quick and easy way to poison a cache? We must appreciate that for us to believe that our risk has been significantly altered, one of two things must be true. Either the attacks work instantly against many victims (ala SQL Slammer or MSBlaster), or they can continue unnoticed for a long enough period of time for users to become victims (ala phishing attacks against banking institution customers). Wouldn’t it be horrible if…?

Scenario #1: Your company DNS is poisoned

Suppose your own company’s DNS is successfully attacked so that users who try to go to a legitimate Web site wind up instead being redirected to www.evilhacker.com (which is probably hosted on a compromised Web server somewhere).

Of course the user will wind up in the wrong place. The criminal would need to emulate that place or the user would go back to their home page having wasted a few minutes.

Q: But couldn’t the criminal attack and “own” the user’s browser?

A: Only if that browser was vulnerable anyway. Or, are we thinking that the criminal not only poisons your company DNS, but also has a never-before-exploited attack handy against the user’s browser. For a criminal to have and use two completely new attack scenarios exploiting two entirely different new vulnerabilities is very unlikely.

So either the browser is resistant, or the AV or IDS (remember this is a company here) or similar systems will resist this. But even if all of these things fail, the criminal still only has ownership of PCs in your company which have visited the same site.

What is the criminal going to do from there? If a backdoor or Trojan is installed, the PC would need to communicate outbound—this is unlikely in many/most corporations and is even more likely to be caught, noticed, or prevented with firewalls, proxies, etc. already in place.

But even if all of these things fail, the criminal still has to do more to get to the crown jewels: He needs to install a sniffer, a scanner, a back-door, or other undetected malicious code and then successfully attack other systems inside the company. And still other countermeasures would need to fail. All of these things are possible, and our recent Data Breach Investigations Report shows that sequences like this actually happen sometimes (about 4% of successful major attacks in that study), but they are not significantly easier with this new DNS attack than before.

This scenario is almost equally true of a “directed attack” against your company by competitive interests.

Scenario #2: Your home network ISP’s DNS is poisoned

Suppose the criminal poisons the DNS of a regional home ISP and redirects traffic going to www.AnyBank.com instead to www.evilhacker.com.

Q: Couldn’t the criminal snooker the user into typing in personally identifying information to be exploited later?

A: Only if that user would have done so anyway. If the new site has a certificate, it will fail and the user will get certificate errors in the browser. Many users ignore such errors, but others should pay enough attention to them to allow the problem to be discovered, and the ISP will likely learn of the problem and fix it.

If there is no certificate, more will not notice, but some will, and the problem will be discovered and fixed relatively quickly. If the criminal presents a login screen for www.AnyBank.com, then tries to redirect the user to the real bank after taking the login credentials, then the bank will notice its users coming from a single address (remember, users can’t easily get there from their own PC—the DNS is poisoned). Yes, a few users will have been phished, but no more so, and probably less so, than by other phishing methods.

Q: Suppose the criminal redirects traffic originally destined for www.ReallyBigSearchEngine.com to www.evilhacker.com?

A: Then whatever site www.evilhacker.com is hosted on will likely be DDoS’d out of existence by a huge swell in traffic that would have normally gone to www.ReallyBigSearchEngine.com. The hosting computer would likely fall over due to a lack of capacity, and the users who were redirected wouldn’t be able to use their search engine.

The ISP hosting the poisoned DNS would probably get support calls from customers unable to get to their search engine, causing them to jump on the issue and clean up their cache. It would make the press, but more likely that hardly anyone would actually have been harmed.

Scenario #3: Bots are used to poison and re-poison numerous DNS caches

A criminal bot-herder could probably have their bots working pretty hard to brainwash various caches, significantly increasing the scope of a poisoning attack. However, they would run into the same problem mentioned in scenario #2: They could easily DDoS their criminally-controlled sites out of existence.

But let’s assume they use compromised hosts with really fat pipes. By having many systems spread across many different DNS server realms, many of the bot-controlled systems would set off alerts at many sites. Those sites would investigate how and determine which bots are doing what, and defenses would come into existence. Furthermore, bot-herders already have control of very large number of victim systems. The use of an additional DNS poisoning step would need to either get the bot-herder a larger army of victims, or provide them with more of the actual value from those attacks performed by his victims. It is not easy to see what additional value cache poisoning would yield.

Q: Couldn’t criminals perform man-in-the-middle (MITM) attacks?

A: Sure, but consider the volume and the processing power they’d require. Criminals typically don’t care whether their compromised hosts (the ones they’re directing victims to) fail to serve victims. If such failures occurred during a MITM attack, people would notice. In addition, any session that requires encryption, such as during system login, or VPN access to a company, or work at bank or commerce site would fail if the man in the middle needed to produce the appropriate server certificate, or would be very noticeable if all users were coming from the same IP address (remember the actual user’s upstream cache is poisoned, so their machine would not be the one seen to be visiting the big commerce site or login site).

Q: Couldn’t criminals poison entries for a very short period of time, allowing them to revert to valid entries periodically, thereby going largely unnoticed?

A: This is probably one of the worst-case scenarios. Such an attack would likely go unnoticed, or even if it were noticed, may not actually be a problem when it’s investigated. Imagine you were directed to www.evilhacker.com at 10:00am, realized it was evil, and reported it at 10:02am. If the time-to-live (TTL) on the poisoned record was 1 minute, by the time the support technician looked at the cache at 10:30am, the poisoned record would have been replaced by a valid one. So the tech doesn’t understand why you’re having a problem.

This scenario gets worse due to Browser DNS Pinning. If you had received the poisoned record from your DNS at 10:00am, even though it was corrected at 10:02am, it is still incorrect in your browser for as long as you don’t close your browser. So the criminal might poison the DNS for short periods of time, but actually keep many end user systems poisoned for hours if not days. Anyone checking the DNS would see it looking fine, unless they checked during the very short time it was poisoned.

This notion of Browser DNS Pinning is browser-specific. It would behave differently among different browsers and even for different patch levels of the same browser. We may very well see a call for frequent shutdowns of browsers or for specific configuration changes in order to avoid this problem.

Scenario #4: A criminal who has purchased a hosted site in MajorHosting.com queries a criminally-controlled DNS to poison the DNS of MajorHosting.com

This is perhaps the other worst-case scenario. If MajorHosting.com does not notice the attempts by one of its own servers, it may very well succeed.

Q: If criminals poisoned the record for the internal payment processing server, couldn’t they steal lots of credit card information?

A: Unlikely. First, payment processing client systems within MajorHosting.com are likely doing encrypted transactions. Unless the criminal is able to establish an encrypted session with the potential victims, they’re unlikely to send anything and instead simply view the payment processing system as down. When that happens, techs at MajorHosting.com should realize what’s happened.

Second, assuming the sessions could be established, the criminal would have to mimic the payment processing system precisely in order to convince the victims their transactions are being processed. Otherwise, again they’ll see the system as broken and report it.

Scenario #5: A criminal Insider poisons his own company’s DNS cache

Imagine that a criminal insider wants to MITM logins to an internal server, or just try and catch the credentials of a particular user. So the criminal poisons the record for ActiveDirectoryServer.myCompany.Internal and has it point back to his own machine (also inside the company).

All attempts to interact with the company’s Active Directory (AD) Server are now going through the criminal’s system. He proxies everything on to the AD server until he gets to the credentials he wants (which could be machine or user credentials).

Windows has ways to prevent MITM, but most people don’t use it. Furthermore our study data has led us to believe that the majority of insider attacks are from IT administrators who typically already have more access than they need to get valid sensitive information without this additional DNS work. Finally, insiders almost never use hacking-style attacks when they perform computer and information crime. Mostly this is because most insiders have far easier ways to accomplish similar goals, and because they are much more likely to get caught and prosecuted.

Summary:

At the end of the day, there are new attack scenarios that may be attractive for whatever reason, but they are a far cry from the earth-shattering tales being suggested by many in the press today.

None of this discussion is to suggest that a new and simple DNS-related attack should be ignored. Indeed, we recommend that every administrator of DNS systems both in companies and at hosting providers and other service providers should: 1) have ready standby systems both for testing and for at least cold-swappable implementation, 2) that appropriate software upgrades be applied after testing and 4) that other countermeasures both at the DNS level and at other levels suggested by this discussion be deployed. Although patching is important, administrators should certainly use many of the numerous other configurations, authentication, cache sizing, and other countermeasures available both within their DNS systems and elsewhere.

Of course, we have considered a number of other scenarios which we have not published here. None represent dire consequences for the Internet. All have some or many of the same limitations described above. Some are more and some are less onerous, but by and large, do not get much more effective when cache poisoning is involved.

Tags: Cache Poisoning, Computer Attacks, DNS, DNS Cache Poisoning, Information Security, InfoSec, risk, Vulnerabilities

This entry was posted on Friday, July 25th, 2008 at 7:21 pm and is filed under Analysis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.