Re: [blag-noise] Reliable DNS Forgery in 2008: Kaminsky’s D…

Delete this message

Reply to this message
Author: John Maclean
Date:  
To: blag-noise
CC: blag-devel
Subject: Re: [blag-noise] Reliable DNS Forgery in 2008: Kaminsky’s Discovery
On Tue, 22 Jul 2008 18:39:10 -0600
jebba@??? wrote:

>    #[1]Home [2]Site Map [3]Technical Support [4]Previous [5]Next

>
>    豬頭 ([6] [info] [7]beezari) wrote,
>    @ [8]2008-[9]07-[10]22 09:15:00
>        _______________________________________________________________

>
>    [11]Previous Entry   [12] Add to memories!   [13] Tell a Friend!
> [14] Next Entry
>        _______________________________________________________________

>
>    DNS bug leaks by matasano
>    Matasano security leaked out the bug and then tried to get the cat
> back into the bag.. pretty funny! :)
>    Anyway, here's the copy of their post, I am eager to experiment
> with some actual code now ;-)
>    Originally was posted at www.matasano.com/log/1103/reliable-dns-f
>    orgery-in-2008-kaminskys-discovery/

>
>    Reliable DNS Forgery in 2008: Kaminsky’s Discovery
>    from Matasano Chargen by 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 don’t want it to. The stub asks a
> real DNS server, probably run by your ISP. That server doesn’t know
>    everything. It can’t, and shouldn’t, because the whole idea of DNS
> is to compensate for the organic and shifting nature of internet
> naming and addressing. Frequently, that server has to go ask another,
> and so on. The cool kids call this “recursion”.

>
>    Responses carry another value, too, called a time to live (TTL).
> This number tells your name server how long to cache the answer. Why?
>    Because they deal with zillions of queries. Whoever wins the race
>    between Alice and Mallory, their answer gets cached. All subsequent
>    responses will be dropped. All future requests for that same data,
>    within the TTL, come from that answer. This is good for whoever
> wins the race. If Alice wins, it means Mallory can’t poison the cache
> for that name. If Mallory wins, the next 10,000 or so people that ask
> that cache where WWW.VICTIM.COM is go to 6.6.6.0.
>    3.

>
>    Then there’s that other set of DNS vulnerabilities. These require
> you to pay attention in class. They haven’t really been talked about
> since 1997. And they’re hard to find, because you have to understand
> how DNS works. In other words, you have to be completely crazy. Lazlo
> Hollyfeld crazy. I’m speaking of course of RRset poisoning.

>
>    DNS has a complicated architecture. Not only that, but not all name
>    servers run the same code. So not all of them implement DNS in
> exactly the same way. And not only that, but not all name servers are
>    configured properly.

>
>    I just described a QID attack that poisons the name server’s cache.
>    This attack requires speed, agility and luck, because if the “real”
>    answer happens to arrive before your spoofed one, you’re locked
> out. Fortunately for those of you that have a time machine, some
> versions of DNS provide you with another way to poison the name
> server’s cache anyway. To explain it, I will have to explain more
> about the format of a DNS packet.

>
>    DNS packets are variable in length and consist of a header, some
> flags and resource records (RRs). RRs are where the goods ride
> around. There are up to three sets of RRs in a DNS packet, along with
> the original query. These are:

>
>    *

>
>    Answer RR’s, which contain the answer to whatever question you
> asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)
>    *

>
>    Authority RR’s, which tell resolvers which name servers to refer
> to to get the complete answer for a question
>    *

>
>    Additional RR’s, sometimes called “glue”, which contain any
> additional information needed to make the response effective.

>
>    A word about the Additional RR’s. Think about an NS record, like
> the one that COM’s name server uses to tell us that, to find out where
>    WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to
> know, but it’s not going to help you unless you know where to find
>    NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg
>    problem. The answer is, you provide both the NS record pointing
>    VICTIM.COM to NS1.VICTIM.COM, and the A record pointing
> NS1.VICTIM.COM to 1.2.3.1.

>
>    Now, let’s party like it’s 1995.

>
>    Download the source code for a DNS implementation and hack it up
> such that every time it sends out a response, it also sends out a
> little bit of evil — an extra Additional RR with bad information.
> Then let’s set up an evil server with it, and register it as
> EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to
> names hosted at that server.

>
>    Bob innocently loads up a page with the malicious tags which
> coerces his browser resolve that name. Bob asks Alice to resolve that
> name. Here comes recursion: eventually the query arrives at our evil
> server. Which sends back a response with an unexpected (evil)
> Additional RR.

