Slashdot Mirror


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."

6 of 71 comments (clear)

  1. BIND false versions by caluml · · Score: 3, Interesting

    "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.)

  2. dig is your friend. by caluml · · Score: 3, Interesting
    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?
  3. Re:Associated paper with more details. by RedHat+Rocky · · Score: 3, Interesting

    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.

    --
    Anything is possible given time and money.
  4. Someone just needs to want change bad enough. by I_redwolf · · Score: 2, Interesting

    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.

  5. Re:This also just in by TheViewFromTheGround · · Score: 2, Interesting
    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.

    --
    Online citizen journalism from the inner city: The View From The Ground
  6. DNSSEC, anyone? by Anonymous Coward · · Score: 1, Interesting

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