DNS Proxy Helps; NAT/PAT Devices Exacerbate Issue
Severity: Medium
18 July, 2008
Update:
Last week, we published an alert about some DNS protocol vulnerabilities that could affect any software or networking devices that run DNS servers, and to a lesser extent, DNS clients. By sending your DNS server (or client) a series of specially crafted DNS queries and/or responses, an attacker could poison your DNS server’s cache with arbitrary IP addresses, thus potentially forcing your users to visit arbitrary, malicious web sites.
This alert adds one new wrinkle pertaining to this issue, then explains a DNS proxy configuration that may help mitigate the risk of DNS cache poisoning attacks in general. First, the new wrinkle:
Possible Negative Impact of NAT
The DNS vulnerability relies in part upon the lack of randomization in the source port used in DNS queries. The patch released by DNS vendors last week forces DNS applications and devices to use random source ports (among other things), which should help make it harder for attackers to impersonate legitimate DNS traffic.
However, in a post to the Full-Disclosure mailing list, security researchers pointed out that network address translation (NAT) or port address translation (PAT) applications and devices could potentially undo one of the benefits provided by your vendor’s DNS fixes. When a NAT/PAT device receives a packet, such as a DNS request, it resends that packet using source ports of its choice. If your NAT/PAT device doesn’t select the source port randomly, attackers could predict the source port necessary to send a response that would trick the NAT device. The NAT device would then format the attacker’s response properly to send to your DNS server, regardless of whether the server was patched.
Many NAT/PAT devices, including WatchGuard’s Firebox models, select source ports incrementally rather than randomly. While incremental source ports aren’t as bad as static source ports, they are still predictable. As a result of these DNS protocol flaws, many NAT/PAT vendors have realized that they need to update their products to select random source ports. WatchGuard plans to add randomization of sources ports to its Firebox UTM devices as soon as possible; our engineers are currently investigating the feasability of providing this fix in an upcoming release. (You should also contact the vendors of any other NAT/PAT devices in your network, to see how they are affected.)
Note that non-random source ports make up just one aspect of this DNS flaw. Attackers must also predict DNS transaction IDs in order to poison your DNS cache. So even if your NAT/PAT device reverses one aspect of the DNS fix, the rest of the fixes will still mitigate the risk of this DNS attack.
Now for the good news: WatchGuard’s DNS proxy can reduce the risks of Internet-based DNS cache poisoning attacks.
How the Firebox DNS Proxy Helps
An attacker can only poison your DNS cache if you have configured your DNS server for recursion. Recursive DNS servers answer DNS queries for ANY domain. If they don’t know the answer to a particular DNS request, they send their own DNS queries to other authoritative DNS server in order to find the answers. Because recursive DNS servers launch their own DNS queries, attackers have an opportunity to send spoofed replies that poison those servers’ DNS caches. However, if your server doesn’t allow for recursive DNS queries — rather, it answers queries about your domain only — then attackers have much less opportunity to lie to your server.
As a security measure, most DNS administrators configure their DNS servers not to use recursion when receiving DNS queries from the Internet. They may allow recursive requests from internal users, but not from external users. We highly recommend that you configure your DNS server in this way.
WatchGuard’s DNS proxy can help you set this up for all devices running WatchGuard System Manager (WSM) and Fireware, as follows:
§ In Policy Manager, click Setup => Actions => Proxies… Double-click the DNS-Incoming proxy action, and highlight Query Names under the Categories section. Here, you can control which domain name queries your DNS server will accept.
§ By default, the DNS-Incoming proxy action contains an asterisk wildcard under Query Names, which means it accepts queries for all domains. You want it to accept queries only for your domain. So highlight the asterisk and press Remove.
§ Now you simply need to add your domain or domains to the list of Query Names the DNS-Incoming proxy action accepts. Enter these domains in the Pattern dialog and press Add. Then press OK and then Close (you may be asked to rename this new DNS-Incoming proxy action).
§ Now you can add this new action to a DNS-Proxy policy. Set the policy as Allowed from Any-External to the IP address of your DNS server, and make sure to apply your new DNS-Incoming action to your DNS-Proxy policy.
Now, Internet-based users will only be able to make DNS requests that have to do with your domain name. Meanwhile, your internal users will still be able to make recursive DNS requests. This simple proxy setting should prevent external attackers from exploiting most DNS cache poisoning attacks against your DNS server.
In the latest episode of Radio Free Security: Firebox Special, the LiveSecurity content team goes over the latest DNS cache poisoning attack, and this proxy workaround, in greater detail. If you have further questions pertaining to this issue, we highly recommend listening to this episode.
Finally, as a convenient reference, our original DNS alert from last week is reprinted below. You can also find it in the LiveSecurity Latest Broadcasts archive.
Summary:
§ This vulnerability affects: All software and networking devices that run DNS servers; to a lesser extent, software or devices with DNS clients
§ How an attacker exploits it: By sending your DNS server (or client) a series of specially crafted DNS queries and/or responses
§ Impact: The attacker could poison your DNS server’s cache with arbitrary IP addresses, thus forcing your users to visit arbitrary, malicious web sites
§ What to do: Deploy the appropriate updates from your DNS vendors as quickly as possible
Exposure:
The Domain Name Service (DNS) is a standard protocol used to translate IP addresses into human readable names. For instance, when you visit www.watchguard.com in your web browser, your DNS server translates that name into an Internet routable IP address registered to our company.
In a coordinated effort launched yesterday, CERT released an advisory warning of some overarching design flaws in the way many products implement the DNS protocol. These flaws could lead to a significant security vulnerability called DNS cache poisoning. Since the design flaws lie within the DNS protocol itself, the vulnerabilities can affect any software or networking device that runs a DNS server. They could even affect, to a lesser extent, software and devices that have a DNS client. Here’s a short list of the more common vendors and products affected by these DNS flaws:
§ Microsoft Windows (both its DNS Server and Client components, as described in yesterday’s alert)
§ Cisco IOS products
§ ISC’s Bind
§ Red Hat Linux
§ Sun Microsystems SunOS
For a complete list of affected vendors, see the Systems Affected section of CERT’s advisory.
Dan Kaminsky, a well-known DNS security researcher, discovered a way to exploit three DNS protocol design flaws. In order to give the world time to patch, Kaminsky and the vendors involved have not released any significant technical details describing how an attacker might exploit these vulnerabilities. They only generally outline the three design flaws as follows:
§ Insufficient randomization of a DNS query’s transaction ID field — When making DNS queries, DNS Servers and clients should use a strong random number (one that’s not easy to predict) for a field in the query called the transaction ID. Otherwise, an attacker might guess the transaction ID and can use that information to help falsify a DNS response in lieu of a legitimate response.
§ Multiple outstanding Resource Record requests — If your DNS server gets multiple requests to look up the same Resource Record (RR) (domain name data) at the same time, it should only generate one RR request and then share that result with all the requestors. However, many DNS implementations will generate multiple identical requests for the same RR. This condition leads to the possibility of something known as a birthday attack, which greatly increases the probability of successful DNS spoofing attacks.
§ Fixed source port in DNS queries — Many DNS implementations use the same source port for their DNS queries. The lack of source port randomization can make it easier for attackers to spoof DNS replies.
By combining these three vulnerabilities in some manner which Kaminsky hasn’t yet explained in detail, an attacker can launch successful DNS cache poisoning attacks against your DNS server (and in some classes, specific DNS clients). This means an attacker can arbitrarily make any domain name point to any IP address he wants to. He could, for example, make www.bankofamerica.com point to the IP address of a malicious phishing site in an attempt to steal your banking credentials. Or he might redirect the domain name for any popular web site to point to a malicious drive-by download site that forces arbitrary malware onto your computer. In short, if an attacker can poison your DNS, you’ll never know if you’re seeing the correct version of the site you want to visit.
While Internet-wide DNS cache poisoning poses a very critical and sobering threat, the lack of technical details in CERT and Kaminsky’s alert has lead many security experts to question the true severity of these DNS flaws. In general, vulnerabilities that rely on lack of randomization of certain elements often take significant effort for attackers to exploit. While some vulnerabilities can make it easier for attackers to predict random elements, just how predictable those elements are depends greatly on the technical details of the flaws. Without knowing how Kaminsky combined these flaws in his attack, we can’t say exactly how severe a risk they pose. However, since these vulnerabilities could potentially pose a very serious risk, and do affect so many products and devices, we highly recommend you patch all your affected DNS software and hardware as soon as you can.
Solution Path:
Many of the vendors affected by these vulnerabilities have released updates to mitigate the risk of these DNS protocol design issues. For a complete list of affected vendors, and links to those vendors’ updates, visit the Systems Affected section of CERT’s advisory. When you click the vendors’ links, you’ll get directed to another page that supplies you with the link to that vendor’s update. Keep in mind that at the time of this writing, many vendors have not yet responded to CERT’s coordinated release effort. CERT lists these vendors with the status of “Unknown.” You may want to occasionally revisit the Systems Affected section of CERT’s advisory to see if any vendors are changed to “Vulnerable.”
Also, if you are curious about whether or not your DNS servers are affected by this flaw, visit Dan Kaminsky’s DoxPara Research page. In the top-right corner of the main page, Kaminsky has provided an automated DNS Checker tool that will test whether or not these vulnerabilities affect the DNS servers assigned to your computer. The tool requires JavaScript to work, so be sure to enable it for DoxPara if you’ve used tools to block it.
Note: If you applied the patches from yesterday’s consolidated Windows alert, you have already applied Microsoft fix for this DNS issue.
For All WatchGuard Users:
As far as we can tell, these attacks travel as normal-looking DNS traffic, which you must allow if you want your users to access the Internet. Therefore, the vendor’s patches are your best solution.
Status:
Many vendors have released patches to fix these vulnerabilities.
References:
§ CERT’s DNS advisory
§ Microsoft’s DNS advisory
§ Cisco’s DNS advisory
§ Bind’s DNS advisory
Dan Kaminsky’s DoxPara Research Page
Posted by bardissi 
Posted by bardissi 
Posted by bardissi 