"DNS Forgery Pharming" Attack Against BIND 9 105
Monley writes "Help Net Security is running a story about a severe flaw in BIND's implementation that allows fraudsters to efficiently predict generated random numbers without the need to control the route between the user and the DNS server. (Here are HTML and PDF versions of the paper.) Using this vulnerability, fraudsters can remotely forge DNS responses and direct users to fraudulent websites, which can steal the user's sign-in credentials and do other mischief. The flaw was discovered by security researcher and Trusteer's CTO, Amit Klein." The ISC has released a patch to BIND 9.
Re:wow... (Score:1, Interesting)
I won't run DJB's authoritative server as it violates the spec by not answering queries that have the recursive bit set. (The spec doesn't require honoring the bit, just answering the query out of what is knows would do).
Re:New (Score:2, Interesting)
"Existing desktop security solutions cannot protect against this type of attacks since DNS forgery pharming does not involve the user's computer or the DNS server but rather the cached data on the DNS server. Mutual authentication solutions, such as Trusteer's Rapport, which strongly authenticates the destination website and prevents access to unauthenticated websites, can defeat the attack."
How convenient!
What version of BIND is going to have the fix? I've got 9.3.2 at the moment.
Re:New (Score:5, Interesting)
If you read the PDF, you will see that a good history of this kind of attack (and previous responses to it) are detailed. Apparently there has been is history of research into this kind of attack, with various counter measures. But the new attack (which seems like it would apply to almost all versions of BIND9 takes a different approach at "cracking" the PRNG which looks like it could be run against real-world servers.
I don't pretend to understand everything (or even most things) in the PDF, but it looks like solid research to me.
djbdns (Score:2, Interesting)
Re:djbdns (Score:4, Interesting)
The functionality of clever tools like QMail and djbdns and daemontools has thus wound up sidelined and ignored by mainline developers. There are numerous lengthy and well-frounded rants on this, such as http://linuxmafia.com/~rick/faq/index.php?page=wa
Jeezus freaking A Christ (Score:4, Interesting)
-Matt
Re:wow... (Score:3, Interesting)
Of course I could go ahead and run the recommended DJB configuring using rsync + openssh to propogate zone files. Then I would avoid the 10 vulnerabilities filed against BIND9 over it's seven year life span, but open myself to the 40 or so against OpenSSH, 30 or so against OpenSSL, and 10 or so against rsync.
Re:djbdns (Score:2, Interesting)
And, no, you can't fix these issues and distribute a "djbdns-fixed.0.1.tar.bz2" file with the fixes in place, because djbdns is not open source.
djbdns is dead and has been dead for years now.
Re:So.. if BIND9 sucks.. what is an alternative? (Score:2, Interesting)
I've been using PowerDNS [powerdns.com] to manage several thousand domains for almost 3 years and its been the best thing I ever did. Besides being GPL it has an SQL backend so doing things like changing the TTL for 300 domains takes a few seconds instead of the slog or scripting nightmare with BIND. I use mysql replication to keep my slaves uptodate which is also flawless. Load average handling around 150 queries a second is less than 1%
There is a postgres backend for it as well although I have never tried it.
Just an idea (Score:3, Interesting)
The login sequence should be:
1) user submits his username.
2) site submits the back-password.
3) if back-password is correct, user submits his password.
By using bi-directional login, if the site is spoofed, the login process will fail, unless the spoofed site knows the back-password.
After login, communication should be encrypted so as that no 3rd party can eavesdrop on the communications.