TCP/IP ATTACK LAB USING Ubuntu 20.04 and 16.04

1 | P a g e

DDoS Assignment

TCP/IP ATTACK LAB USING Ubuntu 20.04 and 16.04

Due Date: 10/8

1. Overview

The learning objective of this lab is for you to gain first-hand experience on vulnerabilities, as well

as on attacks against these vulnerabilities. Wise people learn from mistakes. In security education, we

study mistakes that lead to software vulnerabilities. Studying mistakes from the past not only helps you

understand why systems are vulnerable, why a seemly-benign mistake can turn into a disaster, and why

many security mechanisms are needed. More importantly, it also helps you learn common patterns

of vulnerabilities, so they can avoid making similar mistakes in the future. Moreover, using vulnerabilities

as case studies, you can learn the principles of secure design, secure programming, and security testing.

The vulnerabilities in the TCP/IP protocols represent a special genre of vulnerabilities in protocol designs and implementations; they provide an invaluable lesson as to why security should be designed in from

the beginning, rather than being added as an afterthought. Moreover, studying these vulnerabilities helps you understand the challenges of network security and why many network security measures are needed.

In this lab, you will conduct several attacks on TCP\IP by implementing 4 different tasks. These tasks are :

Using Ubuntu 20.04

1. Task 1 TCP SYN flood attack, and SYN cookies 2. Task 2 TCP session hijacking attack

Using Ubuntu 16.04

3. Task 3 TCP RST Attacks on telnet and SSH Connections 4. Task 4 TCP RST Attacks on Video Streaming Applications

Lab Environment. This lab has been tested on our pre-built SEED Ubuntu 16.04 and 20.04 VM, which can be downloaded from the SEED website.

2. Lab Environment

Network Setup for Ubuntu 16.04 VM’s:

To conduct this lab, you need to have at least 3 machines. One computer is used for attacking, the second computer is used as the victim, and the third computer is used as the observer. You can set up 3 virtual machines on the same host computer, or they can set up 2 virtual machines, and then use the host computer as the third

2 | P a g e

computer. For this lab, we put all these three machines on the same LAN, the configuration is described in Figure 1. IP address, port, and system ID will change for each session.

Figure 1: Environment Setup

Scapy Tool. Some of the tasks in this lab can also be conducted using Scapy, which is a powerful interactive packet manipulation program. Scapy is very well maintained and is widely used, while Netwox is not being maintained any more. There are many online tutorials on Scapy; we expect you to learn how to use Scapy from those tutorials.

--Do not use Netwox--

Step 1: Container Setup and Commands

Please download the labsetup.zip file to your VM from the lab’s website, unzip it, enter the labsetup

folder, and use the docker-compose.yml file to set up the lab environment. Detailed explanation of the

content in this file and all the involved Dockerfile can be found from the user manual, which is linked

to the website of this lab. If this is the first time you set up a SEED lab environment using containers, it is

very important that you read the user manual.

In the following, we list some of the commonly used commands related to Docker and Compose. Since

we are going to use these commands very frequently; we have created aliases for them in the .bashrc file

(In our provided SEEDUbuntu 20.04 VM).

$ docker-compose build # Build the container image $ docker-compose up # Start the container $ docker-compose down # Shut down the container

// Aliases for the Compose commands above $ dcbuild # Alias for: docker-compose build $ dcup # Alias for: docker-compose up $ dcdown # Alias for: docker-compose down All the containers will be running in the background. To run commands on a container, we often need

to get a shell on that container. We first need to use the "docker ps" command to find out the ID of

3 | P a g e

the container, and then use "docker exec" to start a shell on that container. We have created aliases for

them in the. bashrc file. If you encounter problems when setting up the lab environment, please read the “Common Problems” section of the manual for potential solutions.

Step 2 About the Attacker Container

In this lab, we can either use the VM or the attacker container as the attacker machine. If you look at

the Docker Compose file, you will see that the attacker container is configured differently from the other

containers.

• Shared folder. When we use the attacker container to launch attacks, we need to put the attacking code inside the attacker container. Code editing is more convenient inside the VM than in containers because we can use our favorite editors. For the VM and container to share files, we have created a shared folder between the VM and the container using the Docker volumes. If you look at the Docker Compose file, you will find out that we have added the following entry to some of the containers. It indicates mounting the ./volumes folder on the host machine (i.e., the VM) to the /volumes folder inside the container. We will write our code in the ./volumes folder (on the VM), so they can be used inside the containers. volumes:

- ./volumes:/volumes

• Host mode. In this lab, the attacker needs to be able to sniff packets, but running sniffer programs inside a container has problems, because a container is effectively attached to a virtual switch, so it can only see its own traffic, and it is never going to see the packets among other containers. To solve this problem, we use the host mode for the attacker container. This allows the attacker container to see all the traffics. The following entry used on the attacker container: network_mode: host When a container is in the host mode, it sees all the host’s network interfaces, and it even has the same IP addresses as the host. Basically, it is put in the same network namespace as the host VM. However, the container is still a separate machine because its other namespaces are still different from the host.

Step 3 The seed Account

In this lab, we need to telnet from one container to another. We have already created an account called

seed inside all the containers. Its password is dees. You can telnet into this account.

3. Task

• TCP SYN flood attack, and SYN cookies o Launching the Attack Using Python o Launch the Attack Using C o Enable the SYN Cookie Countermeasure

• TCP session hijacking attack • TCP RST Attacks on telnet and SSH Connections • TCP RST Attacks on Video Streaming Applications

4 | P a g e

Task 1: TCP SYN flood attack, and SYN cookies Using Ubuntu 20.04

SYN flood is a form of DoS attack in which attackers send many SYN requests to a victim’s TCP port, but

the attackers have no intention to finish the 3-way handshake procedure. Attackers either use spoofed IP

address or do not continue the procedure. Through this attack, attackers can flood the victim’s queue that

Figure 2: SYN Flooding Attack

is used for half-opened connections, i.e. the connections that has finished SYN, SYN-ACK, but has not yet gotten a final ACK back. When this queue is full, the victim cannot take any more connection. Figure 2 illustrates the attack. The size of the queue has a system-wide setting. In Ubuntu OSes, we can check the setting using the following command. The OS sets this value based on the amount of the memory the system has: the more memory the machine has, the larger this value will be.

# sysctl net.ipv4.tcp_max_syn_backlog

net.ipv4.tcp_max_syn_backlog = 128

We can use command "netstat -nat" to check the usage of the queue, i.e., the number of half-opened connection associated with a listening port. The state for such connections is SYN-RECV. If the 3-way handshake is finished, the state of the connections will be ESTABLISHED.

SYN Cookie Countermeasure: By default, Ubuntu’s SYN flooding countermeasure is turned on. This

mechanism is called SYN cookie. It will kick in if the machine detects that it is under the SYN flooding attack. In our victim server container, we have already turned it off (see the sysctls entry in the

docker-compose.yml file). We can use the following sysctl command to turn it on and off:

# sysctl -a | grep syncookies (Display the SYN cookie flag)

# sysctl -w net.ipv4.tcp_syncookies=0 (turn off SYN cookie)

# sysctl -w net.ipv4.tcp_syncookies=1 (turn on SYN cookie)

To be able to use sysctl to change the system variables inside a container, the container needs to be

5 | P a g e

configured with the "privileged: true" entry (which is the case for our victim server). Without

this setting, if we run the above command, we will see the following error message. The container is not

given the privilege to make the change.

# sysctl -w net.ipv4.tcp_syncookies=1

sysctl: setting key "net.ipv4.tcp_syncookies": Read-only file system

Launching the Attack Using Python

We provide a Python program called synflood.py, but we have intentionally left out some essential data in the code. This code sends out spoofed TCP SYN packets, with randomly generated source IP address, source port, and sequence number. You should finish the code and then use it to launch the attack on the target machine:

#!/bin/env python3

from scapy.all import IP, TCP, send from ipaddress import IPv4Address from random import getrandbits

ip = IP(dst="*.*.*.*") tcp = TCP(dport=**, flags=’S’) pkt = ip/tcp

while True: pkt[IP].src = str(IPv4Address(getrandbits(32))) # source IP pkt[TCP].sport = getrandbits(16) # source port pkt[TCP].seq = getrandbits(32) # sequence number send(pkt, verbose = 0)

Let the attack run for at least one minute, then try to telnet into the victim machine, and see whether you can succeed. Very likely that your attack will fail. Multiple issues can contribute to the failure of the attack. They are listed in the following with guidelines on how to address them.

• TCP cache issue: See Note A below. • VirtualBox issue: If you are doing the attack from one VM against another VM, instead of using our

container setup, please see Note B below. This is not an issue if you are doing the attack using the container setup.

• TCP retransmission issue: After sending out the SYN+ACK packet, the victim machine will wait for the ACK packet. If it does not come in time, TCP will retransmit the SYN+ACK packet. How many times, it will retransmit depends on the following kernel parameters (by default, its value is 5): # sysctl net.ipv4.tcp_synack_retries net.ipv4.tcp_synack_retries = 5 After these 5 retransmissions, TCP will remove the corresponding item from the half-open connection queue. Every time when an item is removed, a slot becomes open. Your attack packets and the legitimate telnet connection request packets will fight for this opening. Our Python program may not be fast enough and can thus lose to the legitimate telnet packet. To win the competition, we can run multiple instances of the attack program in parallel. Please try this approach and see whether the success rate can be improved. How many instances should you run to achieve a reasonable success rate?

