“The-Cat-is-Out-of-The-Bag” DNS Bug
Wednesday July 23, 2008 at 1:48 pm CST
Posted by Ravi Balupari
There has been a lot of hush-hush recently regarding a DNS security issue finding by Dan Kaminsky. Industry wide coordinated effort led by Dan ensured that patches were released by multiple vendors. Even though the technical details of the issue were not yet made public by Dan, an inadvertent leak by Matasano Security blog seems to have given out a lot of the information regarding the issue. At this time I cannot confirm that the findings published on the leaked (and subsequently removed) blog are in fact the same details that Dan is to make public at Black Hat, but the scenarios described in there are a very serious threat to the Internet at large. As has been discussed on a number of follow-on blogs and articles, the threat emerges from two different issues with DNS protocol.
1. Prediction of Source Port and Transaction ID: DNS primarily uses UDP packets to send questions and receive answers. The image below depicts a very simple scenario where a Client is trying to look up the IP address for www.bob.com.
Also, a DNS question (request) and answer (response) UDP packets have the following simple structure.
The Client will accept any packet as an answer to its question as long as the packet is coming from the DNS Server, the source & destination ports match the destination & source port of the question packet, and most importantly the Transaction ID and Question match its question. An attacker can spoof such an answer packet as long as he can pretend to be the DNS server and also guess the source port (SP1) and transaction ID (TID1) (the destination port is usually 53). The attacker also needs to make sure his spoofed answer packet reaches the Client before the actual answer packet from the legitimate DNS Server. The image below depicts a very simple attack scenario.
2. Additional Resource Records: When a DNS server replies to a question, it can also include additional information in the answer to make future process efficient. A typical answer to a question such as “What is the IP for www.bob.com?” from Client DNS server to bob.com DNS server may look like the following image.
So the next time when Client DNS server needs to know the IP for another of bob.com domain, such as mail.bob.com, it will send a question directly to either the DNS server at 1.1.1.254 or 1.1.1.244.
Combining above two issues is what makes it more interesting. If an attacker is successful in predicting the source port and transaction ID (as in Issue 1 described above), and also inserts the additional information into the spoofed answer packet with the DNS servers pointing to the IP of his evil DNS server (as in Issue 2 described above), he can control the traffic directed for bob.com domain. Below is an image showing such a spoofed answer packet.
Although everything looks simple in theory, the two important keys to successful exploitation lie in the process for guessing the source port and the transaction IDs. In reality a large number of attempts are required by an attacker to guess the source port and the transaction ID of a DNS question before an answer from legitimate DNS server is received by the victim. Some of the DNS implementations do not completely randomize the transaction IDs. They may also use the same source port to connect to the same destination DNS server to resolve a series of questions within a short time period. Such patterns can be identified by an attacker by sending recon probes to the victim name server to lookup for domains controlled by the attacker. This combined with other strategies such as the birthday attack make it possible to guess the source port and transaction ID in a relatively short number of attempts.
Another reason to take the issue more seriously is the scenario where the victim name server is behind a NAT device that does a poor translation from the internal random source port to a sequential external source port (or any other fixed pattern source port). This just makes the job of the attacker less challenging.
It should be noted that both DNS clients and server are vulnerable to these issues although the potential impact of a successful exploitation is greater when a DNS server cache can be poisoned. If you would like to know whether your DNS server is vulnerable you can check out Dan’s DNS CHECKER or follow some of the suggestion on Sans Dairy. McAfee customers with McAfee Network Security Platform (formerly IntruShield) line of products are protected by the following attack signature id 0×40303200 that was released in sigset4.1.30.4 and sigset 3.1.67.3.
In closing, I think these are very serious issues in DNS protocol and not necessarily the only issues that Dan will be presenting at Black Hat. I guess we can wait a few more days to get complete details.
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-forgery-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.
关键在最后两段
怎样实现
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!
中文来源：
首先我们要明确的第一个问题是，DNS查询是如何进行的?对于绝大多数桌面系统来说，DNS的查询并不是由自己的机器完成的，DNS查询会提交给另 一台DNS服务器(这台服务器通常是由ISP或者公司提供)，然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓 存下来，从而提高查询效率并降低由DNS带来的流量开销(当然，在今天这种开销已经是可以忽略不计的了)。
我们可以看到的一个情况是，一台缓存DNS服务器(与权威DNS相对，这类系统提供的)下面的桌面系统可能有几百、几千、几万甚至几十万台，从 攻击的有效性而言，如果能够影响这台服务器的话，相比攻陷其下的桌面系统而言，成本便会降低很多，这种攻击我们通常称之为杠杆式攻击。
针对缓存DNS服务器的杠杆式攻击其实从很早就有研究，除了希望通过劫持网站流量来牟利的骇客之外，还有一些人使用这种方法达到一些其他的目的，例如屏蔽存在安全问题的网站，以及在一些国家存在的互联网内容净化处理等等。
本次VU# 800113是一个足以引起人们重视的问题，尽管它采用的仍然是"Cache 投毒"(cache poisoning)的方法，但这种方法采用了一些新的技巧来使其更加有效。具体来说，DNS的查询过程是由客户端(无论是桌面计算机，或是缓存DNS服 务器发起的查询)发出一个到权威DNS服务器(可能是根DNS，也可能是具体域名的权威DNS)一个UDP请求，然后等待其回应。
UDP是一种无连接的协议，为了能够识别来自不同服务器的回应，DNS协议利用端口和一个称为TXID的识别符(类似TCP的序号)来区分它 们。事 实上，早期的DNS协议实现甚至会使用固定的端口来发起DNS请求，这样一来，TXID就成了识别回应的唯一标识。由于DNS协议是在上世纪70年代设计 的，因此TXID序号只有16个bit宽，而另一方面，伪造UDP包的来源地址又很容易(因为UDP并没有提供类似TCP那样内建的防止此类攻击的机 制)，因此，攻击者只需设法让DNS缓存服务器相信自己伪造的来自权威DNS的回应是真实的，就可以达到目的了。
具体地说这种攻击包括两个部分，其一是设法让缓存DNS服务器发起新的DNS查询请求(有很多方法)，其二则是发出大量的伪造包并期待其命中，也就是在真实的权威DNS回应之前，将伪造的，但端口和TXID均能匹配的UDP回应发到缓存DNS服务器。
对于一些以线性递增方式来产生TXID的DNS客户端而言，攻击者可以自行架设一台DNS服务器、诱使对方发出DNS请求，从而大大提高攻击的 效 率。对于采用固定端口的DNS客户端来说，攻击者可以通过类似的手段来获取他关心的信息。攻击者可以用各种方式来达到这种目的，包括钓鱼邮件，也包括直接 发起查询等等。
本次VU #800113所描述的问题是，多数DNS缓存服务器实现都存在这两种弱点之一或全部。
扫一扫
437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
