Remote dns attack

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.