>
>    If Alice’s cache honors the unexpected record, it’s 1995 —- buy
> CSCO! —- and you just poisoned their cache. Worse, it will replace
> the “real” data already in the cache with the fake data. You asked
> where WWW.EVIL.COM was (or rather, the image tags did). But Alice
> also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver
> that points to that name server will now gladly forward you to the
> website of the beast.
>    4.

>
>    It’s not 1995. It’s 2008. There are fixes for the attacks I have
>    described.
>    Fix 1:

>
>    The QID race is fixed with random IDs, and by using a strong random
>    number generator and being careful with the state you keep for
> queries. 16 bit query IDs are still too short, which fills us with
> dread. There are hacks to get around this. For instance, DJBDNS
> randomizes the source port on requests as well, and thus won’t honor
> responses unless they come from someone who guesses the ~16 bit
> source port. This brings us close to 32 bits, which is much harder to
> guess. Fix 2:

>
>    The RR set poisoning attack is fixed by bailiwick checking, which
> is a quirky way of saying that resolvers simply remember that if
> they’re asking where WWW.VICTIM.COM is, they’re not interested in
> caching a new address for WWW.GOOGLE.COM in the same transaction.

>
>    Remember how these fixes work. They’re very important.

>
>    And so we arrive at the present day.
>    5.

>
>    Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.

>
>    This time though, instead of getting Bob to look up WWW.VICTIM.COM
> and then beating Alice in the race, or getting Bob to look up
> WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re
> going to be clever (sneaky).

>
>    Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is
>    NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM.
> Mallory has an answer. We’ll come back to it. Alice has an advantage
> in the race, and so she likely beats Mallory. NXDOMAIN for
> AAAAA.VICTIM.COM.

>
>    Alice’s advantage is not insurmountable. Mallory repeats with
>    AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime,
> perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes
> CXOPQ.VICTIM.COM is 6.6.6.0!

>
>    Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But
>    Mallory has another trick up her sleeve. Because her response
> didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained
> Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are
> in-bailiwick: Bob is in fact interested in VICTIM.COM for this query.
> Mallory has combined attack #1 with attack #2, defeating fix #1 and
> fix #2. Mallory can conduct this attack in less than 10 seconds on a
> fast Internet link.
>    _______________________________________________________________________

>
>                           ([15]Post a new comment)
>      __________________________________________________________________

>
>    [ [16]Home | [17]Update Journal | [18]Login/[19]Logout |
> [20]Search | [21]Viewing Options | [22]Site Map ]
>    [counter?id=1196617]

>
> References
>
>    1. http://www.livejournal.com/
>    2. http://www.livejournal.com/site/
>    3. http://www.livejournal.com/support/
>    4.
> http://www.livejournal.com/go.bml?journal=beezari&itemid=141796&dir=prev
> 5.
> http://www.livejournal.com/go.bml?journal=beezari&itemid=141796&dir=next
> 6. http://beezari.livejournal.com/profile 7.
> http://beezari.livejournal.com/ 8.
> http://beezari.livejournal.com/2008/ 9.
> http://beezari.livejournal.com/2008/07/ 10.
> http://beezari.livejournal.com/2008/07/22/ 11.
> http://www.livejournal.com/go.bml?journal=beezari&itemid=141796&dir=prev
> 12.
> http://www.livejournal.com/tools/memadd.bml?journal=beezari&itemid=141796
> 13.
> http://www.livejournal.com/tools/tellafriend.bml?journal=beezari&itemid=141796
> 14.
> http://www.livejournal.com/go.bml?journal=beezari&itemid=141796&dir=next
> 15. http://beezari.livejournal.com/141796.html?mode=reply 16.
> http://www.livejournal.com/ 17. http://www.livejournal.com/update.bml
> 18. http://www.livejournal.com/login.bml 19.
> http://www.livejournal.com/logout.bml 20.
> http://www.livejournal.com/site/search.bml 21.
> http://www.livejournal.com/manage/settings/ 22.
> http://www.livejournal.com/site/
> _______________________________________________ blag-noise mailing
> list blag-noise@???
> https://www.autistici.org/mailman/listinfo/blag-noise


Woah! Something tells me that this was the blog post that was quickly
rm'd mentioned here...
http://www.wired.com/politics/security/commentary/securitymatters/2008/07/securitymatters_0723