Re: [blag-noise] Reliable DNS Forgery in 2008: Kaminsky’s D…
|This message is part of the following thread:|
|the complete thread tree sorted by date|
> #Home Site Map Technical Support Previous Next
> 豬頭 ( [info] beezari) wrote, > @ 2008-07-22 09:15:00 > _______________________________________________________________
> Previous Entry  Add to memories!  Tell a Friend! >  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 126.96.36.199. 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 188.8.131.52. Mallory > would like the answer to be 184.108.40.206.
> 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 220.127.116.11. > 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 18.104.22.168) > *
> 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 22.214.171.124.
> 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: 126.96.36.199. 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 188.8.131.52.
> 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 184.108.40.206!
> 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 220.127.116.11. It also contained > Additional RRs pointing WWW.VICTIM.COM to 18.104.22.168. 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. > _______________________________________________________________________
> (Post a new comment) > __________________________________________________________________
> [ Home | Update Journal | Login/Logout | > Search | Viewing Options | Site Map ] > [counter?id=1196617]
> 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
|This message was posted to the following mailing lists:|
Mailing List Info | Nearby Messages
|Re: [blag-noise] howto install on drive that is known to have badblocks||Re: [blag-noise] [blag-devel] howto install on drive that is known to have badblocks|
Mailing List Info | Nearby Messages
|Re: [blag-noise] howto install on drive that is known to have badblocks||[blag-noise] 90k source|
|lists.autistici.org administrated by postmaster||Lurker (version 2.3)|