The ASCENT Security Teaching Lab

Lab Setup Directions and Exercises*

Authors: Jun-Won Ho, Nayantara Mallesh, and Matthew Wright

Last Updated: 05/19/2009

*Material in this report also appears in:

Jun-Won Ho, Nayantara Mallesh, and Matthew Wright, "The Design and Lessons of the ASCENT Security Teaching Lab," Proc. of the Colloquium for Information Systems Security Education (CISSE), Jun. 2009.

This work was supported in part by the National Science Foundation under award number DUE-0621280. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect those of the National Science Foundation.

Table of Contents

The ASCENT Security Teaching Lab Setup and Exercises..................................1Table of Contents..................................................................................................21. Overview...........................................................................................................32. Lab Setup..........................................................................................................4

2.1 NFS Setup...................................................................................................52.1.1 Server Setup.........................................................................................52.1.2 Client Setup...........................................................................................7

2.2 Xen Setup....................................................................................................82.2.1 System Requirements:..........................................................................82.2.2 Xen software Installation.......................................................................92.2.3 Build Xen Guest Domain (Guest OS)..................................................10

3. Lab Exercises...............................................................................................193.1 Buffer Overflow Attack...............................................................................19

3.1.1 Prelab..................................................................................................193.1.2 Lab......................................................................................................20

3.2 Command Injection Attack & Virus Creation..............................................213.2.1 Prelab..................................................................................................223.2.2 Lab......................................................................................................22

3.3 Securing Linux Host & Creating Application Level Rootkit in Linux...........233.3.1 Prelab..................................................................................................233.3.2 Lab......................................................................................................24

3.4 Intrusion Detection, ACL, Nessus, and Metasploit.....................................263.4.1 Prelab..................................................................................................263.4.2 Lab......................................................................................................26

3.5 Cracking WEP...........................................................................................293.5.1 Prelab..................................................................................................293.5.2 Lab......................................................................................................29

4. Related work................................................................................................31References..........................................................................................................32

1. Overview

ASCENT – the Alliance for Secure Computing Education in North Texas – is a joint NSF-funded project between the University of North Texas (UNT), the University of Texas at Arlington (UTA), and the University of North Carolina at Greensboro (UNCG). One of the main goals of ASCENT is to provide laboratory equipment for the participating schools and develop exercises for students in security.

As one of the participating schools, UTA has procured equipment and put together a lab – the ASCENT security teaching lab (or ASCENT lab) – for use in three courses. We designed architecture for the lab, including virtualization based on Xen, a NFS file server, laptops, workstations, and networking. For students to make use of the lab, we have created a set of hands-on exercises that are appropriate for seniors and graduate students in computer science. The exercises allow students to develop and test both attack and defense both for hosts and on the network. We have put these exercises into a workbook that is available at our website: http://isec.uta.edu/ascent/

The lab has now been used, at various stages of development, for three courses held a total of five times. Additionally, we brought our materials to India and built a similar lab in a classroom in a software company, with interesting results. Through these classes, we have gained valuable experience in designing and building both the lab and the exercises. In this paper, we describe our lessons. In particular, we focus on the difference between our hopes and expectations and our actual experiences. While many of our goals have been achieved, we have also faced some challenges.

We begin in Section 2 with the description of the lab setup. In Section 3, we describe the lab exercises. Section 4 reviews related work.

2. Lab Setup

The ASCENT lab consists of 5 Dell desktop computers and 17 Lenovo laptops, three switches, two Cisco XX routers, and VPN boxes. The lab machines are, for most exercises, disconnected from the Internet. While we don’t believe that any of our exercises could be a genuine threat to other networks, this helps ensure that no incidents escape the lab environment. We utilized the Network File System (NFS) for lab exercise management. Specifically, we configured one desktop machine as an NFS server and the other desktops and laptops as NFS clients. All lab exercise materials are placed in a designated directory on the NFS server and this designated directory is mounted by all client machines. Thus, lab materials on the server can be accessed by any client machine.

We gain the following benefits from employing NFS. First, we do not need to assign each student a designated client machine because all lab hand-ins are synchronized on the server regardless of which client machines are used for lab tasks. This is particularly useful for students to do their lab exercises over multiple sessions, as they do not need to remember which client machines they were using before and they can join different lab sessions when necessary. Second, we do not need to access each client machine for lab grading, nor have the students download and submit their work, but only need to access a single server. This helps reduce grading time substantially. In the Fall 2007 semester, 45 students registered in the lab sections. Since we only had 13 client machines at that time, we employed Xen virtualization systems to enable all students to use the labs at the same time. Xen enables multiple operating systems to run on a single computer. We installed multiple Fedora 7 operating systems on each computer with the aid of Xen. We successfully operated the lab sections, thanks to virtualization, even though we had fewer computers than the number of students.

Now we present the details of how to setup NFS [9] and Xen [10] on Fedora 7 operating system.

2.1 NFS Setup

Before configuring NFS, you first should gain root privilege on both the server and each of the clients.

2.1.1 Server Setup

(1) Add the following entry to /etc/exports:

/home client's network address(rw,sync) /opt client's network address(rw,sync)

Example:

/home 192.168.10.0/255.255.255.0(rw,sync) 10.2.1.0/255.255.255.0(rw,sync)/opt 192.168.10.0/255.255.255.0(rw,sync) 10.2.1.0/255.255.255.0(rw,sync)

All necessary files for lab exercises are placed in the /opt directory.Hence, we export the /opt directory as well as the /home directory. For each directory, you can add as many network addresses of clients as needed.

(2) Read the export tables again after changing to /etc/exports.

> exportfs -rv

(3) Add the following entry to /etc/hosts.deny:

lockd:ALLmountd:ALLrpcbind:ALLrquotad:ALLstatd:ALL

(4) Add the following entry to /etc/hosts.allow:

lockd:[ip address of client #1],...,[ip address of client #N]mountd:[ip address of client #1],...,[ip address of client #N]rpcbind:[ip address of client #1],...,[ip address of client #N]rquotad:[ip address of client #1],...,[ip address of client #N]statd:[ip address of client #1],...,[ip address of client #N]

Example:

lockd: 10.2.1.0/255.255.255.0

mountd: 10.2.1.0/255.255.255.0rpcbind: 10.2.1.0/255.255.255.0rquotad: 10.2.1.0/255.255.255.0statd: 10.2.1.0/255.255.255.0

(5) Daemons Port Setup.

Edit /etc/sysconfig/nfs to include:

STATD_PORT=4000 LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 MOUNTD_PORT=4002 RQUOTAD_PORT=4003

Edit /etc/modprobe.conf to include:

options lockd nlm_udpport=4001 nlm_tcpport=4001

(6) Configure the firewall

Modify the firewall configuration file, /etc/sysconfig/iptables, to include:

# Allow NFS Connections-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 4000:4003 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 4000:4003 -j ACCEPT

Restart iptables > /sbin/service iptables restart

(7) Start Portmapper, the nfs daemon, and nfslock daemon.

/sbin/service rpcbind restart/sbin/service nfs restart/sbin/service nfslock restart

(8) Make sure that the portmap, nfs, and nfslock daemons start at boot time.

/sbin/chkconfig rpcbind off

/sbin/chkconfig nfs off/sbin/chkconfig nfslock off

/sbin/chkconfig --level 345 rpcbind on/sbin/chkconfig --level 345 nfs on/sbin/chkconfig --level 345 nfslock on

2.1.2 Client Setup

(1) Add the following entry to /etc/hosts.deny:

lockd:ALLmountd:ALLrpcbind:ALLrquotad:ALLstatd:ALL

(2) Add the following entry to /etc/hosts.allow:

lockd:[server's IP address]mountd:[server's IP address] rpcbind:[server's IP address]rquotad:[server's IP address]statd:[server's IP address]

(3) Edit /etc/sysconfig/nfs to include:

STATD_PORT=4000

(4) Make sure that the nfs daemon is off and the portmap and nfslock daemons start at boot time.

/usr/sbin/chkconfig rpcbind off/usr/sbin/chkconfig nfs off/usr/sbin/chkconfig nfslock off /usr/sbin/chkconfig --level 345 rpcbind on/usr/sbin/chkconfig --level 345 nfslock on

(5) Create the directories to be mounted:

mkdir /mnt/home

mkdir /mnt/opt(6) Edit /etc/fstab file to let the netfs service know the mount points.

[server's IP address]:/home /mnt/home nfs rw.hard,intr,bg 0 0[server's IP address]:/opt /mnt/opt nfs rw.hard,intr,bg 0 0

Example:

10.2.1.14:/home /mnt/home nfs rw,hard,intr,bg 0 010.2.1.14:/opt /mnt/opt nfs rw,hard,intr,bg 0 0

(7) Mount the directories

> /sbin/service netfs restart

2.2 Xen Setup

Before installing and configuring Xen, you first should gain root privilege in the server and clients.

2.2.1 System Requirements:

- System must use GRUB to boot the Xen hypervisor.

- Minimum Memory per guest OS: 256MB.

- Minimum Storage Space per guest OS: 600MB(Text), 3GB(GUI)

Before installing the Xen software, you first need to check if the CPU has the PAE extension for running para-virtuallized guests. For this purpose, use the following command: grep pae /proc/cpuinfo

The output should contain "pae" string if the CPU supports PAE extension.

2.2.2 Xen software Installation

- Installation Procedure:

(1) Click Applications in the menu bar. (2) Click Add/Remove Software tab. (3) Package Manager window pops up.

(4) Search for keyword "xen" (5) Install the following packages

virt-manager-0.4.0-2.fc7.i386xen-3.1.0-2.fc7.i386xen-devel-3.1.0-2.fc7.i386xen-libs-3.1.0-2.fc7.i386kernel-xen-2.6.20-2925.9.fc7.i686 koan-0.6.0-1.fc7.noarch python-virtinst-0.200.0-2.fc7.noarch

The packages to be installed are captured in the following picture.

Reboot the computer and let the system boot into the Xen kernel. You can check whether Xen kernel is running as follows:

[root@localhost]# xm listName ID Mem VCPUs State Time(s) Domain-0 0 500 2 r----- 8756.6

Edit /etc/xen/xend-config.sxp to set Network Address Translation (NAT) as the network interface between host and guest domain.

(network-script network-nat) (vif-script vif-nat) Disable the other interfaces, route and bridge by commenting out them.

2.2.3 Build Xen Guest Domain (Guest OS)

We use Logical Volume Management (LVM) to make the storage space for Guest Domains.

Example: [root@localhost]# pvcreate /dev/sda5: create physical volume in /dev/sda5 [root@localhost]# vgcreate xen_vg /dev/sda5: create volume

group whose name is "xen_vg" [root@localhost]# lvcreate -L10G -nxen_3 xen_vg: create logical volume whose name is "xen_3" and storage space is 10GB. [root@localhost]# lvcreate -L1G -nxen_3_test xen_vg: create swap space with 1GB. [root@localhost]# mkswap /dev/xen_vg/xen_3_test

We use Virt-Manager to create new guest domain.

(1) Naming your virtual system: xen_2 (2) Choosing a virtualization method: Paravirtualized (3) Locating installation media: Install Media URL: http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Fedora/i386/os/

(4) Assigning Stroage Space: Normal Disk Partition: /dev/xen_vg/xen_2

(5) Connect to host network: Virtual Network: default

(6) Allocate memory and cpu

VM Max Memory (MB): 256 VM Startup Memory (MB): 256 VCPUs: 1

(7) Click Finish

You have created a new guest domain xen_2.

In order to install the Fedora OS into guest domain xen_2, we need to link the vif interface to the virbr0 interface by using brctl command as follows.

[root@localhost Xen_setup]# brctl addif virbr0 vif4.0

[root@localhost Xen_setup]# brctl showbridge name

bridge id STP enabled interfaces

tmpbridge 8000.000000000000 no

virbr0 8000.feffffffffff no vif4.0

The Virtual Machine Console pops up. Follow the instructions that are displayed in the virtual machine console. Network Setup should be as follows:

IP address : 192.168.122.2 ~ 192.168.122.254 subnet: 24

gateway : 192.168.122.1

DNS server: IP address of DNS server

The above creation procedures are captured in the following pictures

In order to activate the guest domain, SELinux should be set to "Permissive" mode.

Guest domain activation procedure: (1) Click the "Applications" toolbar

(2) Select "System Tools -> Virtual Machine Manager".

(3) The Virtual Machine Manager window pops up.

(4) Select the domain which you want to run and click the right mouse button with "run" tab.

Reset the memory usage of each domain:

> xm mem-set domain-ID Memory

3. Lab Exercises

We developed lab exercises for students to gain hands-on experiences in the system and network security fields. Before doing lab exercises, students were required to do pre-labs. The main purpose for pre-labs is to help students become familiar with lab contents and not waste as much time getting up to speed in the lab.

In the following pages, we present pre-lab and lab exercises on five topics:

Software Security 1 (Buffer Overflows) Software Security 2 (Command Injection and Virus Creation) System Security (Securing Linux and Rootkits) Network Security (IDS, Firewall, and Scanning) Wireless Security (WEP Cracking)

3.1 Buffer Overflow Attack

3.1.1 Prelab

(1) What's the main purpose for inserting NOP code into exploit code?

(2) List the C library functions that can produce buffer overflow attack.

(3) Stack randomization technique is regarded as a defense mechanism against bufferoverflow attack. How does stack randomization make it hard for buffer overflowattack to occur?

(4) In the program test.c, find the values for FOO and BAR that cause the programto print 0 instead of 1. You can use the class-printstack.c program to view the stack layout.

3.1.2 Lab

(1) Objective: the objective of this assignment is to find out buffer overflow vulnerabilities in FTP server program, and exploit these vulnerabilities to crash the program or execute arbitrary shell code in the running program.

(2) Background: we consider the simple scenario of FTP server. In this scenario, FTP server provides three types of functionalities: CMD, GET, and PUT. CMD commandlists the files in the FTP server. GET command allows client to download file from the FTP server. PUT command allows client to upload file to the FTP server. Source code of FTP server contains strcpy and we use it to mount buffer overflow attack. The strcpy function copies its second argument string to the first argument string, but does not check whether the second argument does conform to the first argument in terms of the string length. We can crash FTP server or spawn the shell by exploiting this property.

(3) What to Do: FTP server program is sftp.c and exploit programs are crash.c and spawn.c. Both exploit programs contain networking part that connects exploit programs to FTP server. You will use crash.c to crash the FTP server and spawn.c to spawn a shell from it.

Crashing FTP server

a) Find out the buffer overflow vulnerabilities in FTP server program.

b) Fill in the crash code part of crash.c.

