Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security

"DNS Forgery Pharming" Attack Against BIND 9 105

Posted by kdawson from the better-hope-sitekey-works dept.
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.
This discussion has been archived. No new comments can be posted.

"DNS Forgery Pharming" Attack Against BIND 9 More

"DNS Forgery Pharming" Attack Against BIND 9

Comments Filter:

  • New (Score:1, Insightful)

    by HomelessInLaJolla ( 1026842 ) *

    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: (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.

    • Maybe the headline should read,"Exploit which bored college students figured out fifteen years ago is finally released to the mainstream".
      They are a source of major innovation aren't they? Whitespace anyone? http://compsoc.dur.ac.uk/whitespace/ [dur.ac.uk]

    • 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 @02: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]

  • Come again? (Score:4, Insightful)

    by Angst Badger ( 8636 ) on Tuesday July 24, 2007 @02: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?

      • Re: (Score:2)

        by msimm ( 580077 )
        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.

        • Re: (Score:2)

          by spun ( 1352 )
          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.
      • Why do so many distros default to sendmail and bind? There was a time when running sendmail felt like an open invitation for people to break into your system. Debian has exim and Redhat offers postfix as one of it's defaults, why hasn't an alternative to bind come forward (from a distro provider point of view. The end user/admin can always install something else).

    • Re: (Score:1, Offtopic)

      by The Raven ( 30575 )
      I just wish more places would use djbdns [cr.yp.to].
  • ... 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 @02: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 @02:29PM (#19973185)
    Bind was and is a mess. The patch is to use something else....

    • Re: (Score:2)

      by Xugumad ( 39311 )
      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...

      • Re: (Score:2)

        by jZnat ( 793348 ) *
        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?

      • Re: (Score:2)

        by gweihir ( 88907 )
        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 @03: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!

    • Re: (Score:2)

      by rs79 ( 71822 )
      "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.

    • Bind has been redesigned and rewritten several times... and so has Windows. That doesn't mean anything. They both lack elegance, but they generally get the job done.
  • I bet there's a way to incorporate some qrbgs [random.irb.hr] randomness to improve the security.

  • 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 @04: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.
      • I think you're overstating the case when you slam his documentation. I've found some of it to be so clearly expressed that it seems obvious he is a teacher. The problem with it is that it lives on his server in html format.

        DJB's software is held up only by his licensing. Gerrit Pape's runit is a clone of daemontools with some added functionality. It's packaged in Debian and FreeBSD because it's GPL, not because daemontools is deficient in some way.

        It's a shame Bernstein is such a polarizing figure. His

    • 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 @05: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 eggnet ( 75425 ) on Tuesday July 24, 2007 @10: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
  • 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 ris

    • Re: (Score:1)

      by agbinfo ( 186523 )
      Warning: I'm pretty much clueless about this whole thing but I did read the report.

      From what I've read, you're not safe either even with Split-Split.

      What they claim is that you only need to get the caching server to make a few consecutive CNAME requests and they achieve that through CNAME chaining. Using those requests, they get your caching server's next not-so-random sequence number and start sending it DNS responses.

      Like I said, I'm pretty clueless about DNS servers but after reading the article, I fe

      • Re: (Score:2)

        by TheLink ( 130905 )
        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

        • Re: (Score:1)

          by agbinfo ( 186523 )
          The way I was understanding this, please correct me if I'm wrong, is that you don't need to be inside since you pollute the external DNS server. Once it's polluted, all the inside servers get their DNS information from that polluted server. In order to be able to pollute the external server, it must have no DNS entry for the site you want to pollute or its entry must be expired. You also need to trick some internal user to visit your site. This would probably make it extremely difficult to pollute entries f
          • You need to be inside, or need to bypass the firewall or other controls.

            He was talking about a split DNS server configuration.

            In my experience this is where you have:
            1) External DNS server(s)
            2) Internal DNS server(s)

            Configuration A
            (where the internal DNS server is allowed to do DNS queries directly)
            An External DNS server provides authoritative replies for the domains it is Authoritative for to externals.
            An External DNS server does NO recursive queries for anyone.
            An Internal DNS server only does recursive qu

            • Re: (Score:1)

              by agbinfo ( 186523 )
              Thanks for the explanation. To be honest, I didn't understand it fully. What's a recursive query? Is that the same as the CNAME chaining explained in the article? However, it explains why you can't pollute the DNS server with its own domain names but what about requests from internal clients to access external sites, how would the configurations you described stop the attack presented in the document from polluting the cache for these. If I understood the recursive query thing, I guess that would make it mu

              • Re: (Score:2)

                by TheLink ( 130905 )
                Yes, with BIND, if an internal user visits the attacker's site there is a higher chance of BIND's cache getting polluted than with a more secure dns server.

                This is because BIND tends to use the same udp port for its dns queries when it starts up. e.g. if it start up using 1055, it'll keep using 1055.

                So a malicious site that got a DNS request for badsite.com would know:
                1) you are about to try to get to mybank.com.
                2) the port BIND is using for queries.
                3) the transaction number(s) (query id) BIND is using for

                • Re: (Score:2)

                  by TheLink ( 130905 )
                  Oh yeah, one more thing. If you visit the badsite's webpage, the badsite can also cause you to fetch pages from other sites the badsite wants to "fake". It's not just mybank.com, the webpage could point to any site of the attacker's choice (e.g. www.google.com), it doesn't even have to be visible in the browser.
  • 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
          • The PostgeSQL backend works smoothly, and fits in with other services and backups. It is a simple table though and does not take any advantage of the relational capabilty.

          • 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 haven't used PowerDNS but I've heard nothing but good about it. I only host about 20 DNS zones and BIND comes with FreeBSD, so I never bothered to learn anything else.

            BIND maintenance doesn't have to be painful, though. The key is to refactor your zone files into smaller include files and let it auto-complete as much as necessary. Here's my standard template file:

            $TTL 1800

            @ IN SOA kanga.honeypot.net. root.kanga.honeypot.net. (
            2007072002 10800 3600 604800 86400 )

            $INCLUDE external/gl

    • Re: (Score:1)

      by kc0dxw ( 42207 )
      I am using (and like) maradns -- http://www.maradns.org/ [maradns.org]. The format of the zone file is *much* simpler.

  • Just an idea (Score:3, Interesting)

    by master_p ( 608214 ) on Wednesday July 25, 2007 @09: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.

    • 1) user submits his username.
      2) site submits the back-password.
      3) if back-password is correct, user submits his password.

      Let's say this occurs with a spoofed site, this is what could happen:

      1) user submits his username to spoofing site
      2) spoofing site connects to actual site and submits user name
      3) actual site submits the back-password to spoofing site
      4) spoofing site submits back-password to user
      5) user will see the same back-password he saw if he connected to the actual site

      Why not just use

  • Point all A records to 65.98.92.48!

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close