Slashdot Mirror
Identity Theft Hits the Root Name Servers
aos101 writes "The Renesys blog has an interesting story about networks advertising the old address space of the L root name server after ICANN changed the IP address last November. These networks were also running root name servers on the old IP address of the L root name server up until last week, so any DNS servers still using the old IP address might have been getting their answers from these bogus name servers. A very cursory examination by Renesys of one of these bogus servers found that it appeared to be providing correct responses, which might be why no one noticed the problem. As Renesys points out, the volume of traffic to a root server is staggering, so the people running these bogus root servers must have had a reason. What did they get out of it?"
Somehow, I doubt that is the explanation, but wouldn't it be nice if it were true?
Invenio via vel creo
Summary of this article should read:
"Hey, something happened. No, we don't know who, what, when, or why. We do know where, but that's it. You got any ideas?"
Should have been submitted as "Ask Slashdot"... Then maybe we might find out what happened, if anything. As is, it is a non-news item.
They were probably running something similar to Verisign's SiteFinder that attempts to cash in on typos and non-registered domains.
statistics? profiling?
that data would be worth something to ad men surely...
Actually, "attack" isn't really an appropriate term. It was not really an attack or a hijack or even identity theft. For one thing, these terms imply the existence of both a victim and a villain. In this story, the villains are not obvious and there might not have been any victims.
How do we go from this to a headline reading Identity Theft Hits the Root Servers?
There is no reason to believe that it was malicious at all. We all are familiar with that black hat turned grey or white that wants to help out by demonstrating vulnerabilities in the system. That is just as plausible as anything else. Maybe it's the free-masons!! The Illumanati, maybe!!! The only certain thing about this is the need to secure name service. We should be glad even though it was compromised, there is no apparent damage done.
I got a catholic block.
Maybe they just forgot they had them.
Evil marketing firms are always looking for ways to improve typo-squatting. Popping a root server's address space is the ultimate in NXDOMAIN (failed to match) lookups as every DNS server on the net that cannot resolve a domain (such as unregistered typo-domains) will go further and further back until it hits a root server. Hence having a root server's NXDOMAIN data is the ultimate in typo-squatting.
Since they seem to be providing valid responses (as suggested in the article), it must be some traffic data that they are collecting. They now have a long list of valid IP addresses with data, consider it a list of targets. They also have some first-hand data on the most popular websites which they could sell to advertisers ("Are you sure you're getting the right billing from your advertising agents?"). It could also have been a set-up - benign now but gearing up to start attacking later. I hate to mention it, but they could have been testing a cyberattack technique and had the bad luck to get caught (the Manchurian DNS server).
The addresses (and traffic patterns) of the whole world's secondary DNS servers? Can you say DDOS??
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
A few reasons spring immediately to mind.
1. Preliminary move with the intent of actual subversion of results at a later date. This gives you an idea of what the traffic looks like, the volume you're going to have to manage, and the technical requirements of managing the subversion on top of recording important information about the systems you just subverted for later exploitation, plus any statistical information you need/want to improve your subversion process.
2. Preliminary move by a government, corporate entity, or some grouping with the intent of either wresting control of some portion of the DNS infrastructure from ICANN, or setting up a country-specific DNS infrastructure that is legally mandated. Again, you get valuable information about the kind of stuff you need to be dealing with, depending on exactly what you have in mind.
3. Same as above, but more of an idealistic style intervention, fearing malicious intent from the US government which still controls the DNS system, and trying to prepare for a time when an ICANN-free DNS system may need to be put in place.
Depending on where this stuff is actually going (and if it's the actual owner of the IP space that is doing this) of course...
If only 5% of DNS servers hadn't updated their root servers list, and this server is listed as 1 of the 13 root servers, then these people will have .38% of the entire internet's DNS requests coming through them.
With "control" of a root server (or at least what a DNS client believed was a root server. They would be free to insert whatever records for anything they want. Think banking, finance, email, etc.
So really, the title of this article should have been if you were in organized crime, what would you do if you could transparent MITM (man in the middle) attack .38% of all web traffic on the internet.
My guess is all your accounts belong to us.....
Colin McNamara - CCIE #18233 "The difficult we do immediately, the impossible just takes a little longer"
Thank you, thank you!!! I'll get my coat... ;-)
I guess I don't see what the big deal is. The ICANN article stated that the old root DNS server would run for 6 more months, and that appears to be all that has happened.
What am I missing?
"It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service."
You can get the your root server hints files from:
ftp://ftp.internic.net/domain/named.cache
Slashdot's junk filter won't allow a cut and paste of the file's contents into a post.
Maybe whoever set up the "fake" RNS was trying to hide and appear to be safe until some time when it could collaborate some DDOS. We won't know since they aren't up and running, but having such a highly used server would have been beneficial for whatever the purpose was in the first place, to everyone if it were a positive one or to them if it were negative. But what do I know, I'm purely speculating.
Absolute power corrupts absolutely. indymedia
Demanding constant attention will only lead to attention.
"It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service."
The notice is dated Oct 24th '07, which means the six months isn't up yet.
Nothing to see here, they are being nice and keeping the old one up for a while to make sure people have read the notice and acted on it.
If the real server went offline May 2, does that mean the "spooky" fake servers would only have been getting traffic after May 2, so in the last two weeks, or were they getting traffic over the last six months? If so, how did that happen?
I think they just got a warm and fuzzy feeling out of it.
;)
The problem with modern life is everyone's so damned paranoid all the time. Sometimes people do things that are nice believe it or not
This story is kind of silly actually. On the post available on the ICANN blog, it is clearly stated that the IP address will change on November, 1st and that "It is expected that the old address will continue to work for at least six months after the transition".
Even a 6 year old child would be able to determine when the IP address would be eventually unused (end of May).
From the article quoted as the source of the reference, it is clear that no one tried to verify the information. It would have been very simple to determine it was the same server on both address if only someone tried to check it...
when the old eunet service was finally shut down, there were still a considerable number of people using it as a resolver, and there were still live domains hosted on it where we're been unable to find anyone able to move them!
the /24 IP block was quite useful, so it was re-routed to a different site, and no sooner than machines were deployed on that address, DNS queries began to arrive despite the whole IP block having been unused and unroutable for about a year!
my point is that you can get 99% of the internet to accept updates, but there's a huge number of neglected legacy systems which never get reconfigured because people often don't even know they're there!
My uncle used to say that he preferred corrupt judges to incompetent judges, since the corrupt judges would be careful to get things right 95% of the time, so that they would be well placed when the time came to undermine the system. The incompetent judges, on the other hand, would screw things up far more frequently than that, and ruin far more lives than the corrupt judges. A very few redirected queries could get lost in the huge number of correct responses, but still provide big benefits to a criminal. And if they compromised a secretive bank, or the Defense Department, it's unlikely that we would ever hear about it.
They changed the IP address of the "L" root server, but might have kept the old one active just because not everyone was going to change their configuration in lock step.
They could have kept the address, but then provided a note that the configuration was incorrect, but that really dones' help a lot. I, as an end user can't do much to change the configuration of my nameserver. Besides, my nameserver might have been using another nameserver which used another before it got to the root server. All that would have done would be to frustrate a lot of people, but not allow them to get around the problem.
So, unless it is known that the old L root server IP was actually hijacked and that ICANN didn't just leave it running in a deprecated state for about six months to allow other name servers the time they needed to update their records, I can't really say this is an issue.
Maybe someone should contact ICANN to see if they have any statement on this issue.
Bear in mind that BIND for one doesn't use the root nameserver hints file directly under normal conditions. One of the first things it does is contact one of the servers listed in the hints file and download the real root nameserver list. After that it uses the downloaded list and ignores the hints file. So unless you contacted the L server for that initial download, you'll get the correct root server list and won't ever contact the bogus ones. I'd have to check whether BIND picks a hints entry at random or cycles through starting from the first. If it picks at random the window of vulnerability is small, but if it starts at the first it's virtually nonexistent (most hints files list A, B, C and so on in sequence, and the chance of getting no answer at all from the A-K servers is close to zero).
Pre-coffee posting. I NAT'ed it in the firewall rules so the traffic that had been routed to 127.0.0.1 got redirected to 127.0.0.2.
I was redoing some DNS stuff earlier (switching out a server) and I had CNAME on the brain.
Sad that you're the only person who noticed =P
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
How will anyone else know, since it's the root system responsible for giving out IP addresses?
Example: I request www.google.com. Parent doesn't know, its parent doesn't know, blah blah blah until I go to the "root hints" which are hard-coded IP addresses. There I look up www.google.com, and get my IP address. Now if that root server has a different IP, how the hell do I find it?
Is this a catch-22 or what?
The problem is that the underlying BGP is a trust based system. That's really what trust was taken advantage of. When you learn how that works and how BGP hijacking can happen, you realize how important HTTPS is and how vulnerable to man-in-the-middle attacks everything else is.
-- these are only opinions and they might not be mine.
why traffic goes to "retired" address space is a difficult question to answer. http://www.caida.org/workshops/wide/0611/ has a pointer to some early work done on the "B" renumbering. There was agreement by the operators of "B","L","J", and "M" to collect data during the DITL-2008 collection to see if any correlation btwn querying nodes. That said, ICANN should have renumbered the node when they took it over. They did not. They have not had permission to use the prefix since 2004 - but for stability sake, I did not make a big fuss.
bill manning
Maybe the reason that the nameserver is providing correct responses is due to something like port-knocking for domain names?
If a phisher wanted to use this, they would only supply a bogus dns pointer to a query if the query was preceded by some 'primer' query. E.g. first someone tries to resolve alpha.com, then beta.com within a few seconds, only then will the root server give the incorrect response for beta.com. This would be pretty easy to do with some cross-site scripting magic.
You can never disprove a conspiracy, after all...
The Right Reverend K. Reid Wightman,
The Internet was originally designed to be a "self-healing" system, able to route around damage like (no joke) a nuclear war.
However, the system as it currently exists has one SERIOUS flaw: the reliance on root servers.
We need to switch to a system that does not rely on root servers. There are at least several such systems that are workable. Yes, the U.S. government would lose control over the whole thing. Does ANYBODY in their right mind think that is a bad thing? As long as nobody else can gain root control either, and there are various schemes that can ensure that.
Updating hints is a one-line cronjob that you can run weekly or monthly. How hard is that to set up while you're setting up your DNS in the first place?
New mod option wanted: -1 DrunkenRambling
I checked my Leopard Server and /var/named/named.ca still had the old number in there, So I guess all the Apple servers out there except for those run by very hip people have been subject to some trouble. Someone should look at the common dists and see how common this is...
Suppose I follow that link to get that named.cache file. Who's serving me the DNS when I get that link? Once the squatters GET control, it is going to require non-DNS reliant methods for update. Certainly people will have to validate the sig on the file against the legitimate author's key.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson