Remote DNS Cache Poisoning Attack Lab

Remote DNS Cache Poisoning Attack Lab

Due by midnight November 4, 2020

DNS (Domain Name System) is the Internet’s phone book; it translates hostnames to IP addresses (and vice versa). This translation is through DNS resolution, which happens behind the scene. DNS attacks manipulate this resolution process in various ways, with an intent to misdirect users to alternative destinations, which are often malicious. The objective of this lab is to understand how such attacks work. You will first set up and configure a DNS server, and then you will try various DNS attacks on the target that is also within the lab environment.

The difficulties of attacking local victims versus remote DNS servers are quite different. Therefore, we have developed two labs, one focusing on local DNS attacks, and the other on remote DNS attack. This lab focuses on remote attacks.

Lab Learning Objectives

• Understand DNS and how it works • Conduct remote DNS cache poisoning attack • Be familiar with Scapy DNS class

Lab Setup

The main purpose of this lab is on remote DNS attacks, and our attacking target is a local DNS server. Obviously, it is illegal to attack a real machine, so we need to set up our own DNS server to conduct the attack experiments. The lab environment needs three separate machines: one for the victim, one for the DNS server, and the other for the attacker. We will run these three virtual machines on one physical machine. All these VMs will run the pre-built Ubuntu 16.04 VM image. Figure below illustrates the setup of the experiment environment.

For the sake of simplicity, we put all these VMs on the same network. In the following sections, we assume that the user machine’s IP address is 10.0.2.18, the DNS Server’s IP is 10.0.2.16 and the attacker machine’s IP is 10.0.2.17. Please be noted that your VMs’ IP addresses may be different from those

shown in the figure. We need to configure the user machine and the local DNS server; for the attacker machine, the default setup in the VM should be sufficient.

Lab Instructions

1. First, in order to have three VMs, we will clone the Ubuntu 16.04 VM. In this lab, the original Ubuntu 16.04 VM will serve as attacker. We will clone the VM for the Victim. Make sure that Ubuntu 16.04 VM is powered off. Right click Ubuntu 16.04 in VMWare Workstation, select Manage then select Clone….

Click Next> on the next screen. Select The current state in the virtual machine radio button, then click the Next button.

In the next window, select Create a full clone radio button, then click the Next button.

In the next Window, enter Victim as the virtual machine name, then click the Finish button.

Repeat the same process to clone a VM for the DNS Server. To differentiate three different VMs, let change the background from the default blue color to a different one. Right click the desktop and select Change Desktop Background. In the next screen, choose the wallpapers you like.

2. In this step, we will configure the Victim VM. On the Victim VM, we need to use 10.0.2.16 as the local DNS server (by default, the DNS server program is already running in the SEED VM). This is achieved by changing the resolver configuration file (/etc/resolv.conf) of the Victim machine, so the server 10.0.2.16 is added as the first nameserver entry in the file, i.e., this server will be used as the primary DNS server. Unfortunately, our provided VM uses the Dynamic Host Configuration Protocol (DHCP) to obtain network configuration parameters, such as IP address, local DNS server, etc. DHCP clients will overwrite the /etc/resolv.conf file with the information provided by the DHCP server.

One way to get our information into /etc/resolv.conf without worrying about the DHCP is to add the following entry to the /etc/resolvconf/resolv.conf.d/head file. Open the file by

$ sudo gedit /etc/resolvconf/resolv.conf.d/head

Add the following entry to /etc/resolvconf/resolv.conf.d/head

nameserver your_ DNS_Server_VM’s_IP_Address

Run the following command for the change to take effect

$ sudo resolvconf -u

If the resolvconf is not installed on the current VM, run the following command to install it.

$ sudo apt-get install resolvconf

The content of the head file will be prepended to the dynamically generated resolver configuration file. Normally, this is just a comment line (the comment in /etc/resolv.conf comes from this head file).

After you finish configuring the user machine, use the dig command to get an IP address from a hostname of your choice. From the response, please provide evidences to show that the response is indeed from your local DNS server. If you cannot find the evidence, your setup is not successful.

3. In this step, we will configure the local DNS server. For the local DNS server, we need to run a DNS server program. The most widely used DNS server software is called BIND (Berkeley Internet Name Domain), which, as the name suggests, was originally designed at the University of California Berkeley in

the early 1980s. The latest version of BIND is BIND 9, which was first released in 2000. We will show how to configure BIND 9 for our lab environment. The BIND 9 server program is already installed in our pre-built Ubuntu VM image. The configurations listed in the following Tasks 1, 2 and 3 haven been already implemented in the current Ubuntu 16.04 VM. They are listed just for information purpose.

