ECE568 Lab 4- DNS Cache Poisoning Solution

Setup
We next describe how to setup and configure BIND on your ECF machine.
Step 1: Setup configuration files
There are 2 configuration files you need to set for this lab. They are rndc.conf and named.conf at
/share/copy/ece568f/lab4/bind9/etc . RNDC is short for Remote Name Daemon Control, which is useful for dumping BIND’s server cache to check whether our attack has been successful or not. You need to specify a few parameters in these files.
Therefore, create a local directory and copy them to it:

Step 2: Specify BIND configuration parameters
We will be using two executables from BIND, named and rndc. named executable is the BIND server and rndc is the command-line administration tool. named uses specific port (specified in rndc.conf and named.conf ) to communicate with rndc. Furthermore, named uses two ports, listen-on port and query-source port to communicate with clients and external name servers. Since multiple users can work on ECF workstations, make sure you randomly pick port numbers that would not collide with other students. Also, you must pick port numbers greater than 1024 as ports lower than that are reserved and requires root privileges.

Here are descriptions of parameters that you need to specify before you can run named server: dump-file: path where named will dump its cache listen-on port: port number named will use to listen for DNS queries query-source port: port number BIND will use to send its outgoing queries to external DNS servers pid-file: named will write its process id here session-keyfile: named will use this file for DNSSEC controls port: port number for rndc default-port: port number for rndc



Step 3: Start the DNS server

Step 4: Install Scapy
Scapy is a powerful tool for packet manipulation. To install Python packages locally, we will be using pip. Do the following to install scapy locally:



No output and the absence of an import error (ignore any warnings) indicates that we can proceed further.

This error should not affect your lab and you can safely ignore them.
Further information on how to use scapy could be found at: https://scapy.readthedocs.io/en/latest/ (https://scapy.readthedocs.io/en/latest/)
Note: scapy’s sending functions such as: sr1() , send() will not work in ECF environment. These functions require sudo privileges which is disabled in ECF lab. Instead, you can use scapy to: a) build packets, b) modify packets. For sending and receiving packets, use Python’s socket library. Example for using Python’s socket library + scapy for building DNS packet is in part4_starter.py .
Resources
An Illustrated Guide to the Kaminsky DNS Vulnerability (http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html) Analysis of the Cache Poisoning attack (http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.172.5025&rep=rep1&type=pdf)
Part 1: Getting familiar with dig
dig is a useful tool for sending DNS queries. Unless otherwise specified, dig will by default, try each of servers listed in
/etc/resolv.conf .
Direct dig to the default DNS server on the ECF machines (not the BIND server) and figure out the following:
1. What is the IPv4 address of ecf.utoronto.ca?
2. What are the names of name servers of ecf.utoronto.ca and their IPv4 addresses?
3. What are the names of mail servers of ecf.utoronto.ca and their IPv4 addresses?
4. Now direct dig to your local BIND server and repeat the above queries. Check to see if the output matches your results from 1-3.

Part 2: Write a DNS proxy that sits between dig and local DNS server
If we can inspect DNS queries and their replies, it is possible to forge them to attack users. Imagine redirecting a DNS request of google.com to a malicious server.
Refer to the man page (https://linux.die.net/man/1/dig) to learn how to call dig with the appropriate options in order to point it to the proxy instead of the BIND server. Check to see if you receive the same output as when you point dig directly to the BIND server.
We have provided some starter code that can be used to build the proxy for Parts 2 and 3 in dnsproxy_starter.py Copy this into your local directory as follows

Part 3: Spoof DNS reply using the DNS proxy
Your goal for this exercise is to use the proxy created in Part 2 to intercept and forge DNS replies. Look up example.com by sending:

We suggest using scapy to manipulate DNS packets.
Information about DNS packet format can be found at: http://www.networksorcery.com/enp/protocol/dns.htm
(http://www.networksorcery.com/enp/protocol/dns.htm)
Your proxy should be run as python dnsproxy_starter.py --port <port #> --dns_port <port #> --spoof_response
Part 4: DNS cache poisoning attack
We will be implementing a DNS cache poisoning attack, also known as the Kaminsky attack.

Figure 1: DNS query process
Figure 1 illustrates a complete DNS query process when a user submits a DNS query for example.com’s IP address. Aside from returning www.example.com's IP address, the local DNS server (i.e. BIND) will also cache example.com’s name server address. Therefore, when the user sends a DNS query for another address in example.com domain (e.g. mail.example.com), the local BIND server will directly ask for its IP from the cached example.com’s name server, illustrated in Figure 2.

Figure 2: DNS query process when example.com DNS Server is cached
Imagine what would happen if an attacker forges DNS reply from example.com name server before the actual reply (i.e.
message #3) reaches the local BIND server. The attacker can return arbitrary IP address of mail.example.com and furthermore overwrite example.com name server address that is cached at the local BIND server to a new fake address! (e.g. ns.dnsattacker.net)
However, this is more difficult than it sounds because DNS replies include a transaction ID which must match with the ID from the corresponding DNS query. Transaction IDs for DNS queries are randomly generated and not visible to attackers.
Furthermore, sending DNS queries to resolve the same domain name again will not be effective because the first result will be cached. For example, if you send DNS query for www.example.com twice, the 2nd DNS query will not trigger DNS query to example.com name server. This makes it impossible for the attacker to forge another response for the same domain name until the cache entry expires and thus, makes the attack impractical.
Attack Procedure:
Here are outline for the attack procedure, to successfully poison your BIND server:
1. Query the BIND server for a non-existing name in example.com, such as twysw.example.com, where twysw is a random name.
A. Since the mapping is not available in the BIND server’s cache, it will send out a DNS query to the name server of the example.com domain.
2. While the BIND server waits for the reply from example.com’s name server, flood it with a stream of spoofed DNS replies, each with a different transaction ID, hoping one is correct.
A. Even if the spoofed DNS reply fails, it does not matter because the next time, the attacker will query a different name.
3. Repeat steps 1-2 until the attack succeeds!
Goal:
Spoof DNS replies to overwrite example.com’s name server’s address to ns1.dnsattacker.net , ns2.dnsattacker.net . You need to add fake NS (i.e. name server) record in your spoofed DNS reply to overwrite example.com’s name server address. Use starter code part4_starter.py .
Copy this into your local directory as follows

You can run it with:

Notes:
1. BIND is patched such that you do not need to fake IP address of the spoofed packet to match with the IP address of the remote name server (i.e. example.com). Spoofing IP address requirees sudo privilege which is not allowed in ECF workstations.
2. BIND is patched such that the transaction IDs are 8 bits instead of 16 bits. This greatly increases the chance of guessing the correct transaction ID. For the attack to work with 16 bit IDs, the attacking script need to use other techniques to send spoofed messages much faster, such as programming in faster languages, use multi-threading.
3. There are several ways to verify that the attack worked. DO NOT send DNS query to BIND asking what is the NS for example.com, before the attack has worked. It will make BIND cache NS for example.com and your attacking script will no longer work (BIND will simply disregard your spoofed message to change NS for example.com). It is fine to send the DNS query after you have verified that the attack has worked. Use the method we describe in the next section.
4. You can send a command through RNDC to enable logging queries received by your BIND server:

Attack Verification:
Inspect the BIND server’s cache to determine if it is poisoned:

A successful attack output should contain following:

Submission Instruction

We have provided a submission checking script to help ensure that the automarker will process your files correctly:

Your solutions will be tested on the ECF machines. Please ensure that you test your solutions on these machines prior to submission.