bugtraq - Re: recursive DNS servers DDoS as a growing DDoS problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20060301210611.28325.qmail@securityfocus.com>
Date: 1 Mar 2006 21:06:11 -0000
From: v9@...ehalo.us
To: bugtraq@...urityfocus.com
Subject: Re: recursive DNS servers DDoS as a growing DDoS problem

While you're on the subject of the potentials of DOSing using DNS servers, I noticed several months ago some possible abuses myself, although I soon lost interest for some reason or another.

I noticed that a portion of the worlds DNS servers for some reason or another send back large amounts of duplicate replies if, and only if, the domain being resolved does not exist.

The amount of duplicates seems to range between 2 and 24(in steps of 2, 4, 8, 12, 16, 20 and 24), where each reply packet is roughly 2.5x(including IP header) larger than the original request(because of the SOA).  So, for example one request to a DNS server that sends 24 dups back would roughly equal 60x(24*2.5) amplification of data.

an example of a random server I found while scanning(12 dups from one request):
-------------------------------------------------term1# host x 68.1.2.3

...

term2# /usr/sbin/tcpdump -n src 68.1.2.3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
00:04:58.459356 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:04:58.481281 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:04:58.514411 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:01.459157 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:01.478706 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:01.512249 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:04.459512 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:04.480542 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:04.512085 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:07.458823 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:07.477374 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
00:05:07.511919 IP 68.1.2.3.53 > xxx.xxx.xxx.xxx.1865:  62623 NXDomain 0/1/0 (94)
-------------------------------------------------

At the time I noticed this I decided to create a scanner to find out how many DNS servers are susceptible to this, I found no shortage.  I ran it only for a few hours starting at 68.0.0.1 and found hundreds of DNS servers that sent back dup replies(mostly 12 and 8 dups).

I also created a DOS tool to test the theory at the time, but I see no reason to post that.

I still don't know the cause of this, just figured I would attach it on this subject for someone to decypher.

For anyone interested in the scanner, which is light on documentation:

http://fakehalo.us/dnsdbd-gp.c
http://fakehalo.us/dnsdbd.c

(the -gp.c version simply stores the ip of the dns server in character form so its easier to read by human eyes)