DNS Flaw Hits More Than Just the Web 215
gringer writes "Dan Kaminsky presented at the Black Hat conference in Las Vegas on Wednesday, and said that the DNS vulnerability he discovered is much more dangerous than most have appreciated.
Besides hijacking web browsers, hackers might attack email services and spam filters, FTP, Rsync, BitTorrent, Telnet, SSH, as well as SSL services. Ultimately it's not a question of which systems can be attacked by exploiting the flaw, but rather which ones cannot. Then again, it could just be hype.
For more information, see Kaminsky's power point presentation." Update: 08/07 19:48 GMT by T : There's also an animation of the progress of the patch.
Cyber 9/11 (Score:2, Interesting)
Re:SSH and SSL protected (Score:5, Interesting)
Re:SSH and SSL protected (Score:2, Interesting)
Slide 65 of his presentation:
Actual data: When a major online bank in New Zealand had its cert expire, 99.5% of users still entered their credentials.
Re:Litmus testing (Score:3, Interesting)
The thing that cracks me up is that the one service I've not yet seen mentioned on Slashdot that is affected is exactly the one a geek might have figured on first - the practice of VPN tunneling over DNS servers. (See Freshmeat, as always, for details.) The attack obviously means such VPN tunnels can be spliced into. This means anything that can be reached by such tunnels, even if the endpoints concerned cannot be remotely accessed by any other means, are essentially wide open.
Now, I don't personally know of anyone who uses such tunneling software, but that's not the point. This is a GEEK site! Geeky but irrelevant vulnerabilities should rank higher than mundane, boring, obvious ones that most geeks should not care about anyway. (When I started running my own MUSH servers - I had 7 going at one point - I didn't trust external DNS servers to be safe, reliable or up-to-date, so simply zone dumped all the regulars onto my own DNS and ignored the outside DNS tree entirely. If anyone had problems, I re-transferred the zone from IP address, never name, and always from the authoritative source, never secondaries. These days, that could constitute breach of copyright or an act of terrier-ism, so I've stopped running MUSHes and MUDs.)
Wide open internet is doomed. (Score:5, Interesting)
I RTFA. At this point, we're hanging all of our eggs into the encyrption basket. If someone proves P=NP and breaks SSL, the whole internet is hosed. Now again, why are we telling people that this stuff is safe, when -we- know that it is not?
1. The internet will have to balkanized into those countries that have laws to go after hackers and those who do not.
2. Consumers will eventually only choose content that is actually hosted by their ISPs because that will be the only content that is safe.
3. ISPs will increasingly look to disallow traffic coming from "non-trusted" ISPs in order to protect themselves.
Re:SSH and SSL protected (Score:3, Interesting)
You'd need a root cert, not just control of the domain. You wouldn't even be able to revoke certs.
Watch thte power point. Once you've hijacked the domain you can intercept email. Then all you have to do is say you forgot your password on the cerficate authority website. Which will promptly email you a new one. Login and have the cert reissued to work with your nefarious fake website.
Weakness of "domain control only validated" certs (Score:5, Interesting)
Kaminsky makes a point about how this bug can be used to spoof Certification Authorities who issue SSL certificates. For the cheap "domain control only validated" certificates, ownership of the domain is validated by sending an e-mail to the domain. If you can spoof DNS from the viewpoint of a CA, you can buy a valid SSL cert for a domain you don't own. Now you can spoof some banking site, and the spoofed site will properly display an SSL cert.
He also makes the point that DNS cache poisoning can be used to fake MX records in DNS, which will result in e-mail being diverted to the attacker, who can then look at it. If the attacker creates a high-priority MX record, they can read the mail, then disconnect without acknowledging receipt. The originating mailer will then resend to the next-priority MX record, the real one. So the mail reaches its destination without anything in the headers to indicate it was snooped.
Re:SSH and SSL protected (Score:3, Interesting)
Firefox and IE will, by default, warn you about sending unencrypted passwords.
They warn you about sending any unencrypted information, not just passwords. Most people don't want to see that message every time they use Google, so they turn it off.