Course of Network Security

! Kaminsky attack Laboratory

Authors: Daniele Berti, Genc Hoxha, Joel Ngatouo, Kamdoum Sottang Patrick

May 04.2016

!1

1. Introduction 3

2. Difference Between Kaminsky attack and DNS cache poisoning 4

3. Netkit 5

4. Architecture and DNS hierarchy 6

5. Starting the laboratory 8

5.1 Exploring the configuration 9

5.2 Experiment settings 13

6. Kaminsky attack lab explanation 21

6.1 Exploring and Performing the Kaminsky attack 23

!2

1. Introduction

In July 2008 United States Computer Emergency Readiness Team (CERT)

announced that Kaminsky had discovered a fundamental flaw in the Domain Name

System (DNS) protocol. The flaw could allow attackers to easily perform cache

poisoning attacks on most nameservers causing the name server to return an

incorrect IP address, diverting traffic to the attacker's computer (or any other

computer). Poisoning attacks on a single DNS server can affect the users serviced

directly by the compromised server. Kaminsky attack nowaday is the higher level of

DNS Cache poisoning.

In this report we are going to show the difference between the two kinds of attack

(DNS Cache poisoning and Kaminsky attack) and give the students basic

understanding about how Kaminsky attacks are performed using existing tools.

The students will perform the attacker role as well as the victim role who tries to get

some website.

!3

2. Difference Between Kaminsky attack and DNS cache poisoning

The cache poisoning attack consists in creating a fake RR for a certain website and

successfully inject it into the cache of a DNS server. So from that moment on, if the

client asks for that specific website it will be redirected where the attacker wanted

and not to the right one.

The Kaminsky vulnerability can lead to a cache poisoning attack but the opposite is

impossible. The attacker rather than replacing an A record (Returns a 32-bit IPv4

address, most commonly used to map hostnames to an IP address of the host)

replaces an NS record (Delegates a DNS zone to use the given authoritative name

servers). This way the attacker can get control over any (sub)domain:

- b.a.website.com

- a.website.com

- website.com

- .com

! Figure 1: Kaminsky attack

!4

3. Netkit

Understanding computer networks without performing practical experiments is really

difficult, not to say it is almost impossible. Unfortunately, setting up a networking lab

can be very expensive. So in order to create an understandable network architecture

we decided to use netkit which is an environment for setting up and performing

networking experiments at low cost and with little effort. It allows to create several

virtual network devices (full-fledged routers, switches, computers, etc.) that can be

easily interconnected in order to form a network on a single PC.

Networking equipments are virtual but feature many of the characteristics of the real

ones, including the configuration interface.

Emulating a network with Netkit is a matter of writing a simple file describing the link-

level topology of the network to be emulated and some configuration files that are

identical to those used by real world networking tools.

Netkit then takes care of starting (emulated) network devices and interconnecting

them as required.

Netkit exploits open source software (mostly licenced under GLP) and is heavily

based on the User Mode Linux (UML) variant of the Linux Kernel.

!5

4. Architecture and DNS hierarchy

Basically the architecture of our network is composed by client (pc1), server http

(pc2), (pc3) and dns’ (see Figure 2 below).

!

Figure 2: the dns name hierarchy

Client (pc1.luroma3.org):

is the machine which will make the http request to the server pc2.nanoinside.net/

pc3.nanoinside.net.

Server (pc2.nanoinside.net/pc3.nanoinside.net):

are the machines in which we have installed apache with an html page. Domain Name Service (DNS)

- Allows to convert names into ip address;

- The name system is distributed over several nodes that are hierarchically

organized to form a tree;

- Each node in the hierarchy corresponds to a name;

- A domain in the name system is a subtree;

- A node in the hierarchy may be delegated to handle names for a particular

zone.

!6

! Figure 3: dns zone hierarchy Authoritative Nameserver (DNSNET, DNSORG): for every zone, somebody

has to maintain a file of the hostnames an IP address associations. This is generally

an administrative function performed by a human, and in most cases one machine

has this file. It’s the zone master. At part 5 of this report (see figure 11) you can see a

typical configuration of an Authoritative Nameserver with Bind.

DNS ROOT is the top-level DNS zone in the hierarchical namespace of the

Domain Name System (DNS) of the Internet.

Recursive Nameserver (DNSLUG, DNSNANO): is a nameserver that’s

willing to go out on the internet and find the results for zones that it is not

authoritative for, as a service to its clients. Not all name servers are configured to

provide recursive service, or are limited to just trusted clients. At the part 5 of this

report we are going to see the configuration of a recursive name server (DNSLUG).

!7

5. Starting the laboratory

In order to make the students understand either the DNS hierarchy and the kaminsky

attack, we decided to implement two laboratories, the first one to understand the

DNS hierarchy of our network architecture and the second one for understanding the

attack. To start the first laboratory (which does not include the attack) open a

terminal and follow the steps as below:

● Login as super-user: sudo -s

● Password:root

● Enter in Lab directory: cd netkit-lab_dns

● Start the Lab: lstart

The Lab is configured to:

● Start all the 8 virtual machines (vms)

● Automatically configure the network interfaces

● Automatically configure the name servers

● Automatically start the name server software (bind) on each name server

Once the Lab started you will see all the vms as it shown in Figure 4.

! Figure 4: Lab. 1

!8

As you see in the Figure 5, we have configured the network in such a way that all the

vms lie on the same ethernet: 192.168.0.0/24.

As a consequence the first part of IP address 192.168.0 of each vm will be the same. For example, pc1.lugroma3.org’s IP address is: 192.168.0.111, pc2.nanoninside.net:

192.168.0.222.

Dnslug (192.168.0.11) is the recursive server for pc1.lugroma3.org and dnsnano

(192.168.0.22) is the recoursive server for pc2.nanoninside.net and

pc3.nanoinside.net (192.168.0.224).

Whenever the pc1 will attempt to reach any other machine, will have to ask first his

recursive server (dnslug) which is going to find the specific machine for him.

The same pc2 and pc3 will have to ask to their recursive server (dnsnano).

! Figure 5: network configuration

5.1 Exploring the configuration

Before starting to see how the Lab works let us explore a little bit its configuration.

We start from PC’s configuration which consist of specification on default name

servers. Type cat /etc/reslov.conf on the terminal of pc1, pc2, pc3.

!9

! Figure 6: PC configuration

Name server configuration instead specifies:

● Associations between zones and name servers

● Information about the root name servers

● Authoritative information

● Associations between names and IP addresses

Type cat /etc/bind/named.conf on the dnslug terminal.

!

Figure 7: dnslug, associations between zones and name servers

!10

Type cat /etc/bind/db.root on the dnslug terminal.

! Figure 8: dnslug, information about the root name servers

! Figure 9: available record types

Type cat /etc/bind/db.org.lugroma3 on the dnslug terminal, as show in Figure 10 a.

and b.Let’s see figure 10 a., b. and understand further the configuration:

● 1. Time to live in seconds: determines how long a resource record should be

cached

● 2. Start of the authority record: a zone data file can contain only one SOA

record

● 7. Serial number: determines how recent the information is; influences all data

in the zoneconventional format:YYYYMMDDNN (year, month, day, number of changes

within that day)

!11

● 8. Refresh interval: tells a slave how often to check that data for this zone is

up to data

● 10. Slave expire time: if the slave fails to contact the master for this amount of

time, it considers the zone data too old and stops giving answers about it

! Figure 10 a.: associations between names and IP addresses

! Figure 10 b.: associations between names and IP addresses

!12

Type cat /etc/bind/db.org on the dnsorg terminal as in the below figure to see the

authority (SOA record dnsorg.org) for a subdomain (dnslugroma3.org).

! Figure 11: authority for a subdomain

5.2 Experiment settings Having explored the configuration let’s now see how the Lab works. From

pc1.lugroma3.org we will request the html page of pc2.nanoninside.net/

pc3.nanonisnide.net on which we have installed apache that allows us to get the

html page on this machines. Inside the html page we have written a simple line as in

the below figure to distinguish between them.

Type cat /var/www/index.html on pc2 and pc3 to see their html page.

! Figure 12: html page on pc2 and pc3 Before requesting the html page type on pc3: tcpdump -n -t port domain to listen the

communication on the ethernet in order to see the flow of dns query/answer.

!13

! Figure 13: listening on eth0

To request the html page type on terminal of pc1:

● links (to open the browser on the machine)

● Press “Enter” button

● ctrl+G ( To write URL we are searching for)

● http://pc2.nanoinside.net/

● Press “Enter” button

Note: Links is the browser of netkit that performs the http request and visualize the

content of the page

!14

! Figure 14: enter the URL from the browser of pc1

As we see in the below picture we successfully managed to visit the web page of

pc2.

! Figure 15: web page of pc2

Let’s see now how the dns query/answer works by looking at pc3 which at the

meanwhile was listening the communication on the ethernet.

!15

! Figure 16: dns query/answer

Steps of dns query/answer:

1. (ID: 48207) pc1.lugroma3.org (192.168.0.111) asks to its recursive server

dnslug.lugroma3.org (192.168.0.11) to give the IP address of

pc2.nanoinside.net

2. (ID: 2681) As dnslug.lugroma3.org doesn’t have pc2.nanoinside.net in the

cache asks to the dnsroot (192.168.0.5)

3. (ID: 2681) dnsroot answers to dnslug.lugroma3.org with 0 answers / 1

authority (=nameserver) record (dnsnanon.nanoinside.net) / 2 additional

records (dnsnano.nanoinside.net’s IP address 192.168.0.22 and an OPT

recrod ) (0/1/2)

4. (ID: 20985) dnslug.lugroma3.org then asks to dnsnano.nanoninside.net to

give the IP address of pc2.nanoinside.net

5. (ID: 20985) dnsnet.net (192.168.0.2) answers to dnslug.lugroma3.org with 0

answers / 1 authority (=name server) record (dnsnano.nanoninside.net) / 2

!16

additional records (dnsnano.nanoinside.net’s IP address 192.168.0.22 and an

OPT record) (0/1/2) 6. (ID: 58034) dnslug.lugroma3.org then asks to dnsnano.nanoninside.net to

give the IP address of pc2.nanoinside.net

7. (ID: 58034) dnsnano.nanoninside.net answers to dnslug.lugroma3.org with 1

answer (pc2.nanoinside.net’s IP address 192.168.0.222) / 1 authority

(=nameserver) reord (dnsnano.nanoinside.net) / 2 additional records

(dnsnano.nanoinside.net’s IP address 192.168.0.22 and an OPT record)

(1/1/2)

8. (ID: 48207) dnslug.lugroma3.org (192.168.0.11) answers to pc1.lugroma3.org

(192.168.0.111) with 1 answer (pc2.nanoinside.net IP address 192.168.0.222)

/ 1 authority (=nameserver) reord (dnsnano.nanoinside.net) / 0 additional

record (1/1/0)

Note: each couple (query/answer) has an unique ID.

! Figure 17: dns query/answer illustration If we try to request again the html of pc2 will see that the steps to get there will be

less.

The reason is that now in the cache of the recursive server (dnslu.lugroma3.org) is

recorded the IP address of pc2.nanoinside.net (see on Figure 18.)

!17

! Figure 18: dns query/answer illustration in case the record is in the cache

Steps of the dns query/answer in case:

1. (ID: 41115) pc1.lugroma3.org (192.168.0.111) asks to its recursive server

dnslug.lugroma3.org (192.168.0.11) to give the IP address of

pc2.nanoinside.net

2. (ID: 41115) dnslug.lugroma3.org (192.168.0.11) having already in the cache

the record answers to pc1.lugroma3.org (192.168.0.111) with 1 answer

(pc2.nanoinside.net IP address 192.168.0.222) / 1 authority (=nameserver)

reord (dnsnano.nanoinside.net) / 0 additional record (1/1/0)

!Figure 19: dns query/answer illustration in case the record is in the cache

!18

Let us now visit the web page of pc3.nanoinside.net by tying as before on pc1’s

terminal:

● Ctrl + G

● the URL of pc3 : http://pc3.nanoinside.net/

Steps of the dns query/answer:

1. (ID: 7832) pc1.lugroma3.org (192.168.0.111) asks to its recursive server

dnslug.lugroma3.org (192.168.0.11) to give the IP address of

pc3.nanoinside.net

2. (ID: 41115) dnslug.lugroma3.org (192.168.0.11) having already in the cache

the record of dnsnano.nanoinside.net (192.168.0.22) which is responsible for

the zone asks to it directly for pc3.nanoinside.net

3. (ID: 41115) dnsnano.nanoninside.net answers to dnslug.lugroma3.org with 1

answer (pc3.nanoinside.net’s IP address 192.168.0.224) / 1 authority

(=nameserver) reord (dnsnano.nanoinside.net) / 2 additional records

(dnsnano.nanoinside.net’s IP address 192.168.0.22 and an OPT record)

(1/1/2) 4. (ID: 7832) dnslug.lugroma3.org (192.168.0.11) answers to pc1.lugroma3.org

(192.168.0.111) with 1 answer (pc3.nanoinside.net IP address 192.168.0.224)

/ 1 authority (=nameserver) reord (dnsnano.nanoinside.net) / 0 additional

record (1/1/0)

! Figure 20: dns query/answer in case that we know who is responsible for the zone

!19

! Figure 21: dns query/answer illustration in case that we know who is responsible for the zone

!20

6. Kaminsky attack lab explanation

Before starting with kaminsky attack let us change the typology of tcpdump to full

protocol in order to understand better where kaminsky attack should be

implemented. First of all we have to close the lab by typing lcrash in order to clear

the cache and restart everything all over again. After repeating the steps as before

(for pc2.nanoninside.net) and changing the tcpdump command into tcpdump -vvv -s

0 -l -n port 53 we should get the following dns query/answer (see Figure 22).

! Figure 22: dns query/answer where to implement the attack

In Figure 22 is emphasized the query that dnslug makes towards dnsnet (in red) and

the answer of dnsnet to dnslug (in green). With kaminsky attack we want to take

control over the dnsnano zone inside which are found pc2 and pc3.

To do so we have to sniff the query that dnslug makes towards dnsnet and parse the

ID together with all the parameters that we need in order to create a fake packet.

Then we will send the fake packet to dnslug making it believe that the packet was

!21

sent from dnsnet and giving him hacker dns’ IP address instead of dnsnano’s one.

After that dnslug will ask to the hacker_dns for pc2.nanoinside.net.

!

Figure 23: kaminsky attack network

We have modified the network adding three more machines, pc4 (192.168.0.223),

dnshacker (192.168.0.23) and pc5 (192.168.0.225) as seen in Figure 23.

The role of dnshacker is the one to pretend to be dnsnano and taking its place, pc4

will take the place of pc2/pc3 and pc5 will be the one that will listen the

communication and will perform the attack by sending the fake packet to dnslug.

On pc4 we have installed apache that allows us to get the html page on this

machine. (see figure 27)

On pc5 we install scapy which is a packet manipulation tool for computer networks,

written in Python. It can forge or decode packets, send them on the wire, capture

them, and match requests and replies. It can also handle tasks like scanning, trace

routing, probing, unit tests, attacks, and network discovery.

We have written a script (see figure 24) which will be run from pc5. The script

