Project 3: NetworkingWinter 2022
due Wednesday, March 16 at 6 p.m.
This project counts for 13% of your course grade. Late submissions will be penalized by 10% of the maximum attainable score, plus an additional 10% every 4 hours until received. Late work will not be accepted after the start of the next lab (of any section) following the day of the deadline. If you or your partner have a conflict due to travel, interviews, etc., please plan accordingly and turn in your project early.
Copyright By PowCoder代写 加微信 powcoder
This is a group project; you must work in teams of two and submit one project per team. You are not required to work with the same partner on every project. Note that the final exam will cover project material, so you and your partner should collaborate closely on each part.
The code and other answers you submit must be entirely your team’s own work, and you are bound by the Honor Code. You may discuss the conceptualization of the project and the meaning of the questions, but you may not look at any part of someone else’s solution or collaborate with anyone other than your partner. You may consult published references, provided that you appropriately cite them (e.g., with program comments). Visit the course website for the full collaboration policy.
Your code for this project must be written in the version of Go which ships with the Docker container for this project. You may only use standard libraries that ship with Go or modules that we either explicitly permit or include in the starter code. Completing the Tour of Go will provide the base knowledge necessary to complete the coding portions of this project.
In the scope of this project, the term “IP address” refers to the IPv4 protocol only. Although IPv6 usage continues to grow, IPv4 remains the dominant protocol used to route Internet traffic today.
Solutions must be submitted via the Autograder and Google form, following the submission details at the end of this spec.
Introduction
This project will introduce you to network protocols, to network packet trace analysis, and to common network attacks.
Objectives:
Gain exposure to core network protocols and concepts.
Learn to apply manual and automated traffic analysis to detect security problems.
Understand offensive techniques used to intercept and manipulate network traffic.
Understand the mechanics of man-in-the-middle attacks.
Read this First
This project asks you to perform attacks, with our permission, against controlled and simulated environments. Attempting the same kinds of attacks against other networks without authorization is prohibited by law and university policies and may result in fines, expulsion, and jail time. You must not attack any network without authorization! Per course policy, you are required to respect the privacy and property rights of others at all times, or else you will fail the course. See “Ethics, Law, and University Policies” on the course website.
Part 1. Exploring Network Traces
Both security analysts and malicious attackers frequently study network traffic to search for vulnerabilities and characterize network behavior. In this section, you will examine a network packet trace (commonly called a “pcap”) that we recorded on a sample network set up for this assignment. You will search for specific vulnerable behaviors and extract relevant details using the Wireshark network analyzer. Wireshark ships in a Docker container with the project. When you open the project in the container in VS Code, you can navigate to http://localhost:3880 in your browser to use Wireshark. If you’d prefer to use VNC, you can also connect to vnc://localhost:3881.
If you use Windows and WSL or WSL 2, create your project folder in a WSL directory rather than in a mounted Windows directory (i.e. your project folder should not be accessed at /mnt/… in WSL). Using a mounted directory incurs massive overhead in reading from files, which may make Wireshark extremely slow.
To get started, download your unique pcap file from project3.eecs388.org and open it using Wireshark. (The file will be in a compressed (gzipped) format, but you’ll be able to open it directly in Wireshark without extracting.)
Familiarize yourself with Wireshark’s features and explore the various options for filtering and reconstructing data streams. Then, concisely answer the questions below.
There are no more than five devices actively communicating on the local area network. What are their MAC and IP addresses?
For each device you identified, classify its functionalities (select all that apply for each):
– Windows device
– Android device
– Apple device
– DNS server
– Security camera
– DHCP server
Over approximately what period of time was this pcap captured?
– 10 hours
– 10 minutes
– 10 seconds
Select the packet components that appear in the pcap unencrypted:
– HTTP/1.0 data
– HTTP/1.1 data
– HTTP/2 data
– TCP handshake
– TCP payload data
– TLS handshake: supported algorithms and keys
– TLS application data
The trace shows that at least one of the clients makes HTTPS connections over TLS 1.3. Pick one of these connections and answer the following:
In the majority of cases, the client must transmit the domain name before it can initiate the HTTPS connection. For the connection you chose, in which packet number does this occur and what is the domain name? (If you’re unable to locate this, you may want to pick another connection.)
What cipher suite does the server choose for the connection? Include the packet number where this is found.
As you notice, much of the data in the pcap is encrypted and therefore unreadable by passive eavesdroppers on the network. However, certain traffic can be decrypted when the appropriate secrets are known. Indeed, when capturing this pcap, we turned on a special browser setting to log some of these secrets. Download this keylog file to your computer, and in Wireshark, go to Preferences -> Protocols -> TLS and change the (Pre)-Master-Secret log filename setting to the path of the file.
The pcap now displays unencrypted… select all that apply
– HTTP/1.0 data
– HTTP/1.1 data
– HTTP/2 data
– TCP handshake
– TCP payload data
– TLS handshake
– TLS application data
One of the clients tries to login as someone on Facebook. What is their email?
(Bonus) Network traffic often reveals more than one expects. In what ZIP code was this network located?
What to submit
Submit your answers to this Google form.
To ensure your submission is properly graded, we recommend designating one group member as the lead on this part. Both partners can then use that person’s uniqname when downloading their own copies of the pcap file and working together on the form. Make sure that the form is submitted by only one person per team.
Part 2. Anomaly Detection
In Part 1, you manually explored a network trace. Now, you will programmatically analyze a pcap file to detect suspicious behavior. Specifically, you will be attempting to identify port scanning and ARP spoofing.
Port scanning is a technique used to find network hosts that have services listening on one or more target ports. It can be used offensively to locate vulnerable systems in preparation for an attack, or defensively for research or network administration. In one kind of port scan technique, known as a SYN scan, the scanner sends TCP SYN packets (the first packet in the TCP handshake) and watches for hosts that respond with SYN+ACK packets (the second handshake step).
Since most hosts are not prepared to receive connections on any given port, typically, during a port scan, a much smaller number of hosts will respond with SYN+ACK packets than originally received SYN packets. By observing this effect in a packet trace, you can identify source addresses that may be attempting a port scan.
ARP spoofing is an attack that exploits the Address Resolution Protocol (ARP), the scheme used to discover the MAC address associated with a given IP address within a network. When Device A needs to send a packet to Device B on the network, it initially only knows the IP address of Device B and needs to determine Device B’s MAC address. If Device A does not have this information already, it broadcasts an ARP packet to all computers on the local network, asking which device is associated with the IP address for Device B. Normally, Device B would respond with an ARP reply message containing its MAC and IP addresses. Device A then caches this information before sending the packet.
Because ARP packets are not authenticated, any device can claim to have any IP address. Furthermore, most network devices automatically cache any ARP replies they receive, regardless of whether they were ever requested in the first place. In an ARP spoofing attack, the attacker repeatedly sends unsolicited replies claiming to control a certain address with the aim of intercepting data bound for another system, thereby performing a man-in-the-middle or denial-of-service attack on other users on the network.
Your task is to develop a Go program that analyzes a pcap file in order to detect possible SYN scans and ARP spoofing attacks. To do this, you will use gopacket, a library for packet manipulation and dissection. gopacket ships with the Docker container for the project. You can find more information about gopacket at https://godoc.org/github.com/google/gopacket.
Your program will take the path of the pcap file to be analyzed as a command-line argument, e.g. (run from the project’s root):
$ go run ./detector capture.pcap
The printed output should begin with the line Unauthorized SYN scanners:, followed by the set of IP addresses (one per line) that sent more than 3 times as many SYN packets as the number of SYN+ACK packets they received and also sent more than 5 SYN packets in total. In calculating this, your program should silently ignore packets that are malformed or that are not using Ethernet, IP, and TCP. The line immediately following these IP addresses should print the line Unauthorized ARP spoofers:, followed by the set of MAC addresses (one per line) that send more than 5 unsolicited ARP replies. Unsolicited replies are those which contain a source IP and target MAC address combination that does not correspond to a previous request (each request should correspond to at most one reply).
A large sample pcap file captured from a real network can be downloaded at https://files.eecs388.org/sample.pcap. (You can examine the packets manually by opening this file in Wireshark.) For this input, your program’s output should match the following, with the addresses in each section in any order:
Unauthorized SYN scanners:
128.3.23.2
128.3.23.5
128.3.23.117
128.3.23.150
128.3.23.158
Unauthorized ARP spoofers:
7c:d1:c3:94:9e:b8
14:4f:8a:ed:c2:5e
What to submit
Write a program in Go that accomplishes the task specified above and submit it to your GitHub repository as detector.go. You should assume that gopacket is available, and you may use standard Go libraries, but your program should otherwise be self-contained. We will grade your detector using a variety of different pcap files.
Part 3. Man-in-the-Middle Attack
Some of your friends at the of Business have decided to open up a bank. However, in order to cut costs, they employed students who have not taken 388 to build their website. Not knowing about the benefits of encryption, the students served the website over plaintext HTTP.
After a few weeks, your friends notice that bank clients are mysteriously seeing their funds transferred to the wrong account. Coming to their senses, they decide to hire you, a clever 388 student, to diagnose the problem. Appalled at the use of HTTP in a banking site, you suggest that someone is man-in-the-middling the users’ connections. Your Ross friends scoff at you, rolling their eyes and declaring this IMPOSSIBLE. Your goal is to build a program that demonstrates such an attack against the banking site, to prove that this is a real security problem.
Your friends have provided the framework of a sample network for you to attack, which consists of a DNS server, the bank’s HTTP server, and a simple client simulating the actions of the average bank customer. Expecting your attack to go nowhere, they have even provided starter code for you to use in devising your attack.
MITM Diagram
Vulnerabilities
The vulnerabilities that you will be exploiting during this attack are the lack of authentication in DNS and the lack of encryption in plain HTTP. Since DNS is not authenticated, anyone is able to respond to a DNS request that they see going over the wire. This means an attacker positioned in the network can respond to a DNS request with a false address, thereby tricking clients into connecting to the wrong IP address for the domain. Combined with the fact that HTTP is unencrypted and unauthenticated, any attacker can secretly intercept and even modify communication between two parties who think they are communicating with each other directly, in what is known as a man-in-the-middle attack.
Your job is to create a program that exploits these vulnerabilities to meet the requirements below.
Requirements
DNS When the client queries a DNS A record for bank.com, your program should send a spoofed response containing the attacker’s address. You should send this response in under 2 seconds, so as to beat the real DNS server’s response. You should ignore DNS queries for other names or record types.
To help with troubleshooting, we made it so that the real DNS server never responds. Therefore, when your program fails to send a valid DNS response, DNS resolution will fail, and the client will crash during login with an error such as i/o timeout or Answer to DNS question not found.
Tip: You may want to temporarily modify the DNS server so that it does respond and then observe what happens, in order to better understand the nature of the attack.
HTTP Your program should listen for HTTP requests, forward them to the bank server, and return the response from the server back to the client. In doing so, you should satisfy the following snooping and spoofing guidelines:
Whenever a client makes a POST request to the bank’s /login endpoint, your program should steal the credentials, which are the values of the username and password parameters in the body, by sending them to the thievery.StealCredentials function.
Whenever the client makes a POST request to the bank’s /transfer endpoint containing a to parameter in the body, your program should change the value to Jensen when forwarding this request to the bank. When responding to the client, your program should reverse this change, so that any occurrences of Jensen in the response body are reverted to the value which the client actually sent.
Whenever the client makes a GET request to the bank’s /download endpoint, your program should steal any file that the server provides by sending it to the file handler provided by the thievery.StealFile function. Make sure to call this function with the filename specified by the server.
If you’ve implemented this correctly, you should see a stolen file appear in the intercepted_files directory!
For all other endpoints, your program should forward traffic as-is without modification, just like a proxy server.
For any request made by the client, your program should steal any and all cookies sent by the client or set by the server. That is, any time the client sends the Cookie request header, or the server responds with the Set-Cookie header, your program should send the cookie name and value to the thievery.StealClientCookie or thievery.StealServerCookie functions, respectively.
Whenever your program receives any request to the /kill endpoint, your program should exit immediately by calling os.Exit(1). This is already implemented in the starter code.
Technicalities
As mentioned above, you have been provided starter code to help in demonstrating the attack. You are free to make any modifications to this starter code as you deem necessary, provided that you follow the requirements above and these miscellaneous rules:
You are required to import and use the functions contained in the bank.com/mitm/network and bank.com/mitm/network/thievery packages. (Typing network.… or thievery.… will cause them to be automatically imported). Do not hardcode their implementations into your program, as they may differ on the autograder.
Apart from the bank.com/mitm/network and bank.com/mitm/network/thievery packages described above, you may only import from the Go standard libraries or gopacket.
You may not assume any additional details about the network’s topology or functionality, beyond what is described in this spec. This includes any details about the IP addresses of devices on the network, or what happens when any of the network. or thievery. functions are called.
Testing Your Solution
Unit Testing
Because your Ross friends are so confident about your inability to perform this attack, they have provided basic unit tests for certain functions in the starter code based on the behavior they believe correct implementations of these functions will exhibit.
You can run these tests by clicking “run test” on any of the test functions in VS Code. (You can also click “debug test” to run the test in your visual debugger—this comes fully set up in Docker right out of the box!)
Running a test in VS Code
Running go test . inside the mitm folder will run all tests at once.
Understanding what these unit tests are doing will be extremely useful in successfully implementing these functions; spend some time looking them over. Note that these tests are not necessarily comprehensive. You are more than welcome to add additional tests.
Full-flow Testing
You will be using Docker to simulate a basic network within your computer. Docker allows you to run applications in isolated environments locally, similar to virtual machines, but without the overhead required by VMs to completely virtualize your system’s hardware in each environment.
To run your solution, run the following command within the Docker container for the project:
$ docker compose up –build
If the command gives you trouble, try running sudo docker system prune. This will clean up files related to previous instances, in case they are causing any issues with the build process.
If your program is fully implemented, you should see output as described in correct_mitm_output.txt. Don’t worry if you see extra output before the STAGE 1/6 line or after the exit status 1 line.
To help with debugging your solution, all packets within the network will be saved to mitm.pcap, which you can inspect via Wireshark.
What to submit
Write a program in Go that accomplishes the task specified above and submit it to your GitHub repository as mitm.go.
Submission Details
Create a repo using the GitHub template. Make sure that the repo you create is private.
Ensure that exactly one team member creates a submission to Part 1 using the Google form. You will be able to edit your submission any number of times before the deadline.
Establish a team on the autograder. Only teams created on the autograder will be able to join the online office hours queue.
Project 3 Autograder
Although the autograder submission screen shows the 6 p.m. deadline, you can still submit after this time subject to a lateness penalty, up until the start of the first lab following the deadline. Any submissions after the posted deadline will result in a late deduction, even if your best submission occurred before the deadline. The autograder will not warn you of this. (You don’t get to attempt a higher score after the deadline with no consequences.)
Make sure you have completed the following items by the deadline:
Submit responses for Part 1 to the Google form.
Submit the following files to the autograder:
detector.go: Your Go source code for SYN scan and ARP spoof detection.
mitm.go, http.go, dns.go: Your Go source code for the MITM atta
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com