Slashdot Mirror
What Could You Do With a Bogus Root Name Server?
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."
... 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.
http://www.livinginternet.com/i/iw_dns_history.htm
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.
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.
Absolutely not. Do you know anything about SSL?
The certificate has to be signed by a legitimate Certificate Authority, and be in the name of pop3.yourisp.com. Otherwise your email program says "Hey! I was expecting a certificate for pop3.yourisp.com, when I got a certificate for pop3.evilisp.com!".
Well, most email programs will. Even Outlook will do that.
You can mess up a lot with DNS. But it doesn't break SSL in the slightest.
I think the OP's referring to TSIG and it's variants.
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?
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.
World-wide Rickroll?
Interested in open source engine management for your Subaru?
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
Amazon makes you re-enter the complete credit card number if you ship to a new address.
That had its domain name stolen while I was in the interview, and the DNS from their office still seemed to function... so from their office they still got their site when they went to xxx.com, but from anywhere else it went to yyy.com
That is because DNS replies are typically cached for a period of time, often several days.
If you don't have it in cache, you go to the source and get the current value.
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.
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.
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.
Unions everywhere else are not like unions in the US.
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!
I can confirm Outlook 2003, 2007 and any remotely recent version of The Bat!