DNS Reflection Update and Odd Corrupted DNS Requests, (Wed, Sep 25th)

Occasionally, I tend to check in on what reflective DNS denial of service attacks are doing. We usually see steady levels of attacks. Usually, they attempt to use spoofed requests for ANY records to achieve the highest possible amplification. Currently, I am seeing these two records used (among others):

ANY nlrb.gov

The response for this query may be up to 5,826 bytes in size. With a query payload size of 37 bytes, this leads to a rather impressive implication. The original name server appears to do the right thing, and it ignores EDNS0, but that, of course, doesn't help with open resolvers.

ANY ncca.mil

This domain is a bit odd. I only receive empty responses for ANY, NS, or other queries I tried. Maybe this domain was fixed after it got abused for DDoS attacks.

ANY fnop.net

The response for this domain is also truncated. Likely also fixed.

"Fixing" Amplification via ANY records

There are a few other defensive techniques that show up more often. Google's domain name service returns a "Not Implemented" error for ANY queries:

% dig ANY dshield.org

; <<>> DiG 9.10.6 <<>> ANY dshield.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 27119 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

A few years ago, RFC 8492 was published which spe,cifically allows truncating ANY responses. I see more and more domains returning the "HINFO" record "RFC8492" instead of the full ANY response. 

Corrupt ANY Requests

But, while looking into the DNS responses, I also saw some odd malformed queries.

These are odd and somewhat interesting to a packet-focused person:

(or as text:

09:37:49.571420 IP 45.148.10.248.18177 > 70.91.145.9.53: 17767+ [1au] ANY? o^Cco. (33)     0x0000:  4500 003d 762e 4000 f211 0291 2d94 0af8  E..=v.@.....-...     0x0010:  465b 9109 4701 0035 0029 0000 4567 0100  F[..G..5.)..Eg..     0x0020:  0001 0000 0000 0001 046f 0363 6f00 00ff  .........o.co...     0x0030:  0001 0000 29ff ff00 0000 0000 00         ....)........

I highlighted the IP header in yellow and underlined it with a dashed line. The UDP header is underlined using dots and highlighted in green. In red and enclosed in a box, you will see the hostname.

A couple of observations to start about the IP and UDP headers:

1. The TTL is large (0xf2, or 242), exceeding more normal starting TTLs of 128 and 64.
2.  The UDP checksum is 0, which is valid for IPv4 and just indicates not to verify the UDP checksum

But the real interesting part is the hostname. DNS encodes hostnames in a zero terminated length-value format. Each label is preceded by a one byte length field. For example, "isc.sans.edu" would be encoded as "03"isc"04"sans"03"edu"00".

The sequence above,

04 6F 03 63 6F 00 

implies a single label with a length of 4 bytes. But one byte of the label is "03", which is not a printable ASCII character and not a valid byte value for a hostname. It is more likely that the author of this denial of service tool "messed up" and meant to say:

01 6F 02 63 6F 00

Which would be a valid domain, "o.co", and it could work to amplify queries. The ANY record for the domain is short but contains invalid data:

;; QUESTION SECTION: ;o.co.                IN    ANY

;; ANSWER SECTION: o.co.            900    IN    NSEC    \000.o.co. A NS SOA MX TXT RRSIG NSEC DNSKEY  

The hostname in the NSEC record starts with a NULL byte! No idea what this is about. Let me know if you can figure it all out :)

One more reason to love DNS. There is always a surprise waiting for you.

If you are interested in a video walkthrough, see this YouTube recording:

 

 

--- Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.