c) Crash FTP server by running exploit program.

Constructing exploit code

a) Find out the EIP address that will be replaced with the address of shell spawning code.

b) Fill in the exploit code part in spawn.c. You need to construct this part with EIP address, NOP, and shell spawning code.

Spawning a shell

a) Try to execute exploit program. You will fail to spawn a shell. This is because that the stack of FTP server program is not executable. Hence, you need to make FTP server program have executable stack as follows:

b) Compile sftp.c with the following options.

> gcc -z execstack -o sftp sftp.c

c) Let the sftp program have executable stack by running the following command.

> execstack -s ./sftp

Shell code cannot be executed inside the stack of FTP server program without this configuration.

d) Spawn a shell from running FTP server by executing exploit program.

(4) What to Turn in:

Crashing FTP server

a) Describe the vulnerabilities that you have found out.

b) Turn in crash.c in which you have filled in the crash code part.

c) Describe how you fix the vulnerabilities for FTP server not to be crashed.

Constructing exploit code

a) Specify the EIP address that you found out.

b) Specify how to construct exploit code with EIP address, NOP, and shell code.

Spawning a shell

a) Describe the result when FTP server dose not have executable stack.

b) Turn in the spawn.c in which you have filled in the exploit code part.

3.2 Command Injection Attack & Virus Creation

3.2.1 Prelab

For problem 2 and 3, please refer to the output-trunc.c file. This file has almost allof the individual components that you need to write programs.

(1) Write a program that takes a file as a command line argument and copies the second half of the file to a temporary file that is user readable, writable, and executable. Have the program output the size and permissions of the temporary file.

