The Impact of Dan’s DNS Debacle on Internet Risk

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:

1. An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
3. The attack is DNS server-specific. Only users on the same DNS server are affected.
4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during  times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.

Comments

[Steve Pinkham]

Vulnerability disclosure in this case is different then normal.
This is a design level flaw, and requires design level fixes. This is less like your average buffer overflow, and more like the disclosure of the existence of the first buffer overflow. The fix is not like a patch to one buffer overflow, but more like the addition of ASLR and NX protection.
It's a sad thing that many parts of our critical infrastructure are still in such a state that new attack classes are still being discovered and exploited, but the exploits are valuable in helping us to design better protections into the infrastructure. For example, a DNS hardening RFC that was in progress is now being rewritten because some of its assumptions were proven incorrect byt his new class of attack.
Anyone who knows about DNS knows that the state of the art is always right on the edge of brokenness, and that the major players are patching just enough to fix todays vulnerability. DJB was one of the few exceptions, and he designed all the strength he could think of into his implementation. His implemention had the fix that is being rolled out today, many years ago. To me, that's the real story here, that we should be spending our effort both building things to be as secure as we can reasonably be, and researching new attack classes and defenses that can be applied in a generic manner rather then chasing the latest buffer overflow or XSS bug. Research in static analysis, strong protections in frameworks and libraries available to everyone, and strong well designed protocols that are reusable like SSL and DNSSEC are the things that really push security forward. Vulnerability disclosure is just a useful tool in pushing the those goals along.

Here's my question for you. DNS source port randomization has always been a good idea, has been well know and even been implemented in some software for many years now.
Why is it that people will only roll it out after a vulnerability disclosure and media circus?
In a perfect world, if the industry as a whole really cared about security and was proactively strengthening their software development life cycle and deploying the best defenses we knew of, then vulnerability disclosure might be a bad thing. We don't live in that world, we live in a world where the cheapest thing that just barely works gets thrown on the net.
I would like to live in that world, and spend my time and energy pushing for systemic fixes as much as possible. Until the world is perfect and we sit around making daisy chains, we need vulnerability disclosure.

A side note is that people who care could have protected themselves on day 1 of vulnerability disclosure, as I did. Larger deployments of course take more testing, but 2-3 weeks is not an unreasonable time period.
We as an industry can only help those who care. Is there collateral damage? Yes. Would there be more or less damage without vulnerability disclosure, if security was perpetually at the state it was 10 years ago, or even at a standstill of where we are today? Where should we freeze the research clock?
Unfortunately in most areas of life, you must be running to stand still, and security is no different. If you don't care, you will get run over. We can only help those who care. It's an imperfect universe.

[Michael La Barge]

Although I see Peter’s point’s very clearly, I tend to agree with Steve in that vulnerabilities do need to be exposed. I feel this is especially true when Steve says:

“Why is it that people will only roll it out after a vulnerability disclosure and media circus?"

This is so true in so many Information security, risk and compliance related areas and life in general for that matter. It seems that the squeaky wheel really does get the oil, even more so when the squeak airs live on CNN.

In the PCI Compliance space, we often see what I like to call “Breach Begets Burden”. Meaning that in many cases, vulnerabilities known to exist are not dealt with until after a data breach occurs. Sadly, it is only after the breach, extensive media coverage and usually a change of Management that security related vulnerabilities are addressed in a more serious manner.

Peter is also absolutely correct in his metric of an increased likelihood of attack. If we see a surge to 50 million DNS attacks, we will certainly be hearing more about it. In the meantime, I will have fun watching the U.S Patent and Trade Office to see if this invention gets a filing number.

[Pete Lindstrom]

@Steve - what a load of pretentious baloney.

@Michael - there is another situation (other than vulnerability disclosure) where a fix would be quickly rolled out. Can you guess what it is?