Reference no: EM131193834

In this assignment you will develop 1) an on-path DNS packet injector and 2) a passive DNS poisoning attack detector.

Part 1:

The DNS packet injector you are going to develop, named 'dnsinject', will capture the traffic from a network interface in promiscuous mode, and attempt to inject forged responses to selected DNS A requests.

Your program should conform to the following specification:

dnsinject [-i interface] [-f hostnames] expression

-i Listen on network device <interface> (e.g., eth0). If not specified, dnsinject should select a default interface to listen on. The same interface should be used for packet injection.

-f Read a list of IP address and hostname pairs specifying the hostnames to be hijacked. If '-f' is not specified, dnsinject should forge replies for all observed requests with the local machine's IP address as an answer.

<expression> is a BPF filter that specifies a subset of the traffic to be monitored. This option is useful for targeting a single or a set of particular victims.

The <hostnames> file should contain one IP and hostname pair per line, separated by whitespace.

For example:
10.6.6.6 foo.example.com
10.6.6.6 bar.example.com
192.168.66.6 www.cs.stonybrook.edu

Pay attention to the time needed for generating the spoofed response: it should be fast enough for the injected reply to reach the victim sooner than the server's actual response. The spoofed packet and content should also be valid according to the initial DNS request, and the forged response should be accepted and processed normally by the victim.

Part 2:

The DNS poisoning attack detector you are going to develop, named 'dnsdetect', will capture the traffic from a network interface in promiscuous mode and detect DNS poisoning attack attempts, such as those generated by dnsinject.

Detection will be based on identifying duplicate responses towards the same destination that contain different answers for the same A request, i.e., the observation of the attacker's spoofed response followed by the server's actual response. You should make every effort to avoid false positives, e.g., due to legitimate consecutive responses with different IP addresses for the same hostname due to round robin DNS load balancing.

Your program should conform to the following specification:

dnsdetect [-i interface] [-r tracefile] expression

-i Listen on network device <interface> (e.g., eth0). If not specified, the program should select a default interface to listen on.

-r Read packets from <tracefile> (tcpdump format). Useful for detecting DNS poisoning attacks in existing network traces.

<expression> is a BPF filter that specifies a subset of the traffic to be monitored.

Once an attack is detected, dnsdetect should print to stdout a detailed alert containing a printout of both the spoofed and legitimate responses. You can format the output in any way you like. Output must contain the detected DNS transaction ID, attacked domain name, and the original and malicious IP addresses - for example:

20160406-15:08:49.205618 DNS poisoning attempt

TXID 0x5cce Request www.example.com
Answer1 [List of IP addresses]
Answer2 [List of IP addresses]

For both dnsinject and dnsdetect, feel free to use parts or build upon the code of your 'mydump' tool from Homework 2. You are free to pick any programming language you like for both tools, as long as it is easy to install and configure on a modern Linux system (e.g., C, C++, python, ruby).

What to submit:

A tarball with:

- all required source code files, an appropriate Makefile (if needed), and instructions for installing any library dependencies/packages (if needed)

- a pcap trace of one or more successful attack instances generated using your dnsinject tool

- a short report (.txt file is fine) with a brief description of your programs, the strategy you followed for DNS poisoning detection, and the output of your dnsdetect tool when fed with the above attack trace

Hints:

1) You may find some of the following libraries/tools useful: libnet, scapy, dpkt, libdnet.

2) Mind your spoofed packet's header fields and checksums!

3) Think about what fields should remain the same or may differ between the spoofed and actual response packets.

4) An easy way to test your tools is to have a victim guest VM, and run dnsinject and dnsdetect on the host (or another VM that can observe the victim's traffic).