Message-ID: <002e01c8f3eb$f0f17800$d2d46800$@org>
Date: Fri, 1 Aug 2008 18:33:21 +0300
From: "AR" <ar@...urebits.org>
To: <full-disclosure@...ts.grok.org.uk>, <pen-test@...urityfocus.com>,
	<bugtraq@...urityfocus.com>
Cc: asamhuri@....gr, ntufar@....gr, gtabanji@....gr, whadidi@....gr,
	sghaida@....gr
Subject: DNS Multiple Race Exploiting Tool

############################################################################
#####
Subject:	DNS Multiple Race Exploiting Tool release
Homepage:	http://www.securebits.org/dnsmre.html
Download:	http://www.securebits.org/tools/dns_mre-v1.0.tar.gz
OS:		The tool runs on Linux
Target OS:	Tested against windows 2003 server
############################################################################
#####

 01 Introduction
 02 Features
 03 Extra Notes
 04 Running the Tool
 05 Example
 06 Credits

01 Introduction
---------------
 DNS Multiple Race Exploiting Tool exploits an inherent bug in the
implementation
of DNS Cache. The result of this exploitation is cache poisoning/overwriting
with 
new entries. The exploitation happens by querying a DNS server, that either 
supports recursion or is configured with forwarders, for non-existent
hostnames 
for a target domain. Along with the queries are fake reply/replies with
static 
Transaction ID(s). Every query will generate another query from the DNS
server 
with a random TXID. If one of the replies contains this specific TXID, the
cache 
is poisoned. Because the replies are sent directly after the query, they
will 
arrive at the DNS server much earlier than the legitimate reply from some
Name 
Server.

 This attack was discovered and announced by Dan Kaminsky of Doxpara
Research in 
July 2008.

02 Features
-----------
 A. The tool can attack both unpatched DNS systems as well as patched DNS 
systems. Attacking a patched system requires a much longer time than an 
unpatched system though.

 B. The tool can launch two modes of attack; one is 
against DNS server that supports recursion, and the second mode is against
DNS 
server configured with forwarder DNS. The attack modes differ in the "flags"

carried in the DNS fake replies. Since a DNS with server forwarder(s) sends
a 
query with the "recursion desired" bit set, the reply has to have this bit
set, 
too. Also, the reply has to have the "recursion available" bit set. On the
other 
hand, a DNS server with recursion sends query with the recursion bit unset
(i.e. 
iteration query), the reply has to have this bit unset, too.

 C. The tool spoofs the source IP address of the queries. This is useful if
the 
attacker does not want leave any trace of his IP address on the server.

 D. The tool utilizes CNAME Record Type to inject the false entry. The way
the 
poisoning is implemented is by sending two answer Resource Records (RRs):
One is 
a CNAME RR, and the second is an A record. Every fake reply contains
something 
like:
          [1] abdc.example.com is a CNAME of IN Class for www.example.com
          [2] www.example.com is an A of IN Class for IP 11.22.33.44

 E. The tool sends multiple fake replies with different TXIDs to increase
the 
probability of hitting the correct TXID. This is useful in reducing the time

needed to generate a "hit". For a server that does not randomize the source
port 
number, the maximum number of iterations needed is 65546 (an average would
be
32768). However, by sending 10 to 15 TXIDs, for example, the probability of 
making a "hit" is higher in a shorter time; an average of ~3000 iterations
are 
needed.

03 Extra Notes
--------------
[*] There is a sleeping time between sending the Query and the Replies. The 
currently configured value of this time is 100 Milliseconds. This is
important 
because during the test, I found that if the reply is sent directly along
the 
query, the fake reply would arrive at the server before the server sends its

own query and the fake reply would eventually be ignored.

 [*] There is another sleeping time between every iteration (query+replies).

This "time" is meant to control the amount of packets per second. Currently,

this "time" is 100 Milliseconds.

 [*] The tool does not create the packets in every iteration. It creates the

needed packets (1 query and multiple replies based on the number of TXIDs)
at 
once at the beginning. For later iterations, portions of the packets are
modified 
and re-sent again. This is done for faster operation and to use the least
amount 
of memory.

 [*] I am currently researching the most optimized and efficient way to
poison a 
DNS system that randomizes the source port address. This includes the
threshold 
number of TXIDs beyond which an attack would be unsuccessful, or sending
multiple 
queries first before sending their corresponding fake replies, and so on. 

If you have some ideas and suggestions, please write to me at 
<ar[at]securebits[dot]org>

04 Running the Tool
-------------------
 The command syntax is:
     #./dns_mre [options] <entry_fqdn> <entry_ip>

 The options are:

 -t <target>	The target DNS server to poison (required)
 -n <nameserver>	The Name Server used to impersonate (required)
 -s <spoofed_ip>	A spoofed client IP address (optional)
 -p <port>		Source port address used by target to send queries
                  (required)
 -y <type>		Type of the attack (optional; default 1)
			  0 for Patched Systems   
			  1 for Unpatched Systems
 -m <mode>		Attack mode (optional; default 0)
			  0 Attacking DNS servers configured with forwarders
			  1 Attacking DNS Servers that perform recursive
queries
 -x <no_txids>	Number of Transaction IDs to use (optional; default 15)

05 Example
----------
To attack the DNS server 11.22.33.44 that sends queries from port 1103 and 
configured with a forwarder to 44.33.22.11, and inject the entry 
www.domain.org => 3.2.1.4:

./dns_mre -t 11.22.33.44 -n 44.33.22.11 -p 1103 -x 15 -m 0 -s 22.22.22.22 \
www.example.com 88.55.44.48

#################################################################
#               DNS Multiple Race Exploiting Tool               #
#################################################################

[*] Attacking server:              11.22.33.44
[*] Injecting the record:          www.domain.org => 3.2.1.4
[*] Replies are from:              44.33.22.11
[*] Replies are delivered to port: 1103
[*] Number of TXIDs to use         15
[*] IP address used in queries:    22.22.22.22
[*] Attack mode: Forwarding DNS Server
[*] The attack is against an unpatched system

# Initializing...[OK]
# Preparing query raw packet....[OK]
# Preparing 15 reply raw packet(s)....[OK]
# Checking if the server is already poisoned...No, it is not poisoned
# Launching the Attack...
            maximum iternation 65535
            wait time between each iteration is 100 milliseconds
            wait time between the query and reply is 100 milliseconds
############################### 3000 iterations
Checking to see if the server is poisoned ....Not yet
############################## 6000 iterations
Checking to see if the server is poisoned ....YES
 ** Attack is Successful **

06 Credits
----------

 - Dan kaminsky for originally discovering the attack and for the nice
Webinar on 
July 24th

 - Wafa, Saddam, Nicolai, and Ghassan for their support and help


--
AR
Independent Security Reseacher
Securebits (http://www.securebits.org)


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists