Oana Murarasu, Security Software Engineer at Ixia
Security Software Engineer at Ixia
Blog

DNS Amplification Through Root DNAME Query Responses in BIND

April 4, 2017 by Oana Murarasu

While analyzing CVE-2016-8864 for inclusion in our bi-monthly BreakingPoint updates, I discovered a new reflection- based attack in BIND's recursive DNS resolver. This amplification attack generates responses 10 or more times larger than the query sent. For every 1 megabit of traffic sent, 10 megabits is sent to the victim. We notified ISC of the issue, and their response was that it is a protocol design flaw and not a flaw in BIND. We also tested Microsoft's DNS server and it did not show the same issue. Below are the details of the issue. We will be releasing related content in our next strike pack.

The protocol abuse stems from sending a specifically crafted DNAME Resource Record. DNAME responses are used to append or change the target domain of a query, as specified in RFC 6672. As seen on Page 6 of the RFC, a queried name (QNAME) record can receive a DNAME response in which the 'owner' of the domain can specify a new target to be substituted. For instance, example.com can be replaced with example.net for a given query of foobar.example.com, and thus the new CNAME record will be foobar.example.net. This allows for easy management of multiple domains to redirect clients to the same resource (let's say you want to have all derivatives of Acme Corp's website to go to acmecorp.com, you would create DNAME records for acmecorp.net, acmecorp.co.uk, acmecorporation.com all redirect to acmecorp.com, so that subdomain queries preceded with "www", "ftp", "smtp" would all be mapped to the correct target domain).

1

Figure 1. DNAME Substitution Examples - RFC 6672

The corner case I discovered was the fact that loops and pointers can be used, and are explicitly allowed by RFC 6672 for combining CNAME and DNAME records.

2

Figure 2. Loops are allowed in RFC 6672

One example that is not listed in the RFC is the case when the owner DNAME is specified as the root domain (otherwise seen as <Root>, ".", or just \x00 in DNS traces). The target can be whatever you want, but if you choose an appropriately sized field you can 'maximize your returns' so to speak. Using a bespoke python "DNS server" to respond to a standard A query for example.com, I crafted a response packet with the following attributes for the DNAME record:

3

Figure 3. Recursive DNAME target

This specifies that the target DNAME for root is .com. Since all domains end with the root entry the DNS record then becomes example.com.com. Which then recursively becomes example.com.com.com, and then example.com.com.com.com. It's turtles all the way down, except that the good folks at ISC put a stop to the turtle length (by constraining the domain name length) at 255. The net result of this query is that the recursive server will cache the response and build large CNAME responses to any subsequent query for that domain.

4

Figure 4. Example expanded CNAME response to malformed DNAME query

Using the right crafted response from a DNS server we control, we can get a response size over 1,000 bytes. This then allows a "booter" or "stresser" to poison a recursive name server with a single request/response and then bombard the server with queries from forged sources. This is what is referred to as a reflection attack (also see this blog). We will be adding this DNAME recursive pointer response as a strike in our next ATI release, and also adding the DNS response as a part of our DDoS test lab.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.