Download Understanding the Impact of Climate Change on Agriculture and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
ECE 4112: Internetwork Security
Lab 8: Viruses, Worms, and Wireless
Group Number: _______________ Member Names: _________________________ _________________________ Date Assigned: October 23, 2007 Date Due: October 30, 2007 Last Edited: November 5, 2007 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE the Date Due. NOTE: The wireless lab section requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. The equipment you need to sign up for will not be available at the last minute. PLAN AHEAD. Part 1 Viruses and Worms Goal: The goal of this lab is to come to a better understanding of viruses and worms by experimenting with them in a safe environment. Summary: In this lab we will first look at two worms, one designed as a learning tool and an actual worm that had infected computers. Then we will look at a virus. In all three cases we will actually infect our computer to see how it is done and what happens to our computer then we will completely remove the malicious program. Background and Theory: A worm is any program that propagates copies of itself via a network. They come in many varieties, from simple email worms to those that attack network services such as Code Red and SQL Slammer. We are going to analyze a simple version of the latter. This worm, dubbed the SPOC Worm (Simple Proof Of Concept) propagates itself through a buffer overflow in a network service known as “vuln_service.” This is a service created for this lab. It opens up a TCP socket on port 3333 that allows a connection and can be easily compromised. The program simply reads any data sent to it, but it uses a weak command (see question 1.6) that allows it to be overflowed. Any other network service with a buffer overflow
vulnerability can be targeted instead, but “vuln_service” is particularly easy to study due to its simplicity. The SPOC Worm first scans all LANs it is connected to and tries to connect to port 3333 (the port that “vuln_service” runs on). Upon finding any open ports, it connects, sends a special string formatted to overflow the buffer, and executes a copy of the worm. After finishing, it begins scanning random IP addresses looking for more vulnerable services. Detailed information about this worm may be found in the paper “Design and Implementation of a Research Worm.” [on class web site] In 2001, there was a worm called “AnnaKournikova” that propagated by being sent as an e-mail attachment with the subject “Here you have, ;o)” and a body of “Hi:”,”Check This!” By opening the attachment, a VBScript file ran that sent a duplicate e-mail to every entry in a Microsft Outlook Address Book. In order for this worm to run, it required a Windows platform machine with the Windows Scripting Host and Microsoft Outlook installed. This worm did not damage any files, but it clogged up many mailservers. The AnnaKournikova worm VBScript file and its unencrypted source code can be downloaded from this site: http://www.packetstormsecurity.org/viral-db/ Viruses work in a different way by infecting files but not spreading until a user moves that file to another computer. Prelab Questions: None. Lab Scenario: You will be using the RedHat WS 4 Physical Machine, RedHat7.2 Virtual Machine, and later a Windows XP virtual machine in the last part of the lab. The setup you will be implementing for section 1 is shown below: In the above diagram, 57.35.6.a corresponds to the IP of your RH WS4 Physical Machine and 57.35.6.b corresponds to the IP of one of your RH7.2 Virtual Machine. These can be checked with #ifconfig After you copy what you need from the NAS, to be safe, make sure your network cable is unplugged, this will ensure your worms do not try to infect another groups RH WS4 Physical Machine Attacker 57.35.6.a RH7.2 Virtual Machine Server 57.35.6.b
Strace is a program which will allows us to watch what each program is doing by printing each system call that the program makes. We should see a lot of stuff go by and then see it settle on a call to accept. Accept makes the program wait until it receives a connection from the network. Now run Ethereal on the RedHat WS4 Physical Machine (Attacker), and have it begin capturing packets RedHat -> Internet -> Ethereal Network Analyzer Capture-> options then start OK To get more acquainted with strace, let’s watch what happens when we use the service correctly. From the RedHat WS4 Physical Machine (Attacker) machine, type #telnet 57.35.6.b 3333 When it connects, type the string “hi”. You should see a sequence of reads and writes occurring in “vuln_service.” Disconnect the telnet session (type ‘Ctrl-]’) and then type ‘quit’ at the prompt). Now let’s use strace to analyze our worm. You have copied the executable file worm onto the RedHat WS4 Physical Machine (Attacker), again, do not compile worm.c , just run this file. (The “source code” for the worm is included in Appendix B. The paper ‘Design and Implementation of a Research Worm” found on the class web site explains the worm code development). On the RedHat WS4 Physical Machine (Attacker) type: _#cd attacker
strace ./worm_
A lot of text should now be flowing by. The worm will be executing socket, connect, and close very quickly. This is it attempting to find copies of “vuln_service” by connecting to different IP addresses. Notice how the IP address in the connect call is changing. When it hits 57.35.6.b (the address of the RedHat7.2 Virtual Machine (Server)), it should execute a sequence of sends to send the malicious code to “vuln_service”, which will overflow its buffer and begin executing the worm. When this occurs, the “vuln_service” we ran on the RedHat7.2 Virtual Machine (Server) should begin executing the same familiar socket, connect, and close sequence. You can see this in the terminal you ran “ strace ./vuln_service ” on. This means that the worm has spread to that machine and is looking for more targets. Aside: You will see lots of 127.0.0.y addresses after the server is infected. The worm asks the machine what interfaces are active and sees the loopback interface 127.0.0.1 and begins sending to that network 127.0.0.y Stop packet capture using Ethereal on the RedHat WS4 Physical Machine (Attacker). Leave ethereal running as you will need this output you collected below.
Stop both vuln_service on the RedHat.72 Virtual Machine (Server) and worm on the RedHat8.0 Physical Machine (Attacker) with CTRL-c. Q1.1: The SPOC Worm is incredibly easy to detect. What are some methods you could use to detect the presence of the worm? Q1.2: What are some ways in which the worm could be designed to bypass detection? Q1.3: What is the growth rate of this type of worm given a network with many copies of the vulnerable service running? (Give a general answer) Look at the packets captured by Ethereal. Q1.4: Devise a rule for Snort (see lab 7 for help) that will detect this worm. Add it to the rule base of Snort as done in the forensics lab. Submit the rule with the assignment. Close Ethereal. Run Snort with the new rule base on the RedHat7.2 Virtual Machine (Server). Execute the vuln_service and worm as in the first part of the lab. Q1.5: Does Snort alert you to the worm? Now that you know of the presence of the worm, what do you do if you are responsible for the server? Here is a portion of the vuln_service code (this does not match exactly what is on the machine in the lab (and in the Appnedix) since this code has been cleaned up a bit since installed on the machine: // sockfd is a socket file descriptor to a client void svcHandle(int sockfd) { char paddington[HALFK]; char userinput[BUFFER_SIZE]; if ( (dup2( sockfd, STDOUT_FILENO)) < 0 ) { perror("svcHandle: Error STDOUT_FILENO"); return; } if ( (dup2( sockfd, STDIN_FILENO)) < 0 ) { perror("svcHandle: Error STDOUT_FILENO"); return; } bzero( userinput, BUFFER_SIZE); printf( "1- Input:%s(%d)\n", userinput, strlen(userinput)); printf( "please input a 16 character string:\n"); gets( userinput); printf( "2- Input:(%d)\n", strlen(userinput));
Now run the Windows Task Manager by pressing the key combination Ctrl-Alt-Delete. Click on the Processes tab and you should see a window like in Figure 1. Figure 1. Processes outlined in Windows Task Manager. Don’t you find the fact that CPU Usage is near 100% a little strange for an idle machine? If you look at the processes listed, you will find an executable using most of the CPU resources (in the case of Figure 1, it is wscript.exe). By ending this process, you should notice, in the Performance tab, that the CPU usage should drop down to what is normally expected of an idle machine. Go ahead and run the VBScript file again, and you should notice the CPU Usage again jump back up to nearly 100%. This type of system performance anomaly is one way to detect whether a worm is trying to execute its code. Now make sure you end the worm process before you proceed further. Now let us research what files and registry entries are associated with the worm. Go to this website: http://www.ciac.org/ciac/bulletins/l-046.shtml This site contains information and the history of the AnnaKournikova worm. Notice that some of the information presented is the same as what we deduced from the source code. There are many other database sites that you can find to help research on removing various virus/worms, but we found this site to be the most useful in learning the worm’s effects. Q2.5: What is one way in which anti-virus programs detect worms and viruses? Give an example (hint: look at the source code for the AnnaKournikova script) Now let us manually remove the AnnaKournikova worm by going to the “Removal” section on the website. Basically removal of the worm requires that we kill the running
worm, remove copies of the AnnaKournikova.jpg.vbs file from the C:\WINDOWS directory we put it in, and removing the registry entry. First, let us remove the registry entry. Click on the Start button and select Run. Then type regedit to open the registry editor. Now search for the term OnTheFly since that is where the worm made its registry entry. (You should remember this fact from viewing the source code and reading the information on the website.) The registry editor should find the OnTheFly folder just like in Figure 2. Figure 2. Worm’s Registry Entry “OnTheFly” Now let us delete this entry by right-clicking on the OnTheFly folder and selecting delete. The entry should be removed. Now let us remove the AnnaKournikova.jpg.vbs file from the C:\WINDOWS directory and the Desktop folder we created. Now reboot the WindowsXP virtual machine. The worm should be ineffective now. With this exercise, it is our hope that you learn how a real world worm can operate, where it can hide, and how to remove it by consulting sources. Section 3: Viruses In this portion of the lab, we will see how a computer virus infects a file system in Linux and how a virus is spread. Please read the program Vscr2.c (you have already copied this onto your RedHat WS Physical Machine (Attacker) and also it is included in Appendix D), and try to figure out what the program achieves.
Go back to your / home/lab8 directory and run the file test_virus: #./test_virus Again go back to the directory /usr/local/include and see whether the file stdio.h is in this directory right now. Now to undo the dirty deeds we have done:
- Delete the file stdio.h from the directory /usr/local/include in the two RedHat Machines Server and Attacker. On each machine type: #rm /usr/local/include/stdio.h
- On the RedHat7.2 Virtual Machine (Server) type: #rm /home/lab8/test*
- On the RedHat WS4 Physical Machine (Attacker) type: #rm /home/lab8/test_virus Q3.4: Which source code is malicious, Vscr2.c or test_virus.c? Q3.5: Why is the second Linux machine infected by a virus? Q3.6: If you use a Linux machine, download the file test_virus, and run it, will your system be infected? Q3.7: How do you prevent computer virus? Q3.8: From this lab, what are some notable differences between worms and virus in respect to how they infect a system? Section 4: Worm Generator We have seen in this lab and in the media how damaging worms can be when they get out to the rest of the world. Worms seem to have become more popular to the point where even script kiddies can create one. In this section of the lab, we will examine how easy it is to create a simple worm by creating our own worm in Visual Basic. Start the Windows XP Virtual Machine In the NAS\Lab8 folder, copy the file ssiwg.exe from the NAS to a folder called “worm” on your desktop Double click the file ssiwg.exe. Fill in the fields for your worm’s name, the subject of the e-mail you would like the worm to use, and the e-mail content you would like for your worm. If you like, you can use the “crypt code” option to have the worm’s code appear more cryptic so its not as easy to read Click “MAKE” Notice the yourWorm.vbs file that has been created in your “worm” folder. Answer the questions below by opening the .vbs worm you created in a text editor and going through the code to get a sense of what it does.
Q4.1: What major similarity is there with this worm and the AnnaKournikova worm we looked at earlier? (Hint: how does it spread?) What code clues you into this? Q4.2: How might someone protect themselves from a worm like this?
unchanged, a hacker could try the common SSIDs and connect to your network if there is no other security on the network. MAC Address Filtering MAC address filtering can be used to increase the security of your network. It works by allowing only a set list of network cards to connect based upon their known MAC address, which should be unique for every device. However, MAC address can be captured by snooping and then spoofed which will then allow an attacker to gain access. Most wireless cards now allow MAC addresses to be changed, so this is does not adequately work as a security feature either. WEP Encryption If a user activates WEP, the wireless encrypts the payload (frame body and CRC) of each 802.11 frame before transmission using an RC4 stream cipher provided by RSA Security. The receiving station, such as an access point or another radio NIC, performs decryption upon arrival of the frame. As a result, 802.11 WEP only encrypts data between 802.11 stations. Once the frame enters the wired side of the network, such as between access points, WEP no longer applies. As part of the encryption process, WEP prepares a keyschedule ("seed") by concatenating the shared secret key supplied by the user of the sending station with a random-generated 24-bit initialization vector (IV). The IV lengthens the life of the secret key because the station can change the IV for each frame transmission. WEP inputs the resulting "seed" into a pseudo-random number generator that produces a keystream equal to the length of the frame's payload plus a 32-bit integrity check value (ICV). The ICV is a check sum that the receiving station eventually recalculates and compares to the one sent by the sending station to determine whether the transmitted data underwent any form of tampering while intransient. If the receiving station calculates an ICV that doesn't match the one found in the frame, then the receiving station can reject the frame or flag the user. WEP specifies a shared secret 40 or 64-bit key to encrypt and decrypt the data. Some vendors also include 128 bit keys (know as "WEP2") in their products. With WEP, the receiving station must use the same key for decryption. Each wireless card and access point, therefore, must be manually configured with the same key. Before transmission takes place, WEP combines the keystream with the payload/ICV through a bitwise XOR process, which produces ciphertext (encrypted data). WEP includes the IV in the clear (unencrypted) within the first few bytes of the frame body. The receiving station uses this IV along with the shared secret key supplied by the user of the receiving station to decrypt the payload portion of the frame body.
In most cases the sending station will use a different IV for each frame (this is not required by the 802.11 standard). When transmitting messages having a common beginning, such as the "FROM" address in an e-mail, the beginning of each encrypted payload will be equivalent when using the same key. After encrypting the data, the beginnings of these frames would be the same, offering a pattern that can aid hackers in cracking the encryption algorithm. Since the IV is different for most frames, WEP guards against this type of attack. The frequent changing of IVs also improves the ability of WEP to safeguard against someone compromising the data. WEP has been part of the 802.11 standard since initial ratification in September
- At that time, the 802.11 committee was aware of some WEP limitations; however, WEP was the best choice to ensure efficient implementations worldwide. Nevertheless, WEP has undergone much scrutiny and criticism over the past couple years. WEP is vulnerable because of relatively short IVs and keys that remain static. The issues with WEP don't really have much to do with the RC4 encryption algorithm. With only 24 bits, WEP eventually uses the same IV for different data packets. For a large busy network, this reoccurrence of IVs can happen within an hour or so. This results in the transmission of frames having keystreams that are too similar. If a hacker collects enough frames based on the same IV, the individual can determine the shared values among them, i.e., the keystream or the shared secret key. This of course leads to the hacker decrypting any of the 802.11 frames. The static nature of the shared secret keys emphasizes this problem. 802. doesn't provide any functions that support the exchange of keys among stations. As a result, system administrators and users generally use the same keys for weeks, months, and even years. This gives mischievous culprits plenty of time to monitor and hack into WEP-enabled networks. Due to this, WEP is very easily cracked. In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they broke a WEP-protected network in 3 minutes using publicly available tools. We will perform some of these attacks. One of the most basic attacks a hacker can perform once finding a wireless network is to identify the access point, AP, and check to see if the default settings are in use. A large number of home users, and some businesses, do not change their settings on their AP. Once the brand of the device is known, its default settings are easy to lookup on the Internet, as companies publish them so people can use their devices. [6]
Section 5: Reconnaissance on the network One reason for poor security in wireless networks has nothing to do with the technology; it is due to the operators. Most consumer wireless devices are extremely easy to setup. Many users hook up the equipment and when it works, they do not modify its settings. This leaves huge security holes. We will be exploring a network that does have some security features implemented on it. It will be your job to break into the network and snoop on what is going on inside. Step 0 – Attacker 1 & 2
- Login to Backtrack > bt login: root > password: toor
- Start xWindows > startx Step 1 – Attacker 1 & 2 Now, configure the wireless cards. > ifconfig rausb0 up > airmon-ng > airmon-ng start rausb > iwconfig rausb0 mode monitor
Check & make sure that they are both enabled & in monitor mode before continuing. Step 2 – Attacker 2 Only
- Open Kismet – Start -> BackTrack -> Radio Network Analysis -> 80211 -> Analyzer -> Kismet. Wait for it to load.
- When the list displays, press ‘s’, then ‘c’ and find your target wireless network, ECE4112 in the list.
- Highlight it and press ‘i’. This will bring up details of the wireless AP. Record the MAC address of the AP. Also note the channel that the access point is operating on as you will need this later. It is listed under the BSSID field. Press ‘q’ to exit this screen.
- With ECE4112 still highlighted, press SHIFT + ‘l’. The status in the bottom box should said “Locking Source ‘Ralink_g; to channel x” or similar (where x is the channel of the access point). Don’t close this screen. Question 5.1: What is the MAC address of the AP? Section 6: Cracking the WEP Step 3 – Attacker 2 Only
- Start Ariodump: Start -> BackTrack2 -> Radio Network Analysis -> 80211 -> Aircrark -> Airodump
- Run the command: airodump-ng -w capture --channel –bssid rausb Only look at ones that are associated with our BSSID from kismet screen window. The MAC address of the client connected to AP is listed under ‘Station’ on the screen. It is the one that is associated with the MAC address of the AP. Only pay attention to packets on this connection. Record the MAC address of the client. This is capturing packet information for us to use to break the key in a later step into a file called capture.cap (or capture01.cap, etc. depending on how many times you restart the program). The number listed under Data is a running count of the packets that are being transmitted over the network and captured by the airodump command. As you can see, packets are going slowly. At this rate, it will take us a while to gather enough packets to crack the WEP! Question 6.1: What is the MAC address of the client?
Step 5 Attacker 2 In this step we will install Aircrack-ptw, a better version of Aircrack that takes less packets to crack than the version currently on Backtrack2.
- Get the floppy or USB key containing aircrack-ptw from the TA if it is not already with the Attacker 2 machine.
- Put it in the Attacker 2 machine and copy the aircrack folder to the root directory. To mount the floppy type: mount /dev/fd The files can be found in: /mnt/floppy or /mnt/sdb1_removable depending on whether the floppy or USB key is used.
- Inside the folder, copy aircrack-ptw into usr/local/bin so that you can run it from the terminal.
- Open a terminal and run: aircrack-ptw capture.cap (or whatever your capture file from airodump-ng is called) This command may be run while the packet capture is still in progress, as the file is automatically updated as new packets are captured. If it does not find the WEP key it will display the amount of packets captured thus far and then return to the command prompt. If you were able to get the areplay command from Step 4 to generate arp packets you should be able to find the WEP key in a relatively short time (less than 10 minutes), you just need to keep trying while packets are being captured.
- If it fails to crack it with the packets you captured obtain the capturefile.cap from the provided USB key and rerun the command with this file. It should find the WEP key quickly.
- Once you crack the WEP, stop the airodump from capturing packets and the areplay from sending packets. Question 6.2: How many packets did it take your group to crack the WEP key? Question 6.3: What was the WEP? Section 7: MAC Address Filtering Step 6 - Attacker 1 Now that we have the WEP key we are going to snoop the traffic in the network.
- Open Terminal > ifconfig rausb0 down > ifconfig rausb0 up
> iwconfig rausb0 essid enc mode managed > dhcpcd rausb
- We should be connected now. Ping the router using its address, 192.168.1.
- Did it work? You must have had your MAC address blocked for previous suspicious activity on the network. You must change your MAC address to get access.
- Backtrack2 provides functionality to do this. Open a terminal and type: a. > ifconfig rausb0 down b. Open the MacChanger: Start -> Backtrack -> Misc -> MacChanger c. Since just Attacker 1 & Attacker 2 MACs are blocked, you can choose one at random to use. To do this type: > macchanger –a rausb If only certain MACs are allowed on a network, you could get around it by spoofing a MAC address of someone who leaves the network or that you don’t want to sniff traffic of.
- Now go back to the beginning of this step and try getting on the network again. Ping 192.168.1.1 to make sure it works. Section 8: Man in the Middle Attack Step 7 – Attacker 1
- Open Wire Shark by typing ‘wireshark &’ in the console start capturing on rausb
- Start Ettercap, our Man in the Middle software that you will remember from earlier labs by: Start -> Backtrack -> Privilege Escalation -> Sniffers -> Ettercap
- Set up Ettercap: a. In menu bar: Sniff -> Unified Sniff. Select ‘rausb0’ & click okay b. Press CTRL + S. You should see "2 hosts added to the hosts list" in the bottom box. It may take a second for Ettercap to find both hosts. You may need to retry the scan until it finds 2. c. In the menu bar: Mitm -> ARP Poisons. Choose Sniff Remote connections. It should display "GROUP 1" & "GROUP 2" in the box on the bottom. d. In the menu bar: Start -> Start Sniffing e. Check Wireshark. You should see a lot of tcp traffic. Select ‘Follow TCP Stream’ to reconstruct what is happening. Question 8.1: What messages do you see being sent? What kind of activity are you sniffing?
