Assignment
1 Overview
FIT5037 Network Security Assignment Total Marks 100
Due on Sunday, 4 August 2024, 11:55 PM.
Copyright By PowCoder代写 加微信 powcoder
The learning objective of this assignment is for you to gain a first-hand experience on network attacks (i.e., TCP and DNS attacks) and get a deeper understanding on how to launch these attacks in practice. All tasks in this assignment can be done on the virtual machine used in the labs.
2 Submission Policy
You need to submit a lab report (one single PDF file) to describe what you have done and what you have observed with screen shots whenever necessary; you also need to provide explanation or codes to the observations that are related to the tasks. In your report, you are expected to answer all the questions listed in this manual. Typeset your report into .pdf format (make sure it can be opened with Adobe Reader) and name it as the format:
[Your Name]-[Student ID]-FIT5037-Assignment, e.g., HarryPotter-12345678-FIT5037-Assignment.pdf.
All source code if required should be embedded in your report. In addition, if a demonstration video is required, you should record your screen demonstration with your voice explanation and upload the video to
your Monash Google Drive. For video demonstration, please keep it to maximum of 30 minutes in total duration; you are required to say your name and student ID at the start of recording, showing face is mandatory. The shared URL of the video should be mentioned in your report wherever required. You can
use any tool you would like to record videos, for example panopto (https://monash- panopto.aarnet.edu.au/) and Zoom.
Late submission penalty: 10-point deduction per day. If you require a special consideration, the application should be submitted and notifieda tl eastt hreed aysi nadvance.Z erot oleranceo n
plagiarism: If you are found cheating, penalties will be applied, i.e., a zero grade for the unit. The demonstration video is also used to detect/avoid plagiarism. University polices can be found at https://www.monash.edu/students/academic/policies/academic-integrity.
3 Environment Setup
In this section, you need to double check whether you have configured G NS3 c orrectly. We w ill b e using the Topic 6 – Week 5A lab configuration, i .e., y our G NS3 c onfiguration sh ould lo ok li ke below:
Figure 1: GNS3 Config
Otherwise, if you don’t have the VM ready, we refer you to Environment Setup in Week 01. It is
recommended to perform lab tasks of Topic 6 – Week 5A before proceeding. 1
FIT5037 Assignment
4 TCP Attacks – Using Scapy [40 Marks]
The Transmission Control Protocol (TCP) is a core protocol of the Internet protocol suite. It sits on top of the IP layer, and provides a reliable and ordered communication channel between applications running on networked computers. TCP is in a layer called Transport layer, which provides host-to-host communication services for applications. To achieve such reliable and order communication, TCP requires both ends of a communication to maintain a connection. Unfortunately, when TCP was developed, no security mechanism was built into this protocol, making it possible for attackers to eavesdrop on connections, break connections or hijack connections. In this section, you are required to perform these attacks using Scapy—a packet manipulation tool for computer networks written in Python.
4.1 Task 1: TCP Reset Attacks [15 Marks]
In the stream of packets of a TCP connection, each packet contains a TCP header. In the header, there is a bit known as the ”reset” (RST) flag. In most packets, this bit is set to 0 and has no effect; however, if this bit is set to 1, it indicates that the receiver should immediately stop using the TCP connection. That means it should not send back any more packets using the connection’s identifying numbers, called ports, and discard any further packets with headers belong to that connection. A TCP reset basically kills a TCP connection instantly.
It is possible for a third computer (aka attacker) to monitor the TCP packets on the connection and then send a ”forged” packet containing a TCP reset to one or both endpoints. The headers in the forged packet must indicate, falsely, that it came from an endpoint, not the forger. This information includes the endpoint IP addresses and port numbers. Every field in the IP and TCP headers must be set to a convincing forged value for the fake reset to trick the endpoint into closing the TCP connection.
The idea is quite simple: to break up a TCP connection between A and B, the attacker just spoofs a TCP RST packet from A to B or from B to A.
Q1: Connect from Internal-Client to Internal-Server using SSH (use apt install ssh if SSH is not installed), the username and password are same: msfadmin. Perform TCP RST attack, from Internal-Attacker workstation, on SSH service using Scapy (python-based) packet generator. Internal-Client terminal should show the connection is terminated. Please submit your python code and the steps, along with video link showing that you have performed the attack. (Python code: 5 marks, explanation during recording demonstration: 5 marks)
Q2: Briefly explain the TCP RST attack and propose at least two theoretical countermeasures. You do not have to do any configuration/implementation for this task. (Explanation: 2.5 marks, counter- measures: 2.5 marks)
4.2 Task 2: TCP Session Hijacking Attacks [25 Marks]
Once a TCP client and server finish the three-way handshake protocol, a connection is established, and we call it a TCP session. From then on, both ends can send data to each other. Since a computer can have multiple concurrent TCP sessions with other computers, when it receives a packet, it needs to know which TCP session the packet belongs to. TCP uses four elements to make that decision, i.e., to uniquely identify a session: (1) source IP address, (2) destination IP address, (3) source port number, and (4) destination port number.
We call these four fields as the signature of a TCP session. As we have already learned, spoofing packets is not difficult. What if we spoof a TCP packet, whose signature matches that of an existing TCP session on the target machine? Will this packet be accepted by the target? Clearly, if the above four elements match with the signature of the session, the receiver cannot tell whether the packet comes from the real sender or an attacker, so it considers the packet as belonging to the session.
However, for the packet to be accepted, one more critical condition needs to be satisfied. It is the TCP sequence number. TCP is a connection-oriented protocol and treats data as a stream, so each octet in the TCP session has a unique sequence number, identifying its position in the stream. The TCP header
FIT5037 Assignment
contains a 32-bit sequence number field, which contains the sequence number of the first octet in the payload. When the receiver gets a TCP packet, it places the TCP data (payload) in a buffer; where exactly the payload is placed inside the buffer depends on the sequence number. This way, even if TCP packets arrive out of order, TCP can always place their data in the buffer using the correct order.
The objective of this task is to hijack an existing TCP connection (session) between client and server by injecting malicious contents into their session.
Q3: Connect TELNET from Internal-Client to Internal-Server, the username and password are same: msfadmin. Write a python code, using Scapy, which can inject packets in the TELNET communica- tion, the goal is to make a directory called “attacker” at the Internal-Server (as seen in the screenshot below). You can use Internal-Attacker workstation to run the python code. Submit python code and steps, along with video link that demonstrates you have performed the attack. (Python code: 5 marks, explanation during recording demonstration: 5 marks)
Figure 2: Directories in Internal-Server
Q4: Connect TELNET from Internal-Client to Internal-Server. The objective is to get a reverse shell from Internal-Server. Reverse shell is a shell process running on a remote machine, connecting back to the attacker’s machine. We are omitting the details of reverse shell and encourage students to research about it, you can start from here: https://hackernoon.com/reverse-shell-cf154dfee6bd. Write a python code, using Scapy, which can inject packets in TELNET communication and create a reverse shell from Internal-Server to Internal-Attacker (as seen in the screenshot below, in this case the Internal-Server’s IP address is 10.10.10.197). Submit python code and steps, along with video link showing that you have performed the attack. (Python code: 5 marks, explanation during recording demonstration: 5 marks)
Figure 3: Receiving reverse shell
5 DNS Attacks – Using Scapy [60 Marks]
Domain Name System (DNS) is an essential component of the Internet infrastructure. It serves as the phone book for the Internet, so computers can look up for “telephone number” (i.e. IP addresses) from domain names. Without knowing the IP address, computers will not be able to communicate with one another. Due to its importance, the DNS infrastructure faces frequent attacks. In this section, you will explore the most primary attack on DNS. That is DNS cache poisoning by investigating both Local and Remote DNS cache poisoning attacks.
Due to the large number of computers and networks on the Internet, the domain namespace is organised in a hierarchical tree-like structure. Each node on the tree is called a domain or sub-domain when referencing to its parent node. The following figure depicts a part of the domain hierarchy.
Q5: Connect SSH from Internal-Client to Internal-Server, the username and password are same: msfadmin. Perform same TCP hijacking attacks as you did for TELNET, i.e. make attacker directory in Internal-Server and create a reverse shell from Internal-Server to Internal-Attacker by hijacking SSH connection. If your attacks are successful, please submit python code and steps, along with video link showing that you have performed the attacks. If your attacks were unsuccessful, explain the reason in detail. (Python Code and Explanation during recording demonstration: 5 marks)
Assignment
Figure 4: Domain hierarchy
The domain hierarchy tree structure describes how the domain namespace is organised, but that is not exactly how the domain name systems are organised. Domain name systems are organised according to zones. A DNS zone basically groups contiguous domains and sub-domains on the domain tree, and assign the management authority to an entity. Each zone is managed by an authority, while a domain does not indicate any authority information. The following figure depicts an example of the example.com domain.
Figure 5: DNS Zones
Assume that example.com in the above figure is an international company, with branches all over the world, so the company’s domain is further divided into multiple sub-domains, including usa.example.com, uk.example.com, and france.example.com. Inside US, the usa sub-domain is further divided into chicago, boston, and nyc subdomains.
Each DNS zone has at least one authoritative nameserver that publishes information about that zone. The goal of a DNS query is to eventually ask the authoritative DNS server for answers. That is why they are called authoritative because they provide the original and definitive answers to DNS queries, as opposed to obtaining the answers from other DNS servers.
With such arrangement, the root zone for example.com only needs to keep records of who the authority is for each of its subdomains. By doing this, it maintains the independence among the branches in different countries and enable the administrative right of those subdomains, so the branch in each country manages its own DNS information. For a given DNS query, if your local DNS server does not the answer, it will ask
other DNS servers on the Internet for answer via hierarchical authority servers. The following example demonstrates a dig (DNS query) for the domain www.example.net when sending the query directly to one of the root server (i.e. a.root-servers.net).
Assignment
Figure 6: DIG to the root server
There are four types of sections in a DNS response: question section, answer section, authority section, and additional section. From the above result, we can see that the root server does not know the answer (because the reply does not include an answer section, but it tells several authoritative nameservers for the net zone (the NS records in the authority section), along with their IP address if possible in the additional section). If you continuously dig the domain www.example.net on one these authoritative nameservers, you will finally end up with the answer section showing the IP address of the machine hosting the website for www.example.net.
When your local DNS server gets information from other DNS servers, it caches the information, so if the same information is needed, it will not waste time to ask again.
5.1 Task 3: Local DNS Attack targeting Authority Nameserver [20 Marks]
We recalled that a DNS response contains question section, answer section, authority section, and additional section. If we only target the answer section, the attack only affects one hostname (as we did in our Topic 6 – Week 5A lab “DNS Spoofing Attacks”). Real DNS attacks usually target the authority section by providing a fake NS record for the target domain in the authority section. If the fake NS record is cached, when the victim local DNS server tries to find any IP address in the target domain, it will send a request to the malicious nameserver specified in the fake NS record. Such an attack can affect all the hostnames in the target domain. In this task, you will explore how to target the authority server of example.net and manage to replace it with ns1.attacker.com and ns2.attacker.com.
Q6: Submit your python code and write comments in the code step by step to perform the DNS spoofing attack that modifies the authority server of example.net to be ns1.attacker.com and ns2.attacker.com. Use Internal-Client as victim and Internal-Attacker as the attacker machine. (Python code: 10 marks). If the attack works, you should see the result as in following figures for which the malicious authoritative servers are taken place.
Assignment
Figure 7: Q6
5.2 Task 4: Remote DNS Attack targeting Authority Server [40 Marks]
For this task, the attacker (Internal-Attacker) and DNS server need to be in different LAN. We will move DNS server to Server LAN and configure its IP statically. The GNS3 configuration for this task should look like below:
Figure 8: GNS3 for Remote DNS Attacks
Q7: Provide your explanation in video demonstration to support your above DNS spoofing attack. (Ex- planation and attack’s results: 5 marks, highlight Wireshark packet monitor in the video: 5 marks)
Assignment
Configure static IP for DNS:
Figure 9: Static IP config for DNS
Now login to Internal-FW (username is ‘admin’, no password), and execute the following to disable NAT:
ip firewall nat remove 0
The previous local DNS attacks assume that the attacker and the DNS victim server are on the same LAN so that she can observe the DNS query message and reply with a forged DNS packet. When the attacker and the DNS server are not on the same LAN, the attack becomes harder since the attacker cannot perform ARP poisoning attack and see the DNS query. When the DNS victim server cannot resolve the DNS query, it will forward the DNS query packet to the forwarder DNS server (Google DNS server in our current setup). The DNS query is sent via a UDP packet where the UDP’s source port is a 16-bit random number. In addition, the 16-bit transaction ID in the DNS header is also self-created by the DNS victim server. Hence, if the remote attacker wants to forge the DNS response, the forged packet must contain the correct values of these two numbers; otherwise, the reply will not be accepted.
Without being able to sniff the query packet, the remote attacker can only guess these two numbers. The chance is one out of 232 for each guess. If an attacker can send out 1000 spoofed responses, it may take several days to try up 232 time. In contrast, it only takes few seconds to receive the correct packet response from the forwarder Google DNS. Consequently, that real reply will be cached by the local DNS victim server. To make another try, the attacker has to wait for the server to send out another DNS query when its cache times out. Hence, this attacking chance makes the remote DNS attack unrealistic.
The remote DNS attack had become an open problem until came up with a simple solution in 2008. The attack is depicted in the following figure.
Figure 10: 7
FIT5037 Assignment
We choose a domain test.com as our targeted domain name in this task. When a client queries the DNS server for www.test.com, the attacker (Internal-Attacker) wants to cause the DNS server to use her DNS server (ns.attacker.com). The following steps with reference to above figure describe the outline of the attack.
1. The attacker queries the DNS server for a non-existing name in test.com, for example xyz123.test.com, where xyz123 is a random name.
2. Since the mapping resolution cannot be resolved by the DNS server’s cache, the server forwards the query to Google DNS (8.8.8.8) for that name resolution.
3. In the meantime, the attacker floods the DNS server with many spoofed DNS responses, each trying a different transaction ID and source port number (hoping one guess is correct). In that forged response, not only the attacker provides the IP resolution for the hostname xyz123.test.com, but also provides an authority name server for the domain test.com.
Even if the response failed, the attacker would go back step one, and try another non-existing random name until the attacker succeeds.
4. Once the attack succeeds, when the client sends a DNS query to the poisoned DNS server for www.test.com, the nameserver returned by the DNS server will actually be set by the attacker.
To simplify and shorten the attack’s simulation time in this task, we suggest you follow the below steps before doing the task.
1. Double check the IP addresses of the server, attacker, and client to ensure the server and the attacker are not in the same LAN (using ifconfig command)
• DNS: 10.10.5.53
• Internal-Attacker: 10.10.10.X • Internal-Client: 10.10.10.Y
2. In the DNS server’s terminal, you can type the following command to configure DNS
nano /etc/bind/named.conf.options
Then, you should configure the forwarder 8.8.8.8, enable recursion and fix the query source port of the DNS server (i.e. 33333). With this constraint, the attacker now only needs to guess the transactionID of the DNS packet when performing remote DNS attacks. You can review the following figure for the correct configuration of DNS server.
Figure 11: DNS server config file 8
FIT5037 Assignment
3. After making the changes in the above step, you should restart your DNS server by using the following command
/etc/init.d/named restart
4. Delete the DNS cache on the server using the below command. You need to run this command before starting the attack.
rndc flush
We provide you the remote dns.py script template on Moodle that helps to perform the Kaminsky attack.
Q8: You need to complete Step 1 in the remote dns.py to create 10000 dummy hostnames. (The screen- shot of your Python code for this step: 5 marks)
Q9: You need to complete Step 2 in the remote dns.py to generate a random DNS query for each dummy hostnames. (The screenshot of your Python code for this step: 5 marks)
Q10: You need to complete Step 3 in the remote dns.py to flood about 100 random forged response packets. Each packet has:
• A randomly generated transaction ID for DNSpkt. (5 marks for code and screenshot)
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com