6 | P a g e

• The size of the queue: How many half-open connections can be stored in the queue can affect the success rate of the attack. The size of the queue be adjusted using the following command: # sysctl -w net.ipv4.tcp_max_syn_backlog=80

While the attack is ongoing, you can run one of the following commands on the victim container to see how many items are in the queue. It should be noted that one fourth of the space in the queue is reserved for “proven destinations” (see Note A below), so if we set the size to 80, its actual capacity is about 60. $ netstat -tna | grep SYN_RECV | wc -l $ ss -n state syn-recv sport = :23 | wc -l Please reduce the size of the half-open connection queue on the victim server, and see whether your success rate can improve.

Note A: A kernel mitigation mechanism. On Ubuntu 20.04, if machine X has never made a TCP connection to the victim machine, when the SYN flooding attack is launched, machine X will not be able to telnet into the victim machine. However, if before the attack, machine X has already made a telnet (or TCP connection) to the victim machine, then X seems to be “immune” to the SYN flooding attack and can successfully telnet to the victim machine during the attack. It seems that the victim machine remembers past successful connections and uses this memory when establishing future connections with the “returning” client. This behavior does not exist in Ubuntu 16.04 and earlier versions. This is due to a mitigation of the kernel: TCP reserves one fourth of the backlog queue for “proven destinations” if SYN Cookies are disabled. After making a TCP connection from client to the server, we can see that the client IP address is remembered (cached) by the server, so they will be using the reserved slots when connections come from them, and will thus not be affected by the SYN flooding attack. To remove the effect of this mitigation method, we can run the "ip tcp metrics flush" command on the server. # ip tcp_metrics show 10.9.0.6 age 140.552sec cwnd 10 rtt 79us rttvar 40us source 10.9.0.5 # ip tcp_metrics flush Note B: RST packets. If you are doing this task using two VMs, i.e., launching the attack from one VM against another VM, instead of attacking a container, from the Wireshark, you will notice many RST packets (reset). Initially, we thought that the packets were generated from the recipient of the SYN+ACK packet, but it turns out they are generated by the NAT server in our setup. Any traffic going out of the VM in our lab setup will go through the NAT server provided by VirtualBox. For TCP, NAT creates address translation entries based on the SYN packet. In our attack, the SYN packets generated by the attacker did not go through the NAT (both attacker and victims are behind the NAT), so no NAT entry was created. When the victim sends SYN+ACK packet back to the source IP (which is randomly generated by the attacker), this packet will go out through the NAT, but because there is no prior NAT entry for this TCP connection, NAT does not know what to do, so it sends a TCP RST packet back to the victim. RST packets cause the victim to remove the data from the half-open connection queue. Therefore, while we are trying fill up this queue with the attack, VirtualBox helps the victim to remove our records from the queue. It becomes a competition between our code and the VirtualBox.

Launch the Attack Using C Other than the TCP cache issue, all the issues mentioned in Task 1.1 can be resolved if we can send spoofed SYN packets fast enough. We can achieve that using C. We provide a C program called synflood.c in the lab setup. Please compile the program on the VM and then launch the attack on the target machine. // Compile the code on the host VM $ gcc -o synflood synflood.c // Launch the attack from the attacker container # synflood 10.9.0.5 23

7 | P a g e

Before launching the attack, please restore the queue size to its original value. Please compare the results with the one using the Python program and explain the reason behind the difference.

Enable the SYN Cookie Countermeasure Please enable the SYN cookie mechanism, and run your attacks again, and compare the results.

Task 2: TCP session hijacking attack Using Ubuntu 20.04

The objective of the TCP Session Hijacking attack is to hijack an existing TCP connection (session) between two victims by injecting malicious contents into this session. If this connection is a telnet session, attackers can inject malicious commands (e.g. deleting an important file) into this session, causing the

Figure 3: TCP Session Hijacking Attack

victims to execute the malicious commands. Figure 3 depicts how the attack works. In this task, you need to demonstrate how you can hijack a telnet session between two computers. Your goal is to get the telnet server to run a malicious command from you. For the simplicity of the task, we assume that the attacker and the victim are on the same LAN.

Launching the attack manually. Please use Scapy to conduct the TCP Session Hijacking attack. A

skeleton code is provided in the following. You need to replace each @@@@ with an actual value; you can

use Wireshark to figure out what value you should put into each field of the spoofed TCP packets.

#!/usr/bin/env python3 from *.* import * ip = IP(src***** dst="*****") tcp = TCP(sport****** dport***** flags="A", seq**** ack*****) data = ****** pkt = ip/tcp/data ls(pkt) send(pkt, verbose=0)

Optional: Launching the attack automatically. You are encouraged to write a program to launch

the attack automatically using the sniffing-and-spoofing technique. Unlike the manual approach, we get all

the parameters from sniffed packets, so the entire attack is automated. Please make sure that when you use

Scapy’s sniff function, don’t forget to set the iface argument.

8 | P a g e

Task 3: TCP RST Attacks on telnet and SSH Connections Using Ubuntu 16.04

The TCP RST Attack can terminate an established TCP connection between two victims. For example, if

there is an established telnet connection (TCP) between two users A and B, attackers can spoof an RST

packet from A to B, breaking this existing connection. To succeed in this attack, attackers need to correctly

construct the TCP RST packet.

In this task, you need to launch an TCP RST attack to break an existing telnet connection between A and B. After that, try the same attack on a ssh connection. Please describe your observations. To simplify the lab, we assume that the attacker and the victim are on the same LAN, i.e., the attacker can observe the TCP traffic between A and B.

Using Scapy. Please also use Scapy to conduct the TCP RST attack. A skeleton code is provided in the

following (you need to replace each @@@@ with an actual value):

#!/usr/bin/python

from ***.** import *

ip = IP(src=*****, dst=***)

tcp = TCP(sport=******, dport=*****, flags=*****, seq=***** ack=******) pkt = ip/tcp ls(pkt) send(pkt, verbose=0)

Task 4: TCP RST Attacks on Video Streaming Applications Using Ubuntu 16.04

Let us make the TCP RST attack more interesting by experimenting it on the applications that are widely used in nowadays. We choose the video streaming application in this task. For this task, you can choose a video streaming web site that you are familiar with (we will not name any specific web site here). Most of video sharing websites establish a TCP connection with the client for streaming the video content. The attacker’s goal is to disrupt the TCP session established between the victim and video streaming machine. To simplify the lab, we assume that the attacker and the victim are on the same LAN. In the following, we describe the common interaction between a user (the victim) and some video-streaming web site:

• The victim browses for a video content in the video-streaming web site, and selects one of the videos for streaming.

• Normally video contents are hosted by a different machine, where all the video contents are located. After the victim selects a video, a TCP session will be established between the victim machine and the content server for the video streaming. The victim can then view the video he/she has selected.

Your task is to disrupt the video streaming by breaking the TCP connection between the victim and the content server. You can let the victim user browse the video-streaming site from another (virtual) machine or from the same (virtual) machine as the attacker. Please be noted that, to avoid liability issues, any attacking packets should be targeted at the victim machine (which is the machine run by yourself), not at the content server machine (which does not belong to you).

9 | P a g e

Assignment Submission

Execute all 4 Tasks in the assignments, use the task explanation as guide to help you exciting the Task. You need to submit a detailed (extreme details and explain each step, commands, codes, and flowcharts has to be submitted) lab report, with screenshots, as explained in the Lecture Video to describe what you have done and what you have observed. You also need to provide explanation to the observations that are interesting or surprising. Please also list the important code snippets followed by explanation. Simply attaching code without any explanation will not receive credits. The report is submitted through Blackboard Email is not accepted under any situation. At the end of your assignment answer the following questions :

1. Explain in your own words the difference between using the 16.04 and 20.04 VMs in running the tasks?

2. Can you use VM20.04 to run task 4 “TCP RST Attacks on Video Streaming Applications” and explain?

Important Notes and HINTS:

1- You need to build you the Python code and have detailed explanation for each statement and the reason you decided to use this statement and how it will affect the code execution.

2- Make sure you explain each command use and state what it is used for, inclouding simple terminal commands.

--Do not use Netwox—

Please find the configuration file for the lab on blackboard

• You must show the details of your work (Explanation of every step even command) with screenshots if you do not show the details of you will not get a grade for the question.

• Again, make sure you explain in details and proof your work failing in doing so you will get a Zero in your HW

• You need to download the C program and compile it, also you need to make sure how it runs. (SHOW DETAILED EXPLENATION)

Important Notes:

1. Show with screen shots and explanation how you set up the lab environment

2. You need to show and explain every step even when you run the Python file (how you ran it and explain the code)

3. Do not forget to in cloud screen shots while you are executing the tasks

4. Again make sure you have good explanation for each step.