Slashdot Mirror

← Back to Stories (view on slashdot.org)

What Could You Do With a Bogus Root Name Server?

Posted by Soulskill on from the root-root-root-for-the-home-team dept.

Barlaam notes a post from the Renesys Blog which follows up on news they discussed a couple weeks ago about the 'identity theft' of a root name server. To emphasize the issue of safeguarding such a system, they've now posted an explanation of exactly how the situation could be exploited. "It shouldn't be too hard to see that you could end up answering every DNS query from an organization that came to you for an updated list of root name servers. Every one. And you might end up doing this for a very long time, especially if your answers were largely correct. An attack like this would have no resemblance to the YouTube hijack, where the entire planet gets a blank page and it's immediately apparent that something isn't right. Obvious events like this will continue to occur, and we'll continue to resolve them relatively quickly. But as this incident demonstrates, DNS hijacks are far less obvious and potentially far more harmful."

38 of 120 comments (clear)

  1. Its simple... by Indes · · Score: 5, Funny

    .. do what we do every night.. try to take over the world!!

    (Seriously, Imagine borrowing every bank's front page in North America .... You could be cashing in big time..... )

    1. Re:Its simple... by Anonymous Coward · · Score: 5, Funny

      I would reroute all of 4chan's traffic to fbi.gov

  2. Hmmm... by cp.tar · · Score: 2, Informative

    ... so, you answer nearly all of them correctly.
    Except for the precious few, which, say, redirect you to almost exact copies of pages which take your credit card data.

    Or did I get it wrong?

    --
    Ignore this signature. By order.
    1. Re:Hmmm... by tomhudson · · Score: 5, Funny

      You could send all Obama's web traffic to Clinton's web site ... oops, already been done!

  3. easy by circletimessquare · · Score: 5, Funny

    i would redirect http://slashdot.org/ to http:///..org

    yeah how funny is it now that the joke is on the other foot biatches!

    --
    intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
  4. I've heard of this new technology... by ZeroPly · · Score: 3, Interesting

    ... whereby you can actually "sign" digital data so that it's clear where it came from. If somehow they could incorporate that into this whole "DNS" system, maybe it would fix the problem?

    --
    Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
    1. Re:I've heard of this new technology... by imipak · · Score: 4, Informative

      I think the OP's referring to TSIG and it's variants.

    2. Re:I've heard of this new technology... by klapaucjusz · · Score: 4, Interesting

      DNSSEC has gone through three (3) mutually incompatible specifications. The DNSSEC people are claiming that the last revision really really works, honest, gov, and that all that remains to be done is deploying it.

      But they don't appear to be deploying it on their own servers.

    3. Re:I've heard of this new technology... by klapaucjusz · · Score: 4, Informative

      But they don't appear to be deploying it on their own servers.

      I've just checked -- and the ISC do sign their zone. Sorry for the mis-information.

    4. Re:I've heard of this new technology... by Anonymous Coward · · Score: 4, Insightful

      Digitally signing every DNS request? Good luck handling the computational load :)

      You don't need to sign the requests, you need to sign the replies. And you only need to compute the signing once, and store the signed value.

    5. Re:I've heard of this new technology... by mpeg4codec · · Score: 2, Informative

      DNSSEC in its current state would not prevent any of the attacks mentioned in the article. The root currently does not sign its zone, and as such there is no way to trace a secure delegation to a non-root zone.

      The entire security of DNS as provided by DNSSEC is predicated on the ability to trace a secure delegation. The general theory of operation is that you'd preconfigure your resolver with cryptographic hashes of the root's public DNSKEY records. Then every time you wanted to do a secure lookup, you'd begin at the root, first asking for its DNSKEYs (assuming you didn't have them cached) and then verifying those using your preconfigured hashes. It would then give you the records you asked for, likely the nameservers and DS records for the next level of the hierarchy. That zone's nameservers would then give you their DNSKEYs, which you could verify with the DS records from the root, and you continue the process of DS + NS followed by DNSKEY verification until you're in the zone you're looking for.

      Until the root is signed and until we have resolvers that both support DNSSEC and have been pre-configured with those key hashes, DNSSEC doesn't do us much good. Various research projects have been formed around the notion that the root will never be signed but that it should still be possible to configure a secure system. One of the most promising is a perspectives-based approach, the theory being that a worldwide monitoring system would be harder to spoof, so use this information as a sort of key repository for the apexes of the islands of security. You can trace a secure delegation from any of these zones down to a sub zone, but the weak point of your system is still the fact that you have to trust someone somewhere, and the only real trustworthy place is the root itself. It's something of a hack on top of an academic system that has limited utility in practical applications.

  5. Simple recipe by canuck57 · · Score: 5, Insightful

    If you have lost DNS, game is over, you lose. A recipe if your system hits a compromised root server.

    • You open up email to read todays email. You PC looks up pop3.yourisp.com.
    • DNS returns the IP of evil PC to your PC which will connect to it.
    • Next, evil PC will emulate your login, IP address and record the password. Could even be a /. password.
    • Evil pc now has the info needed to read/retrieve your email.

    Better yet, people often use similar IDs and passwords into other systems. Evil hackers can often use the email to figure out which banks, credit, stock brokers and on line e-tailers you use. Maybe change the home address of your Amazon account and order stuff, if the e-tailor isn't right on top of it.

    Root servers need to be secure, end of story.

    I should note the above method would also work with SSL, be creative, it only has to be a legitimate cert with a root chain.

    1. Re:Simple recipe by Joe+The+Dragon · · Score: 3, Insightful

      ISP can make so that pop3 only works from inside of there own network and force you to have a differnt web mail password not use the same login in system for web mail and pop3 mail.

    2. Re:Simple recipe by imipak · · Score: 4, Insightful
      Oh good god, that's just the tip of the iceberg. More likely would be to MitM some large corps' Outlook Web Access or other places where domain credentials are exposed (VPNs and the like.) Wait until you've got a domain admin's password. You now own that entire corp. Now rinse and repeat for government bodies. How hard do you think it would be for the proverbial well-motivated and resourced attacker to trigger off a war in such circumstances?

      Think about it.

    3. Re:Simple recipe by Vellmont · · Score: 4, Informative


      If you have lost DNS, game is over, you lose. A recipe if your system hits a compromised root server.

      Unless you happen to have SSL enabled pop or imap.

      A (revised) recipe for an SSL enabled mail host:
              * You open up email to read todays email. You PC looks up pop3.yourisp.com.
              * DNS returns the IP of evil PC to your PC which will connect to it.
              * Evil PC returns a forged SSL certfificate claiming to be pop3.yourisp.com
              * Your email client brings up an error message saying there's something wrong with this certificate (self signed, etc)
              * You hopefully get suspicious, (this never having happened before), and don't click through.
              * Attack fails.

      If you don't get suspicious, and just click OK, you're right. But the situation isn't quite as dire as you make it out to be. I'd never connect to a non-secure host for something like email.

      --
      AccountKiller
    4. Re:Simple recipe by MushMouth · · Score: 4, Informative

      Amazon makes you re-enter the complete credit card number if you ship to a new address.

    5. Re:Simple recipe by kvezach · · Score: 2, Informative

      No, because without a password, most password authenticated key exchange algorithm have the same security properties as Diffie-Hellman. In other words, even if you knew the password, you couldn't snoop the connection passively. The only way to thwart it is by an active attack, but for that you need the password, otherwise the two parties' keys won't match.

      See SPEKE, for instance, which is pretty much a Diffie-Hellman key exchange with the (fixed) generator constant replaced by a hash of the password. Snooping SPEKE only gives the adversary g^a mod p and g^b mod p (as well as the combinations as in ordinary DH), where a and b are secret and p is known. That does no good in finding g (the hash of the password) unless the adversary can break the discrete logarithm problem, in which case you've got bigger problems on your hands.

    6. Re:Simple recipe by maxume · · Score: 2, Funny

      Chanting is clearly the network noise that p2p peers make simply letting other nodes know that they are alive and well (rather than traffic from transferring data or handling real business).

      --
      Nerd rage is the funniest rage.
    7. Re:Simple recipe by grcumb · · Score: 2, Informative

      Which email client brigns up an error message for a self-signed POP3 server certificate?

      Mail.app and Thunderbird, for two.

      Mail's error message actually characterises a self-signed cert with language to the effect of, "Couldn't connect to the server because of an untrustworthy certificate." When this was reported to me by a non-technical user, they repeated only the first two words: Couldn't connect.

      That's how things should be.

      I'm hoping that Firefox's improved handling of self-signed certificates gets copied over into Thunderbird's UI as well.

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
    8. Re:Simple recipe by cjb658 · · Score: 2, Funny

      Amazon makes you re-enter the complete credit card number if you ship to a new address. What a horrible inconvenience! You should be able to buy it with one click!
    9. Re:Simple recipe by darthflo · · Score: 2, Informative

      I can confirm Outlook 2003, 2007 and any remotely recent version of The Bat!

  6. break everything by imipak · · Score: 3, Insightful
    Then sit back cackling with glee whilst civilisation falls apart?

    Seriously, in the last decade the premise that the Net is always there has become a silent assumption underlying a lot of critical systems. No I'm not talking about nuclear power stations being online, I'm talking about basic logistics chain outages that mean there's no-one there to run the power station, because they've no fuel for their car, because the petrol tanker driver is off scavaging food for his kids. There are a number of scenarios that could knock out the net (or at least cause widespread depeering, so you'd be stuck on your provider's network and unable to get traffic to/from anywhere else); it would be... well, a bit too interesting for my liking to see how things would go with, say, a seven day outage. Actually a 7 day outage might be just enough to wake people up to the importance of patching your infrastructure, having a heterogenous mix of code for all critical functions, oh and and enforcing BGP security.

    1. Re:break everything by milsoRgen · · Score: 4, Interesting

      Actually a 7 day outage might be just enough to wake people up to the importance of patching your infrastructure That and I'm afraid it would awaken certain governments with the sudden realization now is the chance to install a large scale surveillance infrastructure (or something just as evil) all in the name of fighting the terrorists that caused the disturbance. Oh and I'm sure there would be provisions added to enforce copyright while they're at it.
      --
      I'm sick of following my dreams. I'm just going to ask where they're goin' and hook up with 'em later.
    2. Re:break everything by ColdWetDog · · Score: 4, Interesting

      That and I'm afraid it would awaken certain governments with the sudden realization now is the chance to install a large scale surveillance infrastructure (or something just as evil) all in the name of fighting the terrorists that caused the disturbance. Oh and I'm sure there would be provisions added to enforce copyright while they're at it.

      Exactly. If you think the problem is bad now, wait until we've fixed it. (Arthur Kasspe). This should be the motto engraved on every Government departmental seal.

      --
      Faster! Faster! Faster would be better!
    3. Re:break everything by Anonymous Coward · · Score: 2, Funny

      Better, we can go on a strike and then shut down the Internet. Then, when governments of the world come to us asking for us to repair whatever happened, we say: "ok, we can do that, but before we do we need, 10 million dollars, 3 bikini supermodels and a fast sport car of our choice, for each one of us.
      That would be sweet...
      *GO BACK TO THE BASEMENT, JOHNNY*
      *OK MOM! - Oh God, can't even dream in peace anymore...*

  7. flat files by Gothmolly · · Score: 2, Funny

    The solution is to maintain a series of flat-file or relational DBs locally for every host on the Internet. Periodically, you should be able to do an FTP or similar of the latest master file, and place it on your local nameservers or hosts. Its the only way to be sure.

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:flat files by imipak · · Score: 2, Informative
      That's how it was back in the day before DNS, grasshopper:

      http://www.livinginternet.com/i/iw_dns_history.htm

  8. they tried that by RWerp · · Score: 2, Funny

    It just doesn't scale. But you know that, don't you?

    --
    "Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
    1. Re:they tried that by jonaskoelker · · Score: 5, Funny

      Ooh, I have an idea. We could request only the parts of the file we actually need. Then we could probably do it in real time; the load on the master server will possible get too heavy, though. I know, our ISPs could cache local copies, and we could split the file into hierarchical chunks.

      Hey, I oughta' write up an RFC on this ;)

  9. Wrote about this in Feb 2006 by karl.auerbach · · Score: 4, Informative

    Back in Febrary 2006 I wrote a note "What Could You Do With Your Own Root Server" at
    http://www.cavebear.com/cbblog-archives/000232.html

    My conclusions were that one could make money and cause trouble.

    One of the more interesting aspects was (and still is) that one could operate root servers and, using the Google model, pay ISPs and users to send their queries to your roots so that you could generate data mining revenues.

    That quality of data that is minded form root traffic would not be as good as that as from a top level domain server - and who has some large top level domains and also has root servers? Verisign.

    And ICANN's contract with Verisign explicitly permits data mining of query traffic.

  10. The heck with DNS by iminplaya · · Score: 3, Funny

    Time for you mental midgets to start remembering IP addresses. Do your own damn cacheing.

    It's a JOKE! Alright?

    --
    What?
    1. Re:The heck with DNS by eneville · · Score: 2, Insightful

      Time for you mental midgets to start remembering IP addresses. Do your own damn cacheing. It's a JOKE! Alright? Well, it's not such a silly idea. When I look at my firefox 3 smart book marks, there are maybe 5 pages that I go to regularly. Anything else I can see using google page cache. So what's the big deal, having those few sites in a local hosts file isn't so much of a task.
      --
      Why UNIX?
  11. hosts file by eneville · · Score: 3, Informative

    216.34.181.48 www.slashdot.org
    208.65.153.253 www.youtube.com
    208.65.153.238 www.youtube.com
    208.65.153.251 www.youtube.com
    69.63.184.15 www.facebook.com
    81.110.242.129 www.s5h.net
    66.102.9.99 www.google.com
    66.102.9.104 www.google.com
    66.102.9.147 www.google.com
    Use google page cache for anything else

    --
    Why UNIX?
    1. Re:hosts file by gnuman99 · · Score: 2, Funny

      Sir, what are you doing?!? Perl is NOT meant to be readable. It the code MUST be all on one line!

      use strict; use warnings; use Net::DNS; my %hosts; sub lookup { my $res = Net::DNS::Resolver->new;my $query = $res->search( shift );if ($query) {foreach my $rr ($query->answer) {next unless( $rr->type eq "A" );return( $rr->address );}}else {warn "query failed: ", $res->errorstring, "\n";}}while( my $l = ) {if( $l =~ m!(http://.+?)\s! ) {print( "$1\n" );if( $1 =~ m!http://(.*?)/! ) {my $ip = lookup( $1 );$hosts{$1} = $ip;}}}foreach $host ( sort keys( %hosts ) ) {print( $host, "\t", $hosts{$host}, "\n" );}

      There, fixed it for ya!

  12. That's easy by bconway · · Score: 5, Informative

    World-wide Rickroll?

    --
    Interested in open source engine management for your Subaru?
  13. Take it... by Timosch · · Score: 2, Insightful

    ...and sell it to the Chinese government. The answer to all their desires... No, just kidding.

  14. Obvious first move by PPH · · Score: 5, Funny

    Goatse.cx lives!

    --
    Have gnu, will travel.
  15. Re:I once interviewed at a job by R_Dorothy · · Score: 2, Informative

    If they ran an internal DNS for their network and it was for the same domain as the external record then it would have over-ridden the stolen DNS records. This is a very common practice for dealing with inside-out NAT resolution of public facing servers that also need to be accessible from inside the firewall under the same name.

    So if the web server was an internal server:
    www.example.com -> 192.168.1.123 (returned by internal DNS server)
    www.example.com -> 123.87.32.245 (returned by external public DNS server)

    Even if www.example.com wasn't an internal address server, the example.com domain may be handled by the internal server.

    So if www.example.com was an external server:
    www.example.com -> 123.87.32.245 (returned by uncompromised internal DNS server)
    www.example.com -> 245.76.237.25 (returned by compromised external DNS server)
    dc1.example.com -> 192.168.0.100 (internal host on example.com domain - no public DNS record)

    --
    Stupid flounders!