Posted 7/8/08 by Robert from the 'UDP 4 lyfe' departmentA pretty nasty DNS vulnerability has been discovered in 81 products by Dan Kaminsky. This vulnerability type seems to be the same described by Amit Klein and involves abusing the PRNG involved in transactions on DNS queries. Long story short if you run a vulnerable caching DNS server you can have your cache poisoned. From CERT"The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID. Some flawed implementations may use a smaller number of bits for this transaction ID, meaning that fewer attempts will be needed. Furthermore, there are known errors with the randomness of transaction IDs that are generated by a number of implementations. Amit Klein researched several affected implementations in 2007."
The Problem
The root cause is a fundamental, well known, weakness in the DNS protocol. DNS uses UDP, a stateless protocol. A DNS server will send a request in a single UDP packet, then wait for a response to come back. In order to match request and response, a number of parameters are checked:who sent the response? Was it the DNS server we sent the request to? for this particular response, do we have an outstanding request? each request uses a unique and random query ID. The response has to use the same query ID. The response has to be sent to the same port from which the request was sent. Only if all this matches, the response is accepted. The first valid response wins. If an attacker is able to guess the query id and the source port, the attacker is able to send a fake response, which will be cached by the DNS server.How likely is it to "guess" the query id and the source port? One would think, its not that easy. The query ID is 16 bits long, allowing for 65536 options. The source port could be anything above 1024 which again would allow for another 64512 options. It is easy to guess which DNS server is expected to reply, as it has to be a valid DNS server for the respective domain. A reasonable DNS server should respond in less then a second, allowing for about 1 second to send the spoofed response.At least for BIND, the source port only changes whenever you restart it. Once restarted it keeps using the same source port.Ideally, one would think that it would take millions of packets per second to successfully spoof the response. However, the problem is in the details. A DNS server can not use any port to source the query. It may not use a port commonly used by outbound connections, or a port reserved by a server. This is an issue attacked by today's patches. As of today, DNS servers used a rather small set of ports to source requests. This is the actual new finding. The patch will increase the pool of source ports available to DNS queries. To make things worse: the real DNS server may be silenced using DDoS attacks.Over the past few months, we had a couple patches (again both for Microsoft as well as for BIND) addressing the randomness of the query ID.
The root cause is a fundamental, well known, weakness in the DNS protocol. DNS uses UDP, a stateless protocol. A DNS server will send a request in a single UDP packet, then wait for a response to come back. In order to match request and response, a number of parameters are checked:who sent the response? Was it the DNS server we sent the request to? for this particular response, do we have an outstanding request? each request uses a unique and random query ID. The response has to use the same query ID. The response has to be sent to the same port from which the request was sent. Only if all this matches, the response is accepted. The first valid response wins. If an attacker is able to guess the query id and the source port, the attacker is able to send a fake response, which will be cached by the DNS server.How likely is it to "guess" the query id and the source port? One would think, its not that easy. The query ID is 16 bits long, allowing for 65536 options. The source port could be anything above 1024 which again would allow for another 64512 options. It is easy to guess which DNS server is expected to reply, as it has to be a valid DNS server for the respective domain. A reasonable DNS server should respond in less then a second, allowing for about 1 second to send the spoofed response.At least for BIND, the source port only changes whenever you restart it. Once restarted it keeps using the same source port.Ideally, one would think that it would take millions of packets per second to successfully spoof the response. However, the problem is in the details. A DNS server can not use any port to source the query. It may not use a port commonly used by outbound connections, or a port reserved by a server. This is an issue attacked by today's patches. As of today, DNS servers used a rather small set of ports to source requests. This is the actual new finding. The patch will increase the pool of source ports available to DNS queries. To make things worse: the real DNS server may be silenced using DDoS attacks.Over the past few months, we had a couple patches (again both for Microsoft as well as for BIND) addressing the randomness of the query ID.
How bad is it?
If you run a caching DNS server, patch it soon. I wouldn't say "today, while ignoring sane patch management". But check with your vendor and follow their guidance. The world is not going to end today. It will in fact end in 2 1/2 years from today (different story ;-) ). But this is something you have to fix soon. Right now, the US-CERT advisory lists a handful of vulnerable products and quite a few "unknowns".
Eventually we all may have to break down and fix DNS. DNSSEC is an extension to DNS asking for cryptographic authentication. However, it requires a PKI infrastructure which at this point doesn't exist. There is not much to be gained from implementing DNSSEC on your own (but by all means: try it out and see how it works).
One thing to carefully test is your firewall. We already heard about issues with Zonealarm and MS08-038. However, it is possible that other firewalls will think that something is wrong if your DNS server all for sudden keeps jumping ports.
Where can I find out more?
CERT:www.kb.cert.org/vuls/id/800113
Internet Software Consortium (BIND): http://www.isc.org/sw/bind/bind-security.php
Dan Kaminski on Martin McKeay's Podcast: http://media.libsyn.com/media/mckeay/nsp-070808-ep111.mp3
DNSSEC resources:
DNSSEC Overview: http://www.dnssec.org
DNSSEC resources:
DNSSEC Overview: http://www.dnssec.org
DNSSEC Deployment Initiative: http://www.dnssec-deployment.org
DNSSEC HowTo: http://www.nlnetlabs.nl/dnssec_howto
-----
UPDATE:
The CERT announcement implies strong randomization of the source port and transaction id makes the attack improbable. "Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation"
isc.org warns busy DNS resovlers could be impacted by their patch so they recommend the beta release version.
"The patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. The beta releases include optimized code that will reduce the impact in performance to non-significant levels."
Johannes B. Ullrich, Ph.D. SANS Technology Institute - http://www.sans.edu
-----
UPDATE:
The CERT announcement implies strong randomization of the source port and transaction id makes the attack improbable. "Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation"
isc.org warns busy DNS resovlers could be impacted by their patch so they recommend the beta release version.
"The patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. The beta releases include optimized code that will reduce the impact in performance to non-significant levels."
Johannes B. Ullrich, Ph.D. SANS Technology Institute - http://www.sans.edu
No comments:
Post a Comment