Forgot your password?
typodupeerror
Security Networking The Internet

Kaminsky's DNS Attack Disclosed, Then Pulled 281

Posted by Soulskill
from the can-of-worms dept.
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak." Reader Time out contributes a link to coverage on ZDNet as well.
This discussion has been archived. No new comments can be posted.

Kaminsky's DNS Attack Disclosed, Then Pulled

Comments Filter:
  • The push for DNSSec (Score:5, Interesting)

    by QuantumG (50515) * <qg@biodome.org> on Monday July 21, 2008 @07:03PM (#24281743) Homepage Journal

    Kinda makes you wonder what they're getting out of it.

    • by dintech (998802) on Monday July 21, 2008 @07:07PM (#24281785)
      Fame? Notorioty? Unstoppable attractiveness to women?
    • by gatekeep (122108) on Monday July 21, 2008 @07:29PM (#24281987)

      DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).

      Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.

      DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.

      • Re: (Score:3, Interesting)

        by mrsbrisby (60242)

        Paul is an idiot and a douchebag. He's been lying to you for a long time to cover his own ass: BGP routes are filtered everywhere which means that not only do you have to break the port, and the sequence number, you also have to break the route filtering every AS is already doing.

        Meanwhile, had BIND simply gone and removed the stupid ADDITIONAL-section processing like DJBDNS did, you wouldn't be having the described vulnerability.

        • by 0xygen (595606) on Monday July 21, 2008 @08:45PM (#24282759)

          Not to be paranoid, but the argument of "no-one can do this" is often weak in the light of it being governments or intelligence agencies who are trying to mess with your internet access.

          Is he scared of his government?

          Or concerned about what his government may be doing to others in the world?

          The problem is not necessarily on the "some attacker half way across the world on another AS", but may be much closer to home.

          • Re: (Score:3, Interesting)

            by mrsbrisby (60242)

            To be blunt, "the government" can crack your DNSSEC keys as well.

            LAN security doesn't enter into it- if your cache is on the same machine, and you're using switched ethernet to the border, any remaining attack vectors "close to home" remain on the same level as transparent proxies and whatnot.

            Where is your god then?

        • by Michael Hunt (585391) on Monday July 21, 2008 @09:05PM (#24282975) Homepage

          BGP routes are filtered when they're exchanged between eBGP routers. If you don't filter, you're an idiot. This I agree with.

          You're not talking about BGP route filtering, though; you're talking about some kind of reverse path filtering (making sure that a route to the source address exists on the interface that you received the packet from). In practice, you almost never do this on BGP routers, as RPF makes some (somewhat naive) assumptions about the symmetry of Internetwork traffic.

          Most people who have some kind of RPF deployed have it on a customer-facing device, as you generally only have one route per customer (and can make assertions about traffic NOT coming via that route, AND traffic COMING via that route.)

          That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%. And it only takes one (or a handful of machines) that can forge UDP source addresses for this to be an issue.

          • Re: (Score:3, Insightful)

            by mrsbrisby (60242)

            Actually, for multihomed sites it's even easier.

            Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.

            In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render

      • by Trogre (513942)

        Really dumb question, but why can't we patch BIND to do what DNSSec does?

        • Re: (Score:3, Informative)

          BIND supports DNSSec; DNSSec is about cryptographically signing your DNS entries so resolvers know that the response they got was from the legitimate authoritative server for the domain.

          This means that it's not something you can "just patch" - it actually requires people to do some work, which means it'll take a very long time to actually be widely deployed (by "people" I mean "every single person who administers one or more DNS zones"). You also have the usual problems with crypto, i.e. establishing a "web

    • by 0xygen (595606)

      Not to state the obvious, but possibly a secure DNS system?

      Although, it has been mentioned that there are a number of competing similar commercial solutions available from the big routing / switching manufacturers. However then you would expect them to want to delay DNSSec as much as possible.

  • Perhaps someone whose income depends on phishing, and who is at the same time bright enough to build a reasonably complicated rootkit. This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 days.

    Give an evil genius some credit, 2 hours tops and half that time's spent reading /., most of the other half on other evil online things; like pr0n and goatse.

  • I mean they coordinated this massive "patch" that's supposed to fix it. Now that it's fixed, it's not a secret anymore, or it this one of those cia secrecy where the reputation of those involved is at stake?

    • by cez (539085)
      I've heard of certain problems with at least IIS 6's DNS patch breaking certain servers [yeah yeah citations :]... just curious anyone with links to a "certified" fix?
      • by Vancorps (746090)

        How would patching a DNS server break a web server? My guess is that someone was blaming the patch for a problem that they created themselves.

        "Certified" fixes for MS products come from Windows Update or in certain extreme circumstances you have to request the file such as the case with the Exchange 2003 issue with calendar updates to Exchange 2007 systems. The dates get mangled so the server is unable to read further updates. Just an example from my world.

        It is quite rare these days unless you're doing so

        • by cez (539085)
          Well I guess I don't know the credibility of what I came across in researching a different matter, but there was this description on experts-exchange.com (nope dont have the resolutions)here [experts-exchange.com]. I guess that's why I'm asking... any real world success / horror storries? Our issue turned out to be a newly rebuilt box after a failed hard drive with a mis-configured hosts file (that had had the patch applied, but was not the culprit).
  • by smitty_one_each (243267) * on Monday July 21, 2008 @07:13PM (#24281841) Homepage Journal
    ...about these Monsanto DNA attacks for some time...
  • by gatekeep (122108) on Monday July 21, 2008 @07:20PM (#24281899)

    Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated. [doxpara.com]

    In case of Slashdotting, here's the full update;

    Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (Theyâ(TM)re ready for your traffic.) Thank you to the many of you who already have.

    • Re: (Score:2, Informative)

      by spankymm (1327643)

      do NOT blindly forward to OpenDNS

      They do not return NXDOMAIN for domains which don't exist.

      Dan, not all of the internet is a web-browser.

  • I got this much (Score:2, Informative)

    by bluefoxlucid (723572)

    I got this much and am working on extracting more but hitting a roadblock.

    Matasano Chargen  Blog Archive  Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery. Well the cat is finally out of the bag. I suspected this was how the

    the cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan ... One of them involves mucking about with the QID in DNS packets and
    and the other requires you to know the Deep Magic. First, QIDs
    Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4.
    Mallory would like the answer to be 6.6.6.0. It is a (now not) secret shame of mine
    that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my
    job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part
    of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets
    from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response
    wonâ(TM)t match. The QID is the only thing protecting the DNS from
    Mallory (me). QID attacks began in the olden days, when BIND simply incremented the QID
    with every query response. If you can remember 1995,
    hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373?
    You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM.
    All are quietly discarded â"- until Mallory gets Bob to query for
    WWW.VICTIM.COM. If Malloryâ(TM)s response gets to your computer before the
    legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where
    where Mallory tells you youâ(TM)re going

    • Re:I got this much (Score:5, Informative)

      by bluefoxlucid (723572) on Monday July 21, 2008 @07:26PM (#24281965) Journal

      Found this while google screwing. Someone got it!

      http://pastebin.ca/1078776 [pastebin.ca]

      1.
      Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery
      2.
      from Matasano Chargen by ecopeland
      3.
      0.
      4.

      5.
      The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
      6.
      1.
      7.

      8.
      Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.
      9.

      10.
      Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when heâ(TM)s called back to get his sandwich. If youâ(TM)re wondering, Bob likes ham on rye with no onions.
      11.

      12.
      If youâ(TM)ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. Itâ(TM)s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
      13.
      2.
      14.

      15.
      Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.
      16.

      17.
      First, QIDs.
      18.

      19.
      Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
      20.

      21.
      It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response wonâ(TM)t match. The QID is the only thing protecting the DNS from Mallory (me).
      22.

      23.
      QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. M

      • by snowgirl (978879) *

        *GASP!*

        It's like on the intartoobs nothing is ever gone once published.

        It's true people, and well... be careful with what you post. INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

        • Yeah, it's there somewhere. Google's cache had the newer version, but their database had the full story. A few people had the full text in their RSS readers too. They dropped the ball.

          Also, a girl? On Slashdot? Have we broken 20% yet? The nominal on IRC seems to be 3 boys for every girl, which is just about perfect for a lot of girls....

        • INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

          You're right. I asked my information his opinion on the matter, and he clearly said that he should be free, not so much that he wants to be free.

  • by mysidia (191772) on Monday July 21, 2008 @07:34PM (#24282033)

    Use Google search snippets to expose little details of the document...

    I'm guessing some persistent folks will eventually be able to piece the bits together.

    i.e. see how much you can piece together from the summary with the result shown by google. Adjust your search by including unique words towards the end of the snippet in one search to try to get the text that follows.

    1 [google.co.uk]

    2 [google.co.uk]

    21 Jul 2008 ... One of them involves mucking about with the QID in DNS packets and the ... The QID is the only thing protecting the DNS from Mallory (me). ...

    21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0. 3. Then thereâ(TM)s that other set of ... 21 Jul 2008 ... Then thereâ(TM)s that other set of DNS vulnerabilities. ... Then letâ(TM)s set up an evil server with it, and register it as EVIL.COM. ...

    21 Jul 2008 ... EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the .... EVIL.COM and slipping strychnine into his ham sandwich, ...

    21 Jul 2008 ... This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when ...

    21 Jul 2008 ... Which sends back a response with an unexpected (evil) Additional RR. ... Weâ(TM)ll come back to it. Alice has an advantage in the race, ...

    21 Jul 2008 ... Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM. Aliceâ(TM)s advantage is not insurmountable. ...

    21 Jul 2008 ... Aliceâ(TM)s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. ..

    21 Jul 2008 ... Frequently, that server has to go ask another, and so on. .... And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! ...

    21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW .... COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0! ...

    21 Jul 2008 ... Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. ... Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. ...

    21 Jul 2008 ... COM was: 6.6.6.0. Every resolver that points to that name server will now ... COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact ...

    • Yep, that's how I got my copy. Then I found a pastebin in the middle of that junk that had the full text :)

  • Actually (Score:2, Funny)

    by krkhan (1071096)
    Well, as soon as he had posted that thing he got a Cease & Desist letter from MPAA for disclosing the intellectual property of Wachowski Brothers for The Matrix: Rebuttal. The movie was supposed to answer all the questions pertaining to the first movie and this attack was the secret way that Zion crafts used to hack into the Core. Of course, the Core refused to get its DNS servers patched because they didn't need anyone's help.
  • That's it (Score:4, Funny)

    by krkhan (1071096) on Monday July 21, 2008 @07:41PM (#24282113) Homepage
    I've had enough. From now on, /. isn't /. for me. It's 216.34.181.45. I'm updating all my bookmarks. Wait, why is it redirecting? I have a bad feeling about this. Itsatrick.
  • by Rudd-O (20139) on Monday July 21, 2008 @07:42PM (#24282129) Homepage

    ...is not just that you can race legit DNS servers for legit queries, is that you can request recursive resolution for bullshit DNS servers, while submitting fake answers WITH malicious informational records that let you poison second-level domains. So by requesting xxjk3j.google.com while submitting your own coolly crafted answer, you can make the victim DNS use YOUR DNS as authoritative for the future google.com replies.

    THAT is the significance of the attack. THAT is what matasano pulled.

  • If this is the real deal, there's some bogosity here. This is certainly not a new attack or flaw in the dns protocol, any more than run of the mill dns cache poisoning is. Spoofing responses from the root servers (to hijack a TLD) is difficult; their TTLs are long, there are many of them (more unpredictability), and most DNS servers service so many requests that it's unlikely that your spoofed answer will be the first one to hit the server and thus poison the cache once the TTL for that TLD has expired.
  • by Phroggy (441)

    Any idea when Apple might release a patch for Mac OS X Server?

    I know compiling BIND from source is always an option, but most admins aren't going to do that.

    • Bind is evil, bind has the worst security track record except maybe for sendmail but that's not saying much.
      I don't know much about the other options, I use djbdns, but PowerDNS looks fine.

  • I fail to see the point in pulling this information. The only people who will CARE about it are those who know how to exploit it, and they're the exact people who'll be able to find it regardless of if it's removed.
    I wouldn't mind betting this will show up on Wikileaks pretty soon (if it's not already).
    For those who've not heard of it: http://en.wikipedia.org/wiki/Streisand_effect [wikipedia.org]
  • Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to]

    djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.

    • The licensing on djbdns used to be pretty unacceptable, although it's gotten much better in the last few years. The packaging and documentation of djbdns and dan's other tools are awkward at best. Dan's software deliberately violates the UNIX File System Hierarchy, the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users, and ucspi-tcp is similarly nasty to package and maintain in a server environment without

      • 1. Licence [cr.yp.to]

        2. With possibly the exception of qmail, you can put everything anywhere you like. The /service path location is only hardcoded in svscan, for instance, and the other weird paths such as /command are only used in the install scripts, which you probably don't want to use anyway.

        3. I wish there was a credible alternative to djbdns. I only know of PowerDNS, haven't had time to try it yet, what about the others? Bind is a non-starter for me, just like sendmail (but Postfix is ok).

  • There is a write up on the register [theregister.co.uk] that suggests that while this may be Kaminskys attack, there is a possibility that it is another separate vulnerability.
  • Better Speculation (Score:5, Informative)

    by logicnazi (169418) <logicnazi@nOspAm.gmail.com> on Monday July 21, 2008 @09:44PM (#24283275) Homepage

    Alright, so I'm not even someone who does DNS/networking stuff even for a hobby (just a math grad who skimmed the RFCs once or twice) so if I can figure this out from what's up now then any competent bad guy can as well.

    Anyway my guess is that it involves a combination of the birthday attack and the request for multiple nonexistant nameservers. That is as the attacker you trick poisontarget.com into trying to resolve the following locations.

    AAA.google.com
    AAB.google.com ....
    XXX.google.com

    Now you forge a single response packet that works for all of these requests and send many different copies with different TXIDs. Thus to succeed you need only hit ONE of the TXIDs used in the real requests.

    In these forged responses you also have a forged glue record (as suggested in some of the links) which gives you control of lookups for all of google.com at poisiontarget.com after a single success.

    Then again maybe I missed something basic which means this doesn't work.

  • The described attack's a nasty tactic. I hadn't thought of it, or rather I had but discarded it under the impression that all DNS software had changed years ago to filter out additional RRs that weren't responsive to the actual query to prevent exactly this sort of attack. I hope Dan's patches include such a filter.

  • It's okay... (Score:3, Interesting)

    by davidu (18) on Monday July 21, 2008 @11:05PM (#24283941) Homepage Journal
    There will be more (new) announcements in the coming week or two. The DNS is gonna be fun for a while, unfortunately. We prefer it to be reliable and accurate.
  • by Anonymous Coward on Monday July 21, 2008 @11:13PM (#24283991)

    y ecopeland
    0.

    The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
    1.

    Pretend for the moment that you know only the basic function of DNS -- that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

    Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob's unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice -- once when he is called to the counter to place his order and again when he's called back to get his sandwich. If you're wondering, Bob likes ham on rye with no onions.

    If you've got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It's called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
    2.

    Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

    First, QIDs.

    Bob's a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

    It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I'm Mallory and I'm attacking Bob, how can he distinguish my packets from Alice's? Because I can't see the QID in his request, and the QID in my response won't match. The QID is the only thing protecting the DNS from Mallory (me).

    QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here's a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded --- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory's response gets to your computer before the legitimate response arrives from your ISP's name server, you will be redirected where Mallory tells you you're going.

    Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob's request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

    But there's a bunch more problems here:

    *

    If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
    *

    If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she'll break the RNG and be able to predict its outputs.
    *

    16 bits just isn't big enough to provide real security at the traffic rates we deal with in 2008.

    Your computer's resolver is probably a stub. Which means it won't really save the response. You

  • by FoxNSox (998422) * on Monday July 21, 2008 @11:31PM (#24284093)

    See http://thefrozenfire.com/data/dnspoisoning.html [thefrozenfire.com] for the whole deal, without the pastebin RAW formatting ;)

    • by Chrisq (894406)
      reasonably well formatted .... except for the white-on black colour scheme. Makes me nostalgic for those 1980s CRTs.
  • Kaminsky posted a test [doxpara.com] to see whether your DNS server is still vulnerable (it seems that you'll need to allow scripts from toorrr.com). If the server is vulnerable, he appears to be recommending OpenDNS [opendns.com] as a stopgap measure. Their nameservers are 208.67.222.222 and 208.67.220.220 .

    If you're really paranoid, switch to OpenDNS first before running the test...

    On a related note, doxpara.com = 66.240.226.139 , but I can't get anything but a 404 at the IP address. Should I be nervous?
    • by leuk_he (194174)

      You should be nervous.

      All leading internet companies that control the internet software came together at Redmond (why there) to patch their software and release it at the same time.

      Then they keep the exact detail hidden, blabbing something about about making the port dns request come from random.

      And the moment the information looks like to appear, it is hidden again.

      The patch released only affected independent firewall makers (like zonealarm) who were kept out of the circle.

      Do you realize they just gave all

  • by hivbus (809067) <joshua@boyd.gmail@com> on Tuesday July 22, 2008 @12:33AM (#24284559)
    I've posted up the full text of the article, and it'll stay up, assuming lighty doesn't fail miserably on me. http://www.jbip.net/content/text-mantasanos-article-detais-kaminskys-dns-attack [jbip.net]
  • Okay quick question. (Score:3, Interesting)

    by ledow (319597) on Tuesday July 22, 2008 @04:34AM (#24285953) Homepage

    Okay, I don't dabble deep in DNS but I have a few quick questions. The RR thing is nasty because sub-domain authority implies domain authority. That's just silly and I'm stunned that something so simple is still true. I imagine there are a million and one "good" reasons for it, but it appears to be a gaping hole that could easily have been removed.

    However, on the "let's spoof a DNS response" front - if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end? This is the solution surely, even if you can send millions of packets with incorrect QID's and similar identifiers at a DNS server, like any other service at some point it has to say "you're trying to be naughty" and blacklist any packets, sound an alert, get the upstream filters to block such traffic etc. (This is, of course, assuming that there are at least some systems in place to stop or limit source-IP forgery in the first place). It might even be a good idea, at this point, for such servers to not trust their data, and constantly compare their copies with those available from the nameservers. If "fluctuation" of the data (between real and spoofed responses) is detected, then sound an alert on that domain.

    How many responses does an average DNS server get that are invalid because of purely accidental causes (e.g. corrupted packets, mis-configured routers etc.)? Surely it's so few that it can instantly blacklist any suspicious activity, like trying to poison recursive caches in this manner.

    I imagine that most home routers are extremely stupid and can't stop such things because they rely almost exclusively on the ISP's DNS servers to do their job and a flood of fake packets will not be picked up (this is, however, one of the reasons that I've always used "DMZ" or PPP half-bridge settings on ADSL routers to throw all external packets towards a real server rather than relying on some VxWorks firmware to handle IP-based attacks). But the servers? They *should* be filtering, cleansing and blacklisting packets even before you get into whether they have the most up-to-date patches, and a security fix to enhance the randomness of X etc.

    It seems that the DNS servers are too trusting of "correct" packets that come as part of packet-floods of incoming data that is *obviously* false. DNS clients accepting data appearing to come from a trusted host is not nice, I agree, but recursive DNS servers should know better.

    Or have I missed something incredibly obvious here?

    I don't really care because my ISP wasn't vulnerable to this attack when I first tested it about 10 minutes after the first posting about its potential on the blog, and I'm pretty sure that they wouldn't have had any more advanced warning than anyone else.

    Having said that, the DNS servers provided by LGfL's broadband supplier are, apparently, vulnerable. (London Grid for Learning, a London-wide schools extranet that virtually every London school, of which there are hundreds, use for their Internet connection, DNS servers, content filtering, etc. as well as their external content host). But, knowing LGfL and the way UK IT operations that are in any way involved with government work, that's not surprising at all.

Logic is the chastity belt of the mind!

Working...