Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

"DNS Forgery Pharming" Attack Against BIND 9

Posted by kdawson on Tue Jul 24, 2007 01:02 PM
from the better-hope-sitekey-works dept.
Security
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.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

"DNS Forgery Pharming" Attack Against BIND 9 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Come again? (Score:4, Insightful)

    by Angst Badger (8636) on Tuesday July 24 2007, @01:08PM (#19972849)
    Since when is a severe flaw in BIND's implementation news?
    • Come on, whoever marked this as troll has no idea of the history of BIND, or how many times many of us have had to patch BIND over the last ten years. Consider this: BIND is the only server that I've ever seen a distro package so as to be easily chrooted. Why do you suppose that is?
      • It's news because for a number of readers will be effected (no matter how many times it might have happened in the past). As for chrooting it's really a shame more packages *aren't* commonly jailed. But even bind isn't frequently chroot by default.
        • Sure, I know it's news, but I think the original poster was being sarcastic. In think he thought it was news, too. It's just, you know, the umpteenth time you have to patch BIND, sometimes you just snap... BIND isn't chroot by default but on several distros, jailing it is as easy as firing up Ye Olde Distro Specific Configurator and checking the "run BIND chroot?" box. I agree, more server packaged should come with the nice little scripts to chroot them easily.

      • Re: (Score:3, Insightful)

        by TheRaven64 (641858)

        Consider this: BIND is the only server that I've ever seen a distro package so as to be easily chrooted. Why do you suppose that is?

        Because BIND is the only one that's easy to run in a chroot. OpenBSD also runs Apache in a chroot, but it means you lose features, like the ability to share everyone's ~/public_html. BIND is quite rare among servers in that it's non-trivial but has fairly meagre requirements when it comes to disk access. I can't think of any others off the top of my head that meet this requirement, with the exception of an ftpd that is only used for anonymous FTP, and these tend to support chroot too now.

      • Re: (Score:3, Insightful)

        by Wdomburg (141264)
        Eh? BIND9 has a relatively tame history in terms of vulnerabilities. Just using the updates to RHEL3 as a quick and dirty metric, there have been two security updates compared to 5 openssh, 6 openssl, 11 php, 12 apache, 20 kernels, etc.

        Unfortunately a lot of people seem stuck in the past and still judge BIND from the 4.x and 8.x days.
  • ... 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.. (Score:4, Insightful)

    by fahrbot-bot (874524) on Tuesday July 24 2007, @01:28PM (#19973165)
    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.
  • Say it isn't so!

    Isn't it part of the INSTALL doc to run it in a VM/Jail/Chroot?
    • This isn't an attack on the server. It is a hijack attack against clients of the server.
    • Um, this flaw doesn't allow you to take over the process context of the BIND server. Instead, it allows you to poison the BIND DNS cache with phony records of your choosing.

  • Again.... (Score:4, Funny)

    by gweihir (88907) on Tuesday July 24 2007, @01:29PM (#19973185)
    Bind was and is a mess. The patch is to use something else....
    • I live in the niave hope that there's only so many bugs you can fit in one piece of software, and as such Bind and Sendmail should be practically impossible to break by now...
      • Well, maybe if people would move on and use other software like postfix and powerdns (just off the top of my head), we wouldn't be having all these issues, now would we?
      • I live in the niave hope that there's only so many bugs you can fit in one piece of software, and as such Bind and Sendmail should be practically impossible to break by now...

        Well, I think the thing is that you can fit only so many bugs per line of code, and both are growing...
        • They pretty much are.. when's the last time you heard of a vulnerability in sendmail?

          This particular one is - as others have pointed out - about 10 years old and really doesn't matter.

  • Don't Diss Bind (Score:4, Insightful)

    by toonerh (518351) * on Tuesday July 24 2007, @02:26PM (#19973985)
    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!
    • "Bind has been around since the dawn of Vint Cerf's IP"

      Not quite, try about 10 years later.

      Paul Vixie when at decwrl was funded by his boss, Brian Reid to take the Berkley B-Tree code and whip up a name daemon. This cost Dec quite a bit of money. This was in the mid to late 80s or so. Remember that the relevenat RFC for the domain name system only came out in 86.

      • Re: (Score:2, Informative)

        by SaDan (81097)
        http://www.microsoft.com/technet/security/Bulletin /MS07-029.mspx [microsoft.com]

        What was that again?

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        Yeah, better than Windows.

        Since this is Slashdot the parent post will be modded up and I'll be modded down, but the truth of the matter is that the DNS server that ships with Windows has never has a single vulnerability.

        Wow, you must have a VERY short memory. Try thinking back to just earlier this year, when Microsoft Security Advisory (935964) [microsoft.com] came out. And that is just one of MANY flaws over the years in MS DNS server! Hell, their DNS server for NT4 and earlier releases of Win2K (pre SP3) ran so sloppy th

  • djbdns (Score:2, Interesting)

    by jsdcnet (724314)
    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 (Score:4, Interesting)

      by Antique Geekmeister (740220) on Tuesday July 24 2007, @03:37PM (#19975035)
      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.

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      No, Djbdns is not acceptable. Its list of root name servers is five years out of date, and there is a remote denial of service security problem which has not been fixed. Heck, it won't even compile in any Linux distribution from the last three years or so.

      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.

  • Jeezus freaking A Christ (Score:4, Interesting)

    by m.dillon (147925) on Tuesday July 24 2007, @04:15PM (#19975559) Homepage
    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: (Score:3, Informative)

      by TheRaven64 (641858)
      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.

      • Re:Jeezus freaking A Christ (Score:4, Insightful)

        by -Bacon- (75425) on Tuesday July 24 2007, @09:48PM (#19978903)

        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.
        • They do utilize /dev/random if it exists, to seed and reseed the PRNG. There's a few reasons I can think of not to use those exclusively:
          • On some platforms /dev/random blocks if the entroy pool is exhausted. Really really great when you're trying to service thousands of queries a second.
          • On platforms where /dev/random doesn't block (or an alternate device like urandom is used for non-blocking random number generation) you're going to end up with a PRNG anyways.
          • They have to ship and support a generator rega
  • 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
    • Well, one answer: djbdns

      • Re: (Score:3, Insightful)

        by Just Some Guy (3352)

        Well, one answer: djbdns

        djbdns is proprietary, source-available software. It's nowhere near BSD or GPL licensed.

        • Re: (Score:2, Interesting)

          by elp (45629)
          Don't forget DJB's legendary personality as well.

          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

  • Just an idea (Score:3, Interesting)

    by master_p (608214) on Wednesday July 25 2007, @08:20AM (#19982349)
    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.

    • Re: (Score:3, Insightful)

      by dave562 (969951)
      Maybe those bored college students should have gotten off their asses, put down the bongs and published some research that they would have been paid for.

    • Re: (Score:2, Interesting)

      by countSudoku() (1047544)
      We'll thank goodness the people who are claiming the exploit *also* happen to have a product to defeat said exploit...

      "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.

    • Re:New (Score:5, Interesting)

      by Charles Dodgeson (248492) * <jeffrey@goldmark.org> on Tuesday July 24 2007, @01:26PM (#19973141) Homepage Journal

      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.

    • Re: (Score:3, Informative)

      by e9th (652576)
      This weakness of BIND has been griped about for TEN YEARS!

      http://www.openbsd.org/advisories/res_random.txt [openbsd.org] http://cr.yp.to/djbdns/forgery-cost.txt [cr.yp.to]

    • Re: (Score:3, Informative)

      by Kreggan (36002)
      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: (Score:3, Interesting)

      by Wdomburg (141264)
      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.
      • "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"

        Looks good on paper, but in reality how many bugs have *ss* caused in real world name service? Zero.

        How many compromised nameservers have there been because of bugs in bind? Non-zero.
        • You seriously think there have never been real world compromises from OpenSSL and OpenSSH? Absolutely none?

          If you look at the specifics of the vulnerabilities, none of the ones discovered so far in the BIND9 codebase have been privilege escalation. Mostly DoS, a couple cache poisons, one client side vulnerability in the backwards compatability stub resolver that's disabled by default, and a case of some leaked environmental variables. In the case of *ss* there are numberous code execution bugs. And yes,

      • Re: (Score:2, Informative)

        by Anonymous Coward


        OpenBSD's patched and native Bind9 is immune to this attack and has been for many years.

            • Re: (Score:2, Insightful)

              by matthewmok (412065)
              Moron,

              It is related to MS DNS -- a SYSTEM you said did not have any vulnerabilities.

              It's not hard to get a connection and a rooted machine in somebody's internal network. Also -- I can't think of anybody that would use MS DNS server outside on the Internet. If you do then that confirms my opinion of you.

      • Re:FOSSie fix!!! (Score:4, Insightful)

        by m.dillon (147925) on Tuesday July 24 2007, @05:03PM (#19976125) Homepage
        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
        • I'm pretty sure you also use gcc, then why not use powerdns-recursor ? I'm pretty sure it has the same license.

          Ohh, euh... I think I know what the problem is.

          Please, please, please, could you implement a good swapcontext and getcontext
          implementation for the BSD's ? :-)
      • BUT, the attacker needs to be _inside_ his organization in order to talk to the caching server (the inside dns server).

        This sort of thing has been done for ages even with BIND.

        With djbdns you actually have NO CHOICE and MUST do it that way - it's split into multiple programs e.g. tinydns = authoritative DNS (tell world about names), dnscache = caching server (to make recursive DNS requests for clients and cache them).

        Anyway, the ISC has never had a good track record with software (dns, sendmail, dhcpd). Tr

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.