consists in listening the ethernet and sniffing the packets coming from dnslug

!22

towards dnsnet, parsing all the parameters that are needed to create the fake

packet, create it and then send it towards dnslug.

Figure 24: script attakc.py

Now that we have understood how the labs are configured and the dns query/answer

let us close again the first lab by typing lcrash on the main terminal (ubuntu terminal),

exit the directory by typing cd and dedicate the next section to perform the kaminsky

attack.

6.1 Exploring and Performing the Kaminsky attack

To start the second Lab:

● Enter in the Lab directory: cd netkit-lab_dns_kaminsky

● Start the Lab: lstart (being already a super user)

Let’s see first the configuration of the new machines.

!23

Type cat /etc/bind/db.net.hacker on the dns_hacker machine

Figure 25: hacker.net configuration, a modified version of nanoinside.net’s configuration

Whenever someone will attempt to contact pc2 or pc3 it will be redirected to pc4 by

dns_hacker as we see in figure 25.

Type cat /etc/resolv.conf on the terminal of pc4

Figure 26: pc4 and pc5 configuration

!24

Type cat /var/www/index.html to see the html page of pc4

Figure 27: pc4’s html page

Let us start with the attack. We will repeat the same steps as in paragraph 5.2 for

visiting the web page of pc2 from pc1. First we have to make the dnsnet not to

respond (stop working) by typing the following command on its terminal: rndc stop;

to see the dns query/answer traffic as before type tcpdump -vvv -s 0 -l -n port 53 on

pc3’s terminal; to launch the attack on pc5’s terminal first install scapy and then

launch the attack.py script. Type the following commands:

● cd ..

● cd hosthome

● cd scapy-2.3.1

● python setup.py install (to install scapy)

● cd ..

● python attack.py (to run the script)

Now pc5 is listening the ethernet and is waiting for the communication from dnslug to

dnsnet. As soon as this communication will take place, pc5 will sniff all the

parameters that are needed to create the fake packet, will create and send it towards

dnslug making it believe that the packet was coming from dnsnet.

In order to request the html page type on terminal of pc1:

● links (to open the browser on the machine)

● Press “Enter” button

● ctrl+G ( To write URL we are searching for)

● http://pc2.nanoinside.net/

● Press “Enter” button

!25

As you see from the figure 28 we got the web page of pc4 instead of pc2’s one. The

attack was successful.

Figure 28: pc4’s web page

Let us go to pc3 terminal and understand more what happened. Before go to pc5

and see the ID of the query made by dnslug towards dnsnet. (figure 29)

Figure 29: the attack

On terminal of pc3 we are going to see the fake packet by searching the ID: 23660 of

dns query/answer as in figure 30.

!26

! Figure 30: dns query / answer for the attack

Figure 31: dns query / answer for the attack illustration

!27

Now let us try to get the web page of pc3. On pc1 terminal type:

● cd ..

● cd hosthome

● ctrl+G ( To write URL we are searching for )

● http://pc3.nanoinside.net/

● Press “Enter” button

We are going to get the same page as in figure 28. Again the attack was successful

even if we didn’t lunch again it from pc5. Instead of getting the pc3 web page we got

the pc4’s one. Our recursive server has in cache dns_hacker IP address which he

believes is responsible for nanoinside.net zone under which should be

pc3.nanoinside.net as it should have been even pc2.nanoinside.net .

Let now look again at pc3 terminal which was listening in the meanwhile.

! Figure 32: dns query / answer for the attack once dnslug has in cache dns_hacker

Now dnslug asks directly to dns_hacker to for the Ip address of pc3.nanoinside.net.

!28

As we discussed it on section 2 of this report and shown it now with the kaminksy

attack we get the control of an entire domain/subdomain. Moreover, one of the

characteristics that makes the kaminsky attack very powerful is that its effect lasts

until the cache of the recursive server expires (in our case dnslug).

!29