Task 1: Configure the BIND 9 server. BIND 9 gets its configuration from a file called /etc/bind/named.conf. This file is the primary configuration file, and it usually contains several "include" entries, i.e., the actual configurations are stored in those included files. One of the included files is called /etc/bind/named.conf.options. This is where we typically set up the configuration options. Let us first set up an option related to DNS cache by adding a dump-file entry to the options block.

options {

dump-file "/var/cache/bind/dump.db";

};

The above option specifies where the cache content should be dumped to if BIND is asked to dump its cache. If this option is not specified, BIND dumps the cache to a default file called /var/cache/bind/named_dump.db. The two commands shown below are related to DNS cache. The first command dumps the content of the cache to the file specified above, and the second command clears the cache.

$ sudo rndc dumpdb -cache // Dump the cache to the sepcified file

$ sudo rndc flush // Flush the DNS cache

Task 2: Turn off DNSSEC. DNSSEC is introduced to protect against spoofing attacks on DNS servers. To show how attacks work without this protection mechanism, we need to turn the protection off. This is done by modifying the named.conf.options file: comment out the dnssec-validation entry, and add a dnssec-enable entry.

options {

# dnssec-validation auto;

dnssec-enable no;

};

Task 3: Fix the Source Ports. DNS servers now randomize the source port number in their DNS queries. This s makes the attacks much more difficult. Unfortunately, many DNS servers still use predictable source port number. For the sake of simplicity in this lab, we assume that the source port number is a fixed number. We can set the source port for all DNS queries to 33333. This can be done by adding the following option to the file /etc/bind/named.conf.options.

query-source port 33333

Task 4: Remove the example.com Zone. If you did the “Local DNS Attack Lab”, you have probably configured the local DNS server to host the example.com domain. In this lab, this DNS server will not host that domain, so please remove its corresponding zone from /etc/bind/named.conf.

Task 5: Start DNS server. We can now start the DNS server using the following command. Every time a modification is made to the DNS configuration, the DNS server needs to be restarted. The following command will start or restart the BIND 9 DNS server.

$ sudo service bind9 restart

4. In this step, we need to configure the attack machine, so it uses the targeted DNS server (i.e., the local DNS server) as its default DNS server. Please see Step 2 for the instruction. Make sure that the network configuration for the Attacker VM is "NAT". Like in the local DNS cache poisoning attack, you need to use your last name to construct a fake domain. For example, in my case, the domain I have will be yue.com.

5. The main objective of Pharming attacks is to redirect the user to another machine B when the user tries to get to machine A using A’s host name. For example, assuming www.example.com is an online banking site. When the user tries to access this site using the correct URL www.example.com, if the adversaries can redirect the user to a malicious web site that looks very much like www.example.com, the user might be fooled and give away his/her credentials to the attacker.

In this task, we will target the ucmo.edu domain. The goal of the attack is to launch the DNS cache poisoning attack on the local DNS server, such that when the user runs the dig command to find out any IP address in the ucmo.edu domain (for example, www.ucmo.edu), the local DNS server will end up going to the attacker’s name server ns.your_lastname.com to get the IP address, so the IP address returned can be any number that is decided by the attacker. As results, the user will be led to the attacker’s web site, instead of the authentic www.example.com.

There are two tasks in this attack: cache poisoning and result verification. In the first task, you need to poison the DNS cache of the user’s local DNS server, such that, in the local DNS server’s DNS cache, ns.your_lastname.com is set as the name server for the ucmo.edu domain, instead of the domain’s registered authoritative name server. In the second task, you need to demonstrate the impact of the attack. More specifically, they need to run the command "dig www.ucmo.edu" from the user’s machine, and the returned result must be a fake IP address.

In this task, the attacker sends a DNS query request to the victim DNS server, triggering a DNS query from the local DNS server. The query may go through one of the root DNS servers, the .EDU DNS server, and the final result will come back from ucmo.edu’s DNS server. In case that ucmo.edu’s name server information is already cached by the local DNS server, the query will not go through the root or the .EDU server. This situation is more common, so we will use it as the basis to describe the attack mechanism.

While the local DNS server waits for the DNS reply from ucmo.edu’s name server, the attacker can send forged replies to the local DNS server, pretending that the replies are from ucmo.edu’s name server. If the forged replies arrive first, it will be accepted by the local DNS server. The attack will be successful.

