############################################################################ ##### 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)
