Perils of DNS at RIPE-52

An anonymous reader wrote in to say that " The RIPE meeting got off to a good start yesterday (for those of you outside Europe, RIPE is the European counterpart to ARIN). Emin Sirer from Cornell presented his study of DNS vulnerabilities. The results are staggering: the average name depends on four dozen nameservers, 30% of domains are vulnerable to domain hijacks by simple script kiddies, 85% of domains are vulnerable to hijacks by attackers that can DoS two hosts. The lesson: DNS must be managed by professionals, and the pros have to pay attention to the DNS delegation graph when they set up name servers."

Comments

Associated paper with more details.

[Anonymous Coward]

The associated paper is here. They surveyed some 600,000 names from Yahoo and DMOZ and found that a large percentage of domains are vulnerable to domain hijacks by script kiddies.

Re:Associated paper with more details.

[RedHat Rocky]

There are a number of assumptions in the paper that are questionable:

1. Nameservers give correct version information. This is not correct, some intentionally mislead.
2. Nameservers of a certain version string all have certain vulnerabilities. This is not correct, there are dependencies on platform/OS. Also see 1.
3. DNS Clients are dumb. What I mean here is that no credit is given to the DNS client for discarding incorrect information. Some clients will bypass certain cache poisoning.

I appreciate what the paper is trying to say. Security vs usability is always a direct tradeoff. In the case of DNS, its biggest strength (massively distributed) is also its biggest security weakness.

Re:Associated paper with more details.

[???]

None of these points attacks the core thesis of the paper, IMHO. The vulnerability stats were rough, and were only used tangentially to the argument. The argument is that in practice, there is a larger (and deeper) trust graph (and thus a larger attack exposure) associated with a given name than would appear to immediate observation. This should raise concern, regardless of the incidence of vulnerable DNS servers.

Re:Associated paper with more details.

[RedHat Rocky]

Reflecting, I also question that having more nameservers is bad.

Having more nameservers in the DNS chain means more of those servers need to be compromised to redirect the same number of requesters. Even better if those nameservers are diverse, so that one exploit wouldn't work on all of them.

Re:Associated paper with more details.

[RedHat Rocky]

I disagree that a larger trust pool is always a bad thing. While the attack exposure is larger, true, there is also more work for an attacker to do for the same payoff.

Meaning, if I as an attacker need to choose between two domains to attack, I would prefer the one that would give the biggest payoff for the least work. More namerservers means the attacker has to do more work for the same number of victims (redirected queries).

Re:Associated paper with more details.

[???]

I read the paper. I am still concerned about a few aspects.

- Little analysis is given to the effect (in practice) of glue records. A footnote mentions that glue is not authoritative, but does not elaborate on how glue is actually used in the chain.
- TCB is a poor metric for assessing the attack profile with respect to a name. You talk in your comment about the vulnerabilities depending on the shape of the graph, and assert "In practice, DNS dependence graphs tend to be long and narrow." (not supported by your published data/analysis) In the paper, you briefly mention a distinction between a "partial hijack" and a "complete hijack," but do not elaborate or provide relevant data. I would suggest that the cardinality of the trust graph does not support your thesis as strongly as an analysis of the depth of the graph would. Certainly, an analysis that examines depths of transitive trust chains (as negatives wrt attack profile) and breadth of delegation (as potentially positives due to increased redundancy) would be far more relevant to the thesis of your paper. I would love to see metrics such as minimum depth, maximum depth and average depth calculated and analyzed (and would love to see the raw data you have available - drop me an email).

N.B. High fanout does not necessarily improve security. It only does so if the added chains are more secure than the existing chains...

Re:Associated paper with more details.

[RedHat Rocky]

So the point would be to eliminate cuts, yes? I'm assuming the definition of "cut" is a single point of failure in the DNS dependency tree. To eliminate cuts, introduce more nameserver paths. But wait, that means a larger TCB!

From the talk: "It is a well-accepted axiom of computer security that a small trusted computing base is highly desirable: it is easier to secure, audit and manage."

The followup would be that a small TCB is also at more risk for failure.

Security, resilience or usability, pick two.

More information -- paper

[scovetta]

The paper Perils of Transitive Trust in the Domain Name System (coral cache) describes quite a bit of this. It's a bit scary.

BIND false versions

[caluml]

"The fbi.gov domain is served by two machines called dns.sprintip.com and dns2.sprintip.com. A client trying to resolve www.fbi.gov will first have to get to sprintip.com to find the FBI nameservers. The sprintip.com domain is in turn served by three machines named reston-ns[123].telemail.net. Of these machines, reston-ns2.telemail.net is running an old nameserver (BIND8.2.2-p5), with nine different known exploits against it (namely, tsig, libbind, negcache, sigrec, DoS_multi, srv, zxfr, infoleak and sigdiv0 exploits). Having compromised reston-ns2 using a standard crack tool available on the web, an attacker can divert a query for dns.sprintip.com to a malicious nameserver, which can then divert the subsequent query for www.fbi.gov to any other address, hijacking the FBI's web site and services." I bet that's not its real version. I configure my DNS servers to return funny values. (Sometimes. If I remember. And can be bothered.)

Re:BIND false versions

[cheese-cube]

Oh touché RedHat Rocky, touché.

dig is your friend.

[caluml]

When I say dig, I don't mean Digg.

dig +short +trace www.fbi.gov

... is your friend. Running that though, I get:

;; reply from unexpected source: 69.72.142.35#53, expected 205.247.218.251#53
;; Warning: ID mismatch: expected ID 14394, got 3338
CNAME fbi.edgesuite.net. from server ns4.vericenter.com in 601 ms.

Wonder what's going on there? Someone already trying it?

Re:dig is your friend.

[mmkkbb]

EdgeSuite is an Akamai product. If the FBI is using Akamai then that's not totally surprising, and they do.

Also , for those outside (and inside) of Europe

[tddoog]

ARIN (from the website)

Established in December 1997, the American Registry for Internet Numbers (ARIN) is a Regional Internet Registry (RIR) incorporated in the Commonwealth of Virginia, USA. ARIN is one of five (5) RIRs. Like the other RIRs, ARIN:

        * Provides services related to the technical coordination and management of Internet number resources in its respective service region. The ARIN service region includes Canada, the United States, and several islands in the Caribbean Sea and North Atlantic Ocean;
        * Facilitates the development of policy decisions made by its members and the stakeholders in its region;
        * Is a nonprofit, membership organization;
        * Is governed by an executive board elected by its membership.

Re:This also just in

[caluml]

No, you nutter. What it's saying is, is that even if you configured your DNS correctly, all of the parent DNS servers used in the process of resolving your domain names have to be correctly configured too. Imagine you own foo.com. Your DNS server is OK, but if the .com servers aren't, I can just make the .com servers pass requests for foo.com to my DNS servers, and then return whatever values I want. It's all a big pyramid.

How many lookups to get to the center?

[Intron]

To look up www.futurequest.net (for example) requires:

Ask one of the 13 root servers who is nameserver for .net
Get back (A-M).GTLD-SERVERS.NET, they thoughtfully include IPs
Now ask a GTLD who has futurequest.net
Get back (ns1-ns3).futurequest.net, includes IPs
Now ask ns1 who www is
It provides IP for www is 69.5.6.116

So I guess there were 30 IP addresses involved, but I don't see the arcane resolution problems that this paper talked about. Maybe .edu domains are a little more haphazard?

Note from the author.

[Emin.Gun.Sirer]

I'm the speaker that the article is talking about. I head a research group at Cornell looking at building more resilient Internet infrastructure. Let me say a few words about this study and our recent IMC paper:

This survey was a lot of fun. It's sort of like a "how to 0wn the Internet via DNS" survey. In fact, that was the subtitle of my talk and was the most fun academic paper I ever wrote. It's all based on public information, by the way. The findings were quite surprising, at least to us.

First, the average DNS name depends on a large number of nameservers. Not just the two or three nameservers that you designate when you register the name, but also the nameservers those servers are served by, and so on. This set includes a few dozen hosts for the average .COM domain. If you are in the Ukraine, Malaysia, Poland, or Italy, this set includes more than 400 hosts! In contrast, Japan (.jp) is run very well, and names in .jp depend on very few hosts.

Second, some names are incredibly vulnerable. The most vulnerable name in our survey, the Roman Catholic Church web site in the Ukraine, depends on servers in Berkeley, NYU, UCLA, Russia, Poland, Sweden, Norway, Germany, Austria, France , England, Canada, Israel, and Australia. It's possible to take over that Ukrainian website (and announce a new pope, perhaps?) by compromising a host in Monash, Australia. DNS makes a small world after all.

Typically, you can find some compromised hosts in the dependence graph, DoS the non-vulnerable hosts for a very short time when DNS glue is about to expire, and poison caches. Repeat and rinse until you have hijacked the name of your choice.

Finally, some nameservers are very valuable, they control a large percentage of names. Some of these valuable nameservers are in educational institutions, which have no fiduciary responsibility to the names they serve. In fact, folks at NYU may not be aware that they can control the entire namespace for Baltic countries under the right circumstances.

Interestingly, the FBI.GOV site was vulnerable. We reported this to the DHS and someone upgraded the nameserver involved. We suspect the vulnerability we found was a real one, though we did not attempt to take advantage of it so we can't tell for sure.

Our website has an active webserver where you can type in your favorite sitename, see its dependencies and vulnerabilities. The data is a snapshot we took when we performed this study; do not be surprised if it does not reflect changes you made in the last few months.

The takeaway from this study is that the conventional wisdom about DNS servers, which says "the more DNS servers you have, the merrier as you increase fault tolerance" is wrong. You increase fault tolerance at the cost of increasing your trusted computing base. If you don't pay attention, someone from Monash Australia can hijack your site, and you might not even notice.

My research group generally looks at how to build more resilient infrastructure services. We built a safety net for DNS, a system for monitoring updates on the web, and a system for avoiding SPAM on P2P filesharing networks. Check them out if you are interested in new distributed services for the Internet.

.pl - one of most vulnerable?

[kompiluj]

Quote from the article The names in the top level domains .UA, .BY, .AL, .SM, .MT, .MY, .VA, .PL, .IT, in that order, are on average the most vulnerable. Most country code TLDs average more than 100 dependencies per name..
The part which I have emphasized gives us a hint: in Poland there is a tradition of unreliable telecommunications network. The biggest operator is a post-communistic ineffective giant delivering low quality of service. Therefore most businesses have developed a workaround - redundancy. Many registrars (DNS operators) are also Tier-2 ISPs and have links to most polish Tier-1 ISPs. When in reality they have 1 DNS server it can show up as many IP addresses, one for every Tier-1 ISP. And this is not taken into account by this survey, as far as I have gathered from a quick glance.

Is it a problem or just redundant systems (good)?

[khasim]

I was wondering that when I was reading the article.

If you (correctly) configure your systems, you'll have 3 different DNS boxes on 3 different networks so any single problem won't take all of them out.

Okay, that does mean that you've just increased your attack visibility by 3x, but ... so what?

And yes, if an attacker can get control of 1 of those boxes and DDoS the other 2 then he can redirect those queries to whatever box he wants to.

Someone just needs to want change bad enough.

[I_redwolf]

The vulnerabilties of DNS have been expounded on forever, people already know this. The survey then goes on to point out how trust is an issue and for all that the conclusion of this survey is that cryptographic name to address bindings are key. That's only part of the solution.

The bigger problem is clearly TRUST and can be alleviated if the DNS system was simply reimplemented. Easier said that done, yes, but a p2p with a trust metric system applied isn't overtly complicated and would scale. For instance, lets say you want example.com. It would be delegated when you register, propogated by it's trust amongst the root servers and the two or more namservers you've added when you've signed up. You then setup the trust system algo to prevent large attacks or changes.

The benefits are numerous, the roots are still the roots but are less taxed; their main purpose? The ultimate in trust so that subsequent nameservers always follow the trust metric and should a rogue amount decide to disobey trust metric they are flagged and dropped.

The only problem is actually doing it and setting up some sort of migration path.

Re:Someone just needs to want change bad enough.

[Anonymous Coward]

The bigger problem is clearly TRUST and can be alleviated if the DNS system was simply reimplemented. Easier said that done, yes, but a p2p with a trust metric system applied isn't overtly complicated and would scale... The only problem is actually doing it and setting up some sort of migration path.

Interestingly, the same research group cited in the story has built precisely such a system, a P2P replacement for DNS. It even has a migration path from the current DNS, supports the legacy namespace, and works well enough to answer my DNS queries even as we speak.

Re:This also just in

[TheViewFromTheGround]

What's next? A hysterical report about how (gasp!) a root server could be compromised and we'd all be hosed? Duh! Talk about stating the obvious.

It really isn't the same at all. You sort of hope/expect a root server to be very closely monitoring and controlled by a professional team, but once you start adding multiple links in the chain of varying security and on top of that throw in broken DNS resolvers (like the ones SBC/AT&T use that only cache one nameserver for a given domain... even if the nameservice provider has redundancy, you won't benefit from it if the cached nameserver gets hosed).

DNS is a system in which each failure of any individual in the pyramid has the same ability to hose access to your site, but differential security and quality of service. That's not ideal at all.

To back this thesis up, there have been several major DNS outages (joker.com and Worldnic both bit me in the ass, and there were reports on SANS of others), some due to malicious activity, some due to other problems, in the past few months that have made life insane for tens of thousands if not hundreds of thousands of site operators. The system is way too fragile, IMHO.

The lesson

[metamatic]

"The lesson: DNS must be managed by professionals..."

That's why I go with Network Solutions!

Re:Ripe and ARIN

[raddan]

Would you like a definition for "DNS" while we're at it? How about "computer"?

RIPE != RIPE-NCC

[majorowl]

Actually RIPE is more analogous to NANOG (the North American Network Operator's Group). It is RIPE-NCC (the RIPE Network Coordination Centre) that is the Regional Internet Registry (RIR) for Europe (and parts of the Middle East and Central Asia). RIR's are non-profit member organizations that oversee IP address and ASN registration and allocation.