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

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

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