(2) Write a program that takes two files, let us call them A and B (again, given as command line arguments) and puts the contents of A at the beginning of B. Hint: you can't just copy the contents of A directly into B, just like you can't prepend a value to the beginning of an array.

(3) How can system function take multiple commands as its argument? In other words, how can you execute multiple commands ls, date, ps by using the system function?

3.2.2 Lab

(1) Objective: the objective of this assignment is to get some experience with figuring out the command injection vulnerability of server, exploiting it to launch command injection attack, and creating your own virus.

(2) Background: In command injection attack, we consider the simple scenario of file server. In this scenario, file server stores a set of files and supports three types of functionalities: List, Show, Exit. List command prints the list of all files stored at the file server. The Show command takes file name as an argument and displays the contents of it. The Exit command allows client to close the connection to file server. Source code of file server contains the system function that takes commands as its arguments. By setting proper arguments, we can execute multiple commands.

In virus creation, you will make your own virus that is working on Linux system. Specifically, you will infect the uname utility by prepending viral code to it. Once uname is successfully infected, you will see that the size of uname has been increased by the size of viral code. You will then test how uname infects other utilities such as echo.

(3) What to Do:

Command Injection Attack.

a) In server.c, figure out the vulnerability through which arbitrary commands can be injected into arguments of system function.

b) Fill in the injection part of exploit.c to execute df command in file server.

c) Inject df command into server by running exploit program against file server.

Virus Creation.

a) Fill in the code insertion parts of virus.c.

b) Compile virus.c by running the following command.

> gcc -o virus virus.c

c) Check the size of virus program by running ls -al

d) Reset the code size variable of virus.c to the size of virus program.

e) Recompile virus.c by using gcc.

f) Run ./virus ./uname and ./uname

g) Run ./uname ./echo and ./echo

(4) What to Turn In:

Command Injection Attack.

a) Describe the vulnerability that you have found and suggest a way to fix it.

b) Turn in exploit.c in which you have filled in the injection part.

Virus Creation.

a) Turn in virus.c in which you have filled in the code insertion parts.

b) Specify the output from running uname infected by virus program.

c) Specify the output from running echo infected by the uname utility.

3.3 Securing Linux Host & Creating Application Level Rootkit in Linux

3.3.1 Prelab

(1) What is shadow password file in Linux? How does the shadow password file work?

(2) List file access permissions in Linux.

(3) What is a rootkit? List five different types of rootkits. What kind of rootkit is hardest to detect and remove? Justify your answer.

(4) Describe how port-binding shell makes it possible for backdoor program to run on the target machine.

(5) Write a program that checks whether input string is in the file. We will provide you the program check.c. In check.c, you need to fill in init items and check item functions. Furthermore, you need to create a file with the name of items and fill in the file with arbitrary strings. You will test whether the program is correctly running with the file.

3.3.2 Lab

(1) Objective: the objective of this assignment is to get some experiences in securing Linux host system, creating application level rootkit and hiding it from the system.

(2) Background: when setuid and setgid access permissions are given to a file and the file is executed, the running process has the same access permission as the owner and group of the file being executed, respectively.

A rootkit is a software program to enable the adversary to hide running malicious programs from host operating system. The adversary first gains root access on the victim system and then installs the rootkit on the victim system. The rootkit allows adversary to keep root access on the victim system and run malicious programs on it without being exposed.

We can break rootkit into five categories: firmware, virtual, kernel, library, application level rootkits. Firmware level rootkit exploits device or platform firmware to create backdoor in the victim system. Virtual level rootkit run on the virtual machine such as VMware or Xen. Kernel level rootkit add extra codes or modify existing codes to conceal backdoor in the victim system. Library level rootkit replaces system calls with ones that do not expose adversary information to operating system. Application level rootkit replaces application binaries with maliciously injected fake ones or modifies the existing applications using patches.

In this exercise, you will set user and group IDs and make a backdoor program that enables the adversary to connect the victim server without any authorization, execute commands, and hide the backdoor program from system.

(3) What to Do:

Set User & Group ID.

a) Set setuid permission on the temp file by using the command chmod u+s temp.

b) Set setgid permission on the temp file by using the command chmod g+s temp.

Create backdoor program.

a) Backdoor program backdoor.c will create a backdoor in your machine.

b) Fill in the insertion parts of backdoor.c.

c) Create a backdoor by running ./backdoor 15000 in your machine.

d) Establish a telnet connection to the backdoor program and execute the command uname –a.

Hide the backdoor program from the system.

a) Fill in the insertion parts in ps.c.

b) Compile ps.c by running make.

c) Run ./backdoor1 20000 &

d) Run ./backdoor2 20001 &

e) Run ./backdoor3 20002 &

f) Run ./ps

(4) What to Turn in:

Set User & Group ID.

a) Specify the access permission status of temp file by running the command:ls -l temp.

b) Explain how adversary can exploit setuid and setgid access permissions to launch attacks.

Create a backdoor program.

a) Turn in backdoor.c.

b) Specify the output of running uname -a.

Hide the backdoor program from system.

a) Turn in ps.c that forces the backdoor program not to be revealed.

b) Specify the output of running ./ps

3.4 Intrusion Detection, ACL, Nessus, and Metasploit

3.4.1 Prelab

(1) What is snort? List the four configuration modes of snort and briefly describe each mode.

(2) What is Nmap? Describe the difference between open state and filtered state in Nmap.

(3) Describe the main functionalities of IPFilter.

(4) What is Nessus? What are the two most commonly used types of port scans in Nessus? Explain the advantage and disadvantage of each type.

(5) What is Metasploit? List the options used by most exploits to specify the target address and the target port.

3.4.2 Lab

(1) Objective: the objective of this assignment is to get some experience with how to configure access control list using TCPWrapper, use the Snort tool to perform intrusion detection, find out the vulnerabilities of host using Nessus, and launch a buffer overfow attack against a server using the Metasploit tool.

(2) Background: TCP Wrapper is a host-based access control system. Nmap is a port scanner and Snort tool is a rule-based intrusion detection tool. Nessus is a tool for figuring out the vulnerabilities of host. Metasploit is a tool for launching various kinds of attacks against the victim machine.

(3) What to Do:

Setting up the access control list using TCP Wrapper.

a) In order to block ssh connection attempt from loopback IP address 127.0.0.1, open the /etc/hosts.deny file by running sudo vi /etc/hosts.deny and add the following configuration to it:

sshd : 127.0.01 : spawn /bin/echo Access attempt at `/bin/date`from %a >> /home/your_login_name/Lab4/ssh.log : deny

Then, change your_login_name to your real login name.

Intrusion detection using snort

a) The IP address of attacker machine is 192.168.10.21. Attacker machine scans system ports of your machine using nmap. To detect these intrusion attempts, we will use network intrusion detection system mode of Snort.

b) Create the port_scan.rule file in your home directory and edit it to include the following:

alert icmp 192.168.10.21 any -> 192.168.10.0/24 any

c) Run ./port_scan.bash. This will let Snort detect any intrusion matching port_scan.rule and dump the detection results to icmp_output file.

Port Scan using Nmap.

a) The IP address of target machine for port scan is 192.168.10.21. Verify that the target machine is alive by running the command ping 192.168.10.21.

b) Run nmap -A 192.168.10.21

Nessus.

a) Add user information to the Nessus database by running the nessus-adduser command. Type pass when setting the authentication part, skip the part on user rules, and hit ctrl-D.

b) Start the Nessus service by running the command nessusd -D &.

c) Create targets.txt by running echo 127.0.0.1 > targets.txt. Start a scan by running nessus -xq localhost 1241 login password targets.txt report.txt.

d) The results of the scan are dumped into the file report.txt. Go through the ports and messages given in this file.

Metasploit.

a) The IP address of target machine is 192.168.10.21. To launch an attack against the target machine, we will use the Icecast header module that exploits the buffer overflow in the header of icecast program.

b) Run the command tar -zxvf framework-2.7.tar.gz.

c) Go to the framework-2.7 directory and run perl msfconsole.

d) Run use icecast header.

e) Run set RHOST 192.168.10.21.

f) Run set RPORT 8000 and set LPORT 4444.

g) Run info win32 bind.

h) Run set PAYLOAD win32 bind.

i) Launch a buffer overflow attack by running the exploit command. You will see the command prompt shell of Windows XP running on the target machine.

(4) What to Turn in:

Setting up the access control list using TCP Wrapper.

a) List the contents of the ssh.log file.

b) Briefly describe the basic function of the spawn command.

Intrusion detection using Snort

a) Specify attacker's IP address by viewing the alert file. Use the command sudo cat alert to open the alert file.

b) Try to understand port_scan.rule. If incoming packets match port_scan.rule, then what happens to those packets?

Nessus

a) Specify the vulnerabilities found on port general/tcp and the solution.

b) Describe SSHv2 host key fingerprint, SSH version and SSH supported authentication.

Port Scan using Nmap

a) List the table of port, service, state, version, and the version of OS running on target machine.

Metasploit

a) Write the description of win32 bind payload.

b) Specify the version of Windows XP and the current directory.

3.5 Cracking WEP

3.5.1 Prelab

(1) Why do some wireless cards work with WEP Crack and others don't?

(2) If we can know the channel information of the target network to attack, we can speed up collecting Initialization Vectors (IVs) sent by APs in the target network. Why?

(3) If MAC address filtering is set up by the AP, the AP only accepts packets from the addresses of authenticated users. Is there any way for unauthenticated users to communicate with the AP? If so, describe it.

(4) If no traffic is being passed, we cannot capture any packet from AP. How can we force the AP to send data packets to network?

3.5.2 Lab

(1) Objective: the objective of this assignment is to get some experience with setting up a wireless LAN card in Linux and cracking WEP using the Aircrack tool.

(2) Background: Wired Equivalent Privacy (WEP) was the privacy mechanism of the original IEEE 802.11 standard and was deprecated in 2004 due to security flaws. WEP uses the stream cipher RC4 and a CRC-32 checksum for data confidentiality and integrity, respectively. In this exercise, you will test how the secrecy of WEP can be easily broken through a cracking tool.

(3) What to Do: Setting up the Wireless LAN Card.

a) Install the MadWiFi WLAN driver by running ./madwifi.bash.

b) Load the MadWifi driver module into Linux by running ./module.bash. If you do not see any output, the driver has not been successfully loaded into the system. Try to install and load it into the system again.

c) In order to insert the scanning module, bring up the wireless interface ath0, and do an active scan by running ./scan_bringup.bash. You will see the output of active scanning. Note that LinkSys is the SSID of the target network. You can find out the BSSID and channel of the target network from the output.

d) In order to create a monitor mode interface and check whether monitor mode is correctly setup, run ./setup_monitor.bash. You will see two wireless interfaces ath0 and wifi0. Since wifi0 is in monitor mode and we don't need ath0, destroy the ath0 interface by running ./destroy.bash.

Cracking WEP.

a) Install the aircrack tool by running ./aircrack.bash.

b) Activate a monitor mode interface. If target network channel is 6, run the following command:

./activate_monitor.bash 6

If the monitor mode interface was successfully activated, you should see the ath0 interface in the output. Data packets will be captured through ath0 interface.

c) Start capturing IVs. If the target network channel is 6, run the following command:

./capture.bash 6

d) If you have captured at least 15,000 packets (under # Data field), start to crack WEP. The format of the output file is output-xx.ivs. If you type the ls command, you can see the list of output files. If the target network bssid is 00:15:B4:F2:E5:34 and output is output-01.ivs, run the following command:

./crack.bash 00:15:B4:F2:E5:34 output-01.ivs

Do not stop running the capture program. The crack program will automatically update new IVs from capture program. Keep both programs running until the WEP key is found.

(4) What to Turn in:

a) List the WEP Key when it is found.

4. Related work

A number of others have reported on their experiences designing and implementing laboratories and exercises for security course work. We now describe some of this prior work.

Tikekar and Bacon describe their laboratory setup and a large variety of projects used in their courses . While they provide an excellent set of ideas for projects, many of which we also use, they do not use NFS or virtualization and do not discuss principles of exercise design in much detail. Carlson provides a nice introduction to initiating security courses, also with a list of exercises and report of how successful each one was .

Schembari reports on experiential exercises designed for a course in cryptography . He concludes that these experiences improve the learning and enjoyment of the course. Kessler and Hoag describe how to create forensics exercises without the use of a lab environment . However, our offensive exercises require an isolated environment for safety.

Vigna describes several network configurations and comments on their respective advantages and disadvantages . In particular, he finds that an image server that can reinstall the OS in a few minutes is a useful tool, as is a fail-safe mode for checking on the availability of victim machines and reinstalling and rebooting when needed. None of our exercises required these features, partially due to virtualization and partially due to having mainly closed-form exercises.

Border reports on the technical details of setting up a remote virtualization-based lab for classes including security . His approach is based on VMWare. We are not convinced that virtualization is sufficient to make the lab exercises we offer safe and more acceptable to third parties, such as the university’s network administrators.

Padman and Memon describe an interesting alternative to the isolated lab environment: a virtual laboratory that can be shared between multiple institutions . The virtual laboratory is accessible through a browser interface and is remotely configurable. The browser interface would likely engender greater feelings of safety by third parties than virtualization alone (regardless of actual risk). This approach is compelling for sharing lab resources, but is not appropriate for our present situation.

Abler et al. describe the use of realistic network topologies for the security lab at the Georgia Institute of Technology . The lab is unique in emulating a small part of the Internet, allowing for more realistic scenarios. This is an excellent approach, but it requires approximately 22 routers and most of our lab exercises have little direct benefit from the realistic networks. Nevertheless, their approach would create perhaps the most exciting and engaging environment for learning network security.

5. Acknowledgements

Thanks to Steve Tate for identifying key pieces of laboratory equipment and giving us a basic lab design to build upon. Donggang Liu co-taught the primary lab course and contributed most of the buffer overflow lab, including the vulnerable server. Amit Singh kindly provided the Jingle Bell code from his website. Giovanni Vigna graciously provided the prior years’ CTF images on the UCSB CTF website. Thanks to Steve Tate, Ebru Celikel, Vandana Gunupudi, and Roopa Vishwanathan for their efforts running the CTF. Thanks also to Infosys Technologies Limited, and in particular Dr. V. P. Kochikar, Dr. P. Suresh P., and Alsaad Ishaq, who hosted us at the Infosys campus in Mysore.

References

[1] G. Vigna, “Teaching Hands-On Network Security: Testbeds and Live Exercises,” Journal of Information Warfare, Vol. 2, Issue 3, Aug. 2003.

[2] R. Tikekar and T. Bacon, “The Challenges of Designing Lab Exercises for a Curriculum in Computer Security,” The Journal of Computing in Small Colleges, Vol. 18, Issue 5, May 2003.

[3] D. Carlson, “Teaching Computer Security,” SIGCSE Bulletin, Vol. 36, Issue 2, 2004.

[4] N. P. Schembari, “‘Hands-On Crypto’: Experiential Learning in Cryptography,” Proc. Colloquium for Information Systems Security Education (CISSE ’07), June 2007.

[5] G. C. Kessler and J. Hoag, “The Power of Simple Hands-On Cyberforensics Exercises: A Guide for Faculty,” Proc. Colloquium for Information Systems Security Education (CISSE ’08), June 2008.

[6] C. Border, “The development and deployment of a multi-user, remote access virtualization system for networking, security, and system administration classes,” Proc. SIGCSE Technical Symposium on Computer Science Education (SIGCSE), Mar. 2007.

[7] V. Padman and N. Memon, “Design of A Virtual Laboratory for Information Assurance Education and Research,” Proc. IEEE Workshop on Information Assurance and Security, 2005.

[8] R. T. Abler, D. Contis, J. B. Grizzard, and H. L. Owen, “Georgia tech information security center hands-on network security laboratory,” IEEE Trans. on Education, Vol. 49, Issue 1, Feb. 2006.

[9] http://optics.csufresno.edu/~kriehn/fedora/fedora_files/f7/howto/nfs.html.

[10] http://fedoraproject.org/wiki/FedoraXenQuickstartFC6.