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)