Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Perils of DNS at RIPE-52 71

Posted by CmdrTaco from the don't-ping-me-there dept.
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."
This discussion has been archived. No new comments can be posted.

Perils of DNS at RIPE-52 More

Perils of DNS at RIPE-52

Comments Filter:

  • Associated paper with more details. (Score:4, Informative)

    by Anonymous Coward on Wednesday April 26, 2006 @09:12AM (#15204369)
    The associated paper is here [cornell.edu]. 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. (Score:4, Interesting)

      by RedHat Rocky ( 94208 ) on Wednesday April 26, 2006 @09:56AM (#15204677)
      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. (Score:4, Insightful)

        by ??? ( 35971 ) <k&kobly,com> on Wednesday April 26, 2006 @10:13AM (#15204865)
        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.
        • 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).

          • As we point out in the paper, the vulnerabilities all depend on the shape of the dependence graph. You keep pointing out that high fanout improves security. In practice, DNS dependence graphs tend to be long and narrow, with small cuts. An attacker that owns a cut can hijack a domain. The paper has the details on the size of typical graph cuts.
            • 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
            • 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.
      • 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.

    • Note from the author. (Score:5, Informative)

      by Emin.Gun.Sirer ( 970825 ) on Wednesday April 26, 2006 @10:05AM (#15204785)
      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 [cornell.edu] 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 [cornell.edu], a system for monitoring updates on the web [cornell.edu], and a system for avoiding SPAM on P2P filesharing networks [cornell.edu]. Check them out if you are interested in new distributed services for the Internet.

      • I can't claim to be a super DNS guru, but I do know a fair amount. It seems that some of the claims of this research are exaggerated because they don't take DNS glue records into account. Most of the name servers return the IP addresses of the next level name servers, even if they aren't in the domain being looked up (obviously they have to return the IP if the ns is in the domain being looked up). So, for a normal DNS recursive lookup you will never follow most of the graph because of the short circuits t
    • Unfortuntely there seems to be two important errors in the paper leading to results being plainly wrong (uhm, hyped). There are:
      * inability to notice that dns server is visible under many different ips (thats very often the case in Europe, and that leaded to false assumption about average of 100 hosts used blah blah blah)
      * glue records attached to dns reply doesnot increase average of 100 hosts used blah blah

      It's important, but far lesser than stated in paper.

  • More information -- paper (Score:3, Informative)

    by scovetta ( 632629 ) on Wednesday April 26, 2006 @09:14AM (#15204383) Homepage
    The paper Perils of Transitive Trust in the Domain Name System [cornell.edu] (coral cache [nyud.net]) describes quite a bit of this. It's a bit scary.
    • Your sig and your subject go well together...

      Unfortunately, transitive trust is dangerous anywhere. The first example that comes to mind is handing your card over to a retailer to swipe; while it's something that's attempting to be addressed, with chip and pin readers, people equipped in the right way (whether script kiddies in the original example or someone in store with a second or tapped cardswiper (or, presumably next wave, same for chip and pin readers) in mine) have the ability to abuse that trust an

  • BIND false versions (Score:4, Interesting)

    by caluml ( 551744 ) <slashdot@spamgoe ... c a l u m . org> on Wednesday April 26, 2006 @09:17AM (#15204397) Homepage
    "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.)

  • dig is your friend. (Score:4, Interesting)

    by caluml ( 551744 ) <slashdot@spamgoe ... c a l u m . org> on Wednesday April 26, 2006 @09:21AM (#15204425) Homepage
    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?

  • Also , for those outside (and inside) of Europe (Score:4, Informative)

    by tddoog ( 900095 ) on Wednesday April 26, 2006 @09:21AM (#15204430)
    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.

  • Ripe and ARIN (Score:1, Offtopic)

    by ArgoNought ( 970821 )
    ...(for those of you outside Europe, RIPE is the European counterpart to ARIN) Oh good. And ARIN is?
  • The architecture of the legacy DNS greatly helps the attackers. It creates many non-obvious dependencies between names and nameservers, and can enable unexpected nodes to exert great control over remote domains. For example, the resolution of the host www.whitehouse.gov is directly dependent on all the servers that serve the whitehouse.gov domain. There are just seven of these, one of which is a.gov.zoneedit.com. But how does a client figure out the IP address of a.gov.zoneedit.com? For that, it will have t

  • How many lookups to get to the center? (Score:4, Insightful)

    by Intron ( 870560 ) on Wednesday April 26, 2006 @09:37AM (#15204522)
    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?

    • Is it a problem or just redundant systems (good)? (Score:4, Insightful)

      by khasim ( 1285 ) <brandioch.conner@gmail.com> on Wednesday April 26, 2006 @10:18AM (#15204902)
      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.
    • Perhaps this example, involving "www.nasa.gov" [cornell.edu], will make the dependences more clear. It is true that parent servers cache and forward IP addresses, in so called "glue records." But the glue does expire occasionally and the parents need to perform occasional lookups. These are the periods of vulnerability that an attacker would take advantage of to propagate bad bindings.
  • When I was trying to register some nameservers for a reverse delegation, RIPE didn't allow me to put the nameservers in the in-addr.arpa domain. They claimed that would cause a loop. This means that they force every reverse delegation to be glueless, causing the amount of involved nameserver to be (much) greater than needed. (Granted, this was a few years ago, but I'll bet you don't find many registered nameservers in in-addr.arpa even today)

    And (not RIPE related) why the hell is .org served by nameserver o

  • .pl - one of most vulnerable? (Score:3, Informative)

    by kompiluj ( 677438 ) on Wednesday April 26, 2006 @10:08AM (#15204817)
    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.
  • Did anyone else notice that slashdot.org is in the list of vulnerable sites?
    • Did anyone else notice that slashdot.org is in the list of vulnerable sites?


      Don't worry! Anyone stealing the slashdot.org name to redirect users to his own server will surely be slashdotted at once.

  • Someone just needs to want change bad enough. (Score:3, Interesting)

    by I_redwolf ( 51890 ) on Wednesday April 26, 2006 @10:22AM (#15204941) Homepage Journal
    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.
  • Domain hijacking isn't the greatest threat posed by DNS system, it's the system itself.

    Attacker could use DNS to relay virus payload to host, thus entirely bypassing NIDS systems.
    Any command that resolves hostname could be used to exploit this concept.
    It's not commonly used because the limited length of hostnames would require several
    queries to transfer larger payloads.
    But with some time and effort, attacker could hide the transfer almost completely.

    There was an article about this on phrack? around 199x so
  • Their counts seem inflated, as they mark every single root server for a TLD as a "dependent" server, etc. If you have multiple DNS servers for your own domain (e.g., microsoft.com has 5 nameservers), they count each of _those_ as a separate "dependent" server as well.

    It seems to me that it would be more accurate to only count 1 server at each level of the hierarchy as Dependent, and all the peers at that level as Redundant (co-dependent?).

  • The lesson (Score:3, Funny)

    by metamatic ( 202216 ) on Wednesday April 26, 2006 @12:36PM (#15206093) Homepage Journal
    "The lesson: DNS must be managed by professionals..."

    That's why I go with Network Solutions!

  • (for those of you outside Europe, RIPE is the European counterpart to ARIN

    That's nice to know. Then what is ARIN?

    • People who hand out blocks of IP addresses and keep track who has what.

      Known to most of people through situations like whois -h whois.arin.net 11.22.33.44

  • RIPE != RIPE-NCC (Score:3, Informative)

    by majorowl ( 668094 ) on Wednesday April 26, 2006 @12:41PM (#15206140)
    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.

  • DNSSEC, anyone? (Score:1, Interesting)

    by Anonymous Coward
    So what about Secure DNS? Sweden has already converted, so why doesn't the rest of the world follow?

Slashdot Top Deals

"There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.

Close