If you have done the local DNS attack lab, you should realize that those attacks assume that the attacker and the local DNS server are on the same LAN, i.e., the attacker can observe the DNS query message. When the attacker and the local DNS server are not on the same LAN, the cache poisoning attack becomes more difficult. The difficulty is mainly caused by the fact that the transaction ID in the DNS response packet must match with that in the query packet. Because the transaction ID in the query is usually randomly generated, without seeing the query packet, it is not easy for the attacker to know the correct ID.

Obviously, the attacker can guess the transaction ID. Since the size of the ID is only 16 bits, if the attacker can forge K responses within the attack window (i.e. before the legitimate response arrives), the probability of success is K over 216. Sending out hundreds of forged responses is not impractical, so it will not take too many tries before the attacker can succeed.

However, the above hypothetical attack has overlooked the cache effect. In reality, if the attacker is not fortunately enough to make a correct guess before the real response packet arrives, correct information will be cached by the local DNS server for a while. This caching effect makes it impossible for the attacker to forge another response regarding the same domain name, because the DNS server will not send out another DNS query for this domain name before the cache times out. To forge another response on the same domain name, the attacker has to wait for another DNS query on this domain name, which means he/she has to wait for the cache to time out. The waiting period can be hours or days.

Dan Kaminsky came up with an elegant technique to defeat the caching effect. With the Kaminsky attack, attackers will be able to continuously attack a DNS server on a domain name, without the need for waiting, so attacks can succeed within a very short period of time. In this task, we will try this attack method. The following steps outline the attack.

1. The attacker queries the local DNS Server for a non-existing name in example.com, such as twysw.ucmo.edu, where twysw is a random name

2. Since the mapping is unavailable in the local DNS server’s DNS cache, the local DNS server sends a DNS query to the name server of the example.com domain

3. While the local DNS server waits for the reply, the attacker floods the local DNS server with a stream of spoofed DNS response, each trying a different transaction ID, hoping one is correct. In the response, not only does the attacker provide an IP resolution for twysw.ucmo.edu, the attacker also provides an “Authoritative name servers” record, indicating ns.dnslabattacker.net as the name server for the example.com domain. If the spoofed response beats the actual responses and the transaction ID matches with that in the query, the local DNS server will accept and cache the spoofed answer, and thus the local DNS server’s DNS cache is poisoned

4. Even if the spoofed DNS response fails (e.g. the transaction ID does not match or it comes too late), it does not matter, because the next time, the attacker will query a different name, so the local DNS server has to send out another query, giving the attack another chance to do the spoofing attack. This effectively defeats the caching effect

5. If the attack succeeds, in local DNS server’s DNS cache, the name server for example.com will be replaced by the attacker’s name server ns.dnslabattacker.net. To demonstrate the success of this attack, you need to show that such a record is in the local DNS server’s DNS cache

Implementing the Kaminsky attack is quite challenging, so we break it down into three sub-tasks. This subtask focuses on spoofing DNS requests. In order to complete the attack, we (as attackers) need to trigger the target DNS server to send out DNS queries, so we have a chance to spoof DNS replies. Since we need to try many times before we can succeed, we have to automate the process. The first step is to write a program to send out DNS queries to the target DNS server, each time with a different hostname in the question field. Your job is to write this program and demonstrate using Wireshark that your queries can trigger the target DNS server to send out DNS queries on behalf of you.

6. Right after each query is sent out, the attacker needs to forge a large number of DNS response packets in a very short time window, hoping that one of them has the correct transaction ID and it reaches the target before the authentic response does. Since our target is ucmo.edu, we need to spoof the replies from

this domain’s name server. You first need to find out the IP addresses of ucmo.edu’s legitimate name servers (it should be noted that there are multiple name servers for this domain).

We need to spoof DNS replies in the Kaminsky attack. Performance is essential for the success of the attack, so it is better to write the program in C. The dilemma is that it is quite an effort to construct DNS query and reply packets using C. Therefore, it is more desirable to use the hybrid approach proposed by the textbook author.

On the Attacker VM, open Firefox and surf to the Blackboard. Download generate_dns_query.py, generate_dns_reply.py and attack.c. You will use generate_dns_query.py to generate a DNS query packet template, generate_dns_reply.py to generate the DNS response packet templates. You will use both templates and modify them to create the spoofed query and response packets in attack.c. For each spoofed DNS query, the program needs to generate 100 spoofed DNS responses each with a different transaction id.

If your attack is successful, when the local DNS server receives the DNS query, it searches for ucmo.edu’s NS record in its cache, and finds ns.yue.com. It will therefore send a DNS query to ns.yue.com. However, before sending the query, it needs to know the IP address of ns.yue.com. This is done by issuing a separate DNS query. That is where we get into trouble.

The domain name yue.com is a fake one which obviously does not host the zones for the ucmo.edu domain. The local DNS server will soon find out about that, and mark the NS entry invalid, essentially recovering from the poisoned cache. One may say that when forging the DNS response, we can use an additional record to provide the IP address for ns.yue.com. Unfortunately, this additional record will not be accepted by the local DNS server. Please think about why and give your explanation in your lab report (hint: think about the zones).

To avoid spending money to purchase a real domain, we can use a trick to ask the local DNS server to forward the query to our attacker VM. In the Local DNS server VM, let’s open /etc/bind/named.conf by typing

$ sudo gedit /etc/bind/named.conf

Add the following zone entry.

Here 10.0.2.3 is the IP address for my Attacker VM, your VM’s IP address maybe different. Next, we will set up the yue.com zone and the fake ucmo.edu zone on the Attacker VM. Let’s open /etc/bind/named.conf by typing

$ sudo gedit /etc/bind/named.conf

Enter the following two zone entries.

Open Firefox and surf to the Blackboard, download the yue.com.db and ucmo.edu.db zone files. Modify the zone files accordingly based on your last name and Attacker VM’s IP address. After that copy both files to the /etc/bind/ directory by

$ sudo cp Downloads/ucmo.edu.db /etc/bind/

$ sudo cp Downloads/YLN.com.db /etc/bind/

Make sure to replace YLN with your actual last name. Restart the DNS server on the Attacker VM by

$ sudo service bind9 restart

You may omit some of the above steps if you already set up your zone from the local DNS cache poisoning lab.

Now, let’s test to make sure that both zones are set correctly. On the attacker VM, type

$ dig @127.0.0.1 www.ucmo.edu

Repeat the same test on another domain (for example, your_lastname.com). A typical reason the zone file is not set up correctly is the permission on the zone file. It can be easily fixed by issuing the following command.

$ sudo chmod a+r /etc/bind/ucmo.edu.db

From the User VM, we will run additional commands to ensure that our setup is correct.

Get the IP address of ns.your_lastname.com by typing

$ dig ns.your_lastname.com

When we run the following dig command, the local DNS server will forward the request to the Attacker VM due to the forward zone entry added to the local DNS server’s configuration file. Therefore, the answer should come from the your_lastname.com.zone file that we set up on the Attacker VM. If this is not what you get, your setup has an issue. Please describe your observation in your lab report.

Get the IP address of www.ucmo.edu. Two name servers are now hosting the ucmo.edu domain, one is the domain’s official name server, and the other is the Attacker VM. We will query these two name servers and see what response we will get. Please run the following two commands (from the User VM), and describe your observation.

$ dig www.ucmo.edu

$ dig @ns.your_lastname.com www.ucmo.edu

The objective of the DNS cache poisoning attack is to get the victims to ask ns.your_lastname.com for the IP address of www.ucmo.edu.

7. All the VMs are set for the lab in this step. You need to run your attack program to complete the Kaminsky attack. Before attacking, make sure that the local DNS Server’s cache is empty. You can flush the cache using the following command.

$ sudo rndc flush

First run your attack script using the root privilege on the Attacker VM., while the attack script is running, on the local DNS server VM, check the cache on the local DNS server to find whether the cache is indeed poisoned. On the local DNS server, run

$ sudo rndc dumpdb -cache

$ sudo cat /var/cache/bind/dump.db | grep your_lastname

To make your life easy, you can download a shell script check.sh from the Blackboard to automate this task. Make sure to add the file extension .sh to the file when you save the file on your VM. (I have to remove it since Blackboard blocks uploading of a script file). You need to modify the script to replace your last name with my last name.

Clearly, we can see that the cache has been poisoned. To verify the damage caused by the remote DNS cache poisoning, on the User VM, let’s find the IP address for another hostname in the ucmo.edu domain. On the user VM, run

$ dig xyz.ucmo.edu

It is obvious that we have compromised the entire ucmo.edu domain.

8. Power off three VMs. Right click the Victim, select Manage, then select Delete from Disk.

Repeat the same process to delete another cloned VM.

Lab Report

• please include your name and 700# at the beginning of your report • please upload your report to the Blackboard by the due date • only word or pdf format is acceptable

1. provide necessary screenshots for steps 5, 6 and 7

Submit the following two items separately to the Blackboard

• A lab report with all necessary screenshots • A zip file with all your Python and C codes