Description
ECE568 – Computer Security Lab #4: DNS Cache Poisoning Setup For this lab, we will be using the patched DNS server program called BIND (Berkeley Internet Name Domain). BIND is installed at /share/copy/ece568f/lab4/bind9 on the ECF machines. 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: mkdir -p lab4/etc mkdir -p lab4/var/run/named/ cp /share/copy/ece568f/lab4/bind9/etc/rndc.conf lab4/etc cp /share/copy/ece568f/lab4/bind9/etc/named.conf lab4/etc 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 Once you have chosen a port number for rndc, modify bold-faced parameters in rndc.conf and named.conf : rndc.conf: options { default-key “rndc-key”; default-server 127.0.0.1; default-port ; }; named.conf: options { dump-file “/lab4/dump.db”; listen-on port { any; }; query-source port ; pid-file “/lab4/var/run/named/named.pid”; session-keyfile “/lab4/var/run/named/session.key”; }; controls { inet 127.0.0.1 port allow { 127.0.0.1; } keys { “rndc-key”; }; }; Step 3: Start the DNS server You can run BIND by running script at /share/copy/ece568f/lab4/run_bind.sh : /share/copy/ece568f/lab4/run_bind.sh -c 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: pip install scapy==2.3.3 –user Take care to ensure that the version of scapy being installed is as shown above ie. 2.3.3. You may encounter warnings about SNIMissingWarning and InsecurePlatformWarning . You can safely ignore them. Check if scapy is installed correctly: $ python Python 2.6.6 (r266:84292, Aug 9 2016, 06:11:56) [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)] on linux2 Type “help”, “copyright”, “credits” or “license” for more information. >>> import scapy >>> No output and the absence of an import error (ignore any warnings) indicates that we can proceed further. When using scapy, you may get a lot of following errors: Exception RuntimeError: ‘maximum recursion depth exceeded while calling a Python object’ in <type ‘exceptions.AttributeError’> ignore d 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 In this lab, you will be performing a DNS Cache Poisoning attack as described in Lecture . More details on the attack can be found here: 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. 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 BIND server. For question 1-3, create a file called part1.txt and write to it in the following format: 1. 2. : 2. : 2. …. 3. : 3. …. Note – there may be more than 1 name/mail server for ecf.utoronto.ca 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. Due to security concerns in ECF, packet sniffing is disabled. However, we can simulate it by forcing DNS queries to go through proxies. Your goal is to write a proxy server that accepts DNS queries from dig and forwards them to the BIND server we setup earlier. It should also receive a DNS reply from the BIND server and forward it back to dig (unmodified). 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 cp /share/copy/ece568f/lab4/dnsproxy_starter.py Your proxy should be run as python dnsproxy_starter.py –port –dns_port 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: dig example.com Spoof the DNS reply such that example.com’s IPv4 address is 5.6.6.8 instead and change its name servers to ns1.dnsattacker.net , ns2.dnsattacker.net . Furthermore, remove all data from additional sections. 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 –dns_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 cp /share/copy/ece568f/lab4/part4_starter.py You can run it with: ./part4_starter.py –dns_port –query_port 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: /share/copy/ece568f/lab4/bind9/sbin/rndc -c etc/rndc.conf querylog Attack Verification: Inspect the BIND server’s cache to determine if it is poisoned: /share/copy/ece568f/lab4/bind9/sbin/rndc -c etc/rndc.conf dumpdb -cache less /tmp/dump.db // should be your cache dump location A successful attack output should contain following: Submission Instruction You may work on this lab individually or in groups of two. Your code must be entirely your own original work. The assignment should be submitted by 11:59:59pm on Thursday, December 10th. Please submit a README file that contains your name(s), student number(s), and email(s) at the top, along with explanations for each part. You should submit part1.txt , README , dnsproxy_starter.py (for part2 and 3) and part4_starter.py . submitece568f 4 README part1.txt dnsproxy_starter.py part4_starter.py README format: #first1 last1, studentnum1, e-mail1 #first2 last2, studentnum2, e-mail2 Part 1 Explanation: … Note: Please put your explanations in the README , not in the part#.txt files. If your files are not formatted as instructed, you may lose marks. We have provided a submission checking script to help ensure that the automarker will process your files correctly: /share/copy/ece568f/bin/check568_lab4 Your solutions will be tested on the ECF machines. Please ensure that you test your solutions on these machines prior to submission.
