"DNS Forgery Pharming" Attack Against BIND 9

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.

New

However, security researcher and Trusteer's CTO, Amit Klein, has discovered a severe flaw in BIND's implementation which allows fraudsters to efficiently predict generated random numbers without the need to control the route between the user and the DNS server.

How long has BIND been using the same random number generator? I'm a little bit skeptical that Mr. Klein is the first person to consider the possibility of mimicking its behavior.

Maybe the headline should read,"Exploit which bored college students figured out fifteen years ago is finally released to the mainstream".

Re:New

Maybe those bored college students should have gotten off their asses, put down the bongs and and written some bots that they would have been paid for.

Oh wait, that isn't ethical ...

Re:New

How long has BIND been using the same random number generator? I'm a little bit skeptical that Mr. Klein is the first person to consider the possibility of mimicking its behavior

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.

Come again?

Since when is a severe flaw in BIND's implementation news?

The flaw was discovered by...

... the CTO's underlings doing the hard work and the CTO gets the credit.

IMHO, the story wouldn't garner any interest whatsoever if the summary did NOT include mentioning the CTO. Look at the grief your average employee get when they publish an exploit.

Our product not vulnerable to flaw we discovered..

The flaw was discovered by security researcher and Trusteer's CTO, Amit Klein.

The TFA recommends using Trusteer's product to defeat this attack:

Mutual authentication solutions, such as Trusteer's Rapport, which strongly authenticates the destination website and prevents access to unauthenticated websites, can defeat the attack.

So, to recap. Vendor discovers a flaw and recommends their product.
Film at 11:00.

A flaw in BIND?

Say it isn't so!

Isn't it part of the INSTALL doc to run it in a VM/Jail/Chroot?

Again....

Bind was and is a mess. The patch is to use something else....

Don't Diss Bind

Bind has been around since the dawn of Vint Cerf's IP, but it has been redesigned and rewritten several times. The RFC that says replies go via UDP make it a security risk, but also make the net work better.

In 2007, where 1000,s of "researchers" spend their lives trying to break the Internet.... This stuff happens. BIND, SendMail and classic solutions are attacked. Amazingly they hold up better than Windows!

entropy?

I bet there's a way to incorporate some qrbgs [random.irb.hr] randomness to improve the security.

djbdns

I've been using djbdns [cr.yp.to] for years. It takes some getting used to if you're coming from BIND-land but it's worth making the effort.

Re:djbdns

Try looking at the copyright on djbdns. None, I repeat *none*, of Dan Bernstein's technically excellent solutions have propagated to broad use because of his extremely poor documentation, installation instructions, violations of the UNIX FileSystem Hierarchy, unwillingness to allow others to fork his code even for ease of packaging reasons, confusing licensing, etc.

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=war ez#djb [linuxmafia.com]. And like the absurd licensing conditions of Pine and the University of Washington wu-imapd, the refusal to accept input or insights from others or cooperate with its packaging for more stable configurations has led to their being discarded from most distributions.

Jeezus freaking A Christ

Why the hell is bind trying to implement its own random number generator? It's a piece of junk compared to the random numbers modern BSD OS's generate via libc.

-Matt

Re:Jeezus freaking A Christ

Probably because BIND has to be cross-platform. I'm sorry to break this to you Matt, but some people use inferior operating systems without good random number generation function.

That doesn't prevent BIND from using superior OS provided services for platforms that do have good random number generators. They decided not to do it, plain and simple.

Underscores the need for good design

At my organization, I've configured our DNS as split-split. Split-split means that the outside world only gets nonrecursive advertisements of our authoritative domains, separate servers are configured for the inside to do recursive queries(i.e. forwarders), and a last set is for our user land dns servers which forward to our recursive nameservers. Only these dns servers are allowed to talk to the forwarders, which sit in their own DMZ.
Now, my servers may have the same vulnerability as yours, but the risk of it being exploited is much lower. This buys me time to patch any given flaw without panicking too much.
To those that knock BIND, for its lack of security: if a system (i.e a group os servers meant to provide a service) is designed and then configured securely, even when flaws are discovered, the chances of getting hit can be vastly reduced. Yes, there are more secure versions of DNS out there, but BIND is the most popular. DJBDNS has a great reputation, but my solution works just fine and I don't have to learn yet another version of something that when passed on to the next person will go on neglected for years.

So.. if BIND9 sucks.. what is an alternative?

Lets see, it has to be GPLed or BSDed, run on every platform, be insanely robust, free as in beer, tested so thoroughly that it ought to make the law of gravity look like shaky science. So, based on those criteria, what DNS software could hold up? Just wondering. Peace, V

Just an idea

Shouldn't login into a web site be bi-directional? not only a user logs in a web site but the web site should log in a user by submitting to the user a password (let's name this password back-password).

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.

Hackers, to your keyboards!

Point all A records to 65.98.92.48!

Re:wow...

And what to you propose, Troll!

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:Yes but...

Only clueless (windows) admins will install and run bind nowayday. There you go...

Re:Complexity breeds problems.

Frankly, yes. The basic concepts of a DNS server are fairly straightforward, but as demonstrated by this attack, the devil is in the details. This attack uses reasonably advanced cryptanalysis, and exploits the predictable behaviour of DNS clients. I suspect that this attack would also have been mitigated by the use of DNSSEC, but the roll-out of that has been held up for years - and DNSSEC itself introduces even more cryptographic complexity.

Re:FOSSie fix!!!

A large number of programmers can make minor modifications to small software applications.

A medium number of programmers can make minor modifications to medium-sized software applications.

Very few programmers can make any sort of modification to very large software applications. Very, very few.

Bind is a very large, complex piece of software. A good portion of that complexity is due to poor documentation and badly designed algorithms (a problem I've had with bind from the first release on through today), but at this point the majority of the complexity is due to feature creep. I still use bind simply because I do not have the desire to write a replacement for it, and because the only other really good DNS package has a copyright and licence on it that makes it virtually unusable. Software gets stale as it gets older... if I can't keep software up to date after the original author has lost interest then I have no interest incorporating said software, no matter how good it is.

-Matt

Re:wow...

I personally like my DNS servers to follow the relevent standards personally.

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.