CSG254: Network Security

Practical Systems Security Lab
Lab Assignment 2: Network Attacks
Due: 6:00PM Eastern, February 15, 2006

Your team must complete either lab assignment 2 OR lab assignment 3 by the due date. You may complete both for bonus points, but if you plan on doing both, be sure to complete lab assignment 2 BEFORE lab assignment 3, otherwise it may be difficult to complete lab assignment 2. (All bonus labs are due on March 27, 2006.)

NOTE: Read this entire document before beginning the lab assignment.


Lab Assignment

  1. Port Scanning & Vulnerability Scanning

    A. NMap Basics

    1. First, read the man page on nmap(1) and become familiar with the basic command line arguments and scan types. (See -sS, -sT, -sU and -sP.)

    2. Run a discovery scan using -sP against the IP range: 10.0.0.128/26 . (Record the output of this command.)

    3. You should have identified 2 systems in that IP range. Scan both systems at once with a full TCP connect() scan (-sT scan).

    4. Run the last scan again, except this time use -sS instead. (Record the output of this command.)

    5. Finally, review the -p option in the nmap man page. Use this option to scan every UDP port of the two systems in question. (Record the output of this command.)

    B. Using Nessus

    1. Nessus is a vulnerability scanner designed to remotely detect publicly-known vulnerabilities. Read about it and become familiar with the Nessus architecture.

    2. Next, start up the Nessus service, nessusd on your Fedora system (as root): 

          /etc/init.d/nessusd start
      Create a nessus user with the command nessus-adduser. Configure this user for password authentication, and be sure to remember the password for later.

    3. Log into your Windows server via RDP. Download and install the NessusWX client. (You will likely need to install an unzip program as well. Freezip is one option.) Use the installed client to connect to your Nessus server. You'll need to connect to your router's inside interface, which holds IP 10.0.T.1, where T is your team number.

    4. Configure a session to scan 3 hosts: your Windows server, and the two systems you discovered earlier in section 1.A. Execute the scan, and then export the results to an NBE format file. (You will turn this in later.)

  2. Spoofed Scanning Using Predictable IP ID Numbers

    A sneaky method was developed in 1998 to perform spoofed scans through the information leak of IP ID numbers. IP IDs are a field in the IP header of packets which allows a recipient to piece together packets that get fragmented in transit. In order to function properly, these IDs need to be mostly unique, and many IP implementations simply increment a global counter for each packet sent out.

    However, such an implementation leaks information about how many packets are being sent from a host. Using this leak, one can obtain the results of a spoofed TCP scan. More information on this technique is available here and here. We will first manually try this technique, then learn how to use nmap's automated idle scan feature.

    1. First, make sure your Windows server is not being used. Close any applications, and log out of any RDP clients. This machine will be your idle host, and it is important that it does not interact with the network too much.

    2. Open three seperate ssh sessions to your Linux router. In the first session, start up a continuous ping to your Windows server. Your Windows server will be at the IP 10.0.T.2 where T is your team number.

    3. In the second session window, run tcpdump to watch the echo reply packets coming back from your windows server. A suggested command line for this is:

         tcpdump -v -i eth1 icmp[icmptype] == icmp-echoreply
      This of course, must be run with root privileges. This listens only on eth1 (which is the network interface connected to your Windows server) and prints out only packets that are ICMP of type echo reply. It should print out lines that look something like: 
         11:37:52.054397 IP (tos 0x0, ttl 128, id 6197, offset 0, flags [DF], proto 1, length: 84) 10.0.T.2 > 10.0.T.1: icmp 64: echo reply seq 376
      Notice the id field in the IP headers section. This field is the IP ID.

    4. Now, in the third ssh session window, scan one of the systems you discovered in section 1.A, on a single port, spoofing the source address of the Windows server. You can do this with nmap, using a command line like:

          nmap -P0 -sS -p PORT -e eth0 -S 10.0.T.2 VICTIM
      Where T is of course your team number, and VICTIM is the system you are scanning. You should first select PORT as a port you know is open on the VICTIM. This scan will send a single SYN packet to an open TCP port on the victim system, made to look like it came from your Windows system.

    5. Return to the session window in which tcpdump is running. Play close attention to the IP ID field. Look specifically for any holes in the sequence. You can repeat the nmap scan several times. If you did everything right, you should notice the sequence skips one number for each time you run the scan. This is because the Windows system will respond with a RST packet to the SYN/ACK received from the victim system, which causes the system-wide ID to increment by one. (Record a snippet of the tcpdump output when the scan was run. Annotate the output to point-out holes in the IP ID sequence associated with your spoofed scan.)

      NOTE: nmap will report correct results of the scan, even though you didn't give your system's address as the source. Because of the current network configuration, the reply packets have to pass over your router in order to get back the Windows server. nmap sees these, and can determine what ports are open even though these responses aren't technically destined for your Linux router. If you were using an idle host the same interface as the victim, nmap would likely show all ports as filtered, even though the IP IDs would indicate otherwise.

    6. Run the scan again, this time against a port which you know is closed. Watch the IP ID sequence, and see if there are any holes. Repeat this several times to be sure, but there shouldn't be a hole. This is because the victim will return a RST packet to the idle host, and the idle host will not respond to a RST packet.

    7. Fortunately, this labor-intensive scan technique has been automated in nmap. Read the man page's explanation of the -sI scan type. Next, stop your continuous ping, and run an idle scan against the same victim host, once again using your team's Windows server the idle host. Scan at least 5 TCP ports, some known to be open, and some known to be closed. (Record the output of this scan.)

  3. Fingerprinting & Password Sniffing

    A. Fingerprinting

    1. A common scan technique used by many port scanners is network fingerprinting. Gathering information about the operating system running on a host is very valuable to attackers as this can indicate what other software may be running on a system, and therefore what public vulnerabilities may be open to exploit.

      Network fingerprinting typically involves the analysis of different behaviors of a host to various types of requests. While TCP, UDP, ICMP, and IP are all more-or-less standardized based on IETF RFCs, there are almost always small differences in implementation. For instance default TTLs, TCP options fields, optional features, and even bugs on certain systems can help an attacker identify the implementation of the network protocol stack. Read more about these specific techniques here and here.

    2. NMap utilizes a number of tests to make educated guesses as to the operating system of a scanned host. To enable these tests, use the -O option. Scan both hosts discovered in section 1.A with the -sS and -sU scan types (use the default ports), along with -O. (Record the output of this scan.)

    3. The scan you just ran didn't send any information to these systems in the application layer. It merely probed the lower-layers of the protocol stack. Often it is much easier to use the application layer to determine directly what versions of software are running on a system, because many network daemons like to advertize themselves and even their version numbers in application-layer headers.

      Use telnet to connect to port 80 on both systems you discovered in section 1.A. Once you connect, type in the following line exactly:

      GET / HTTP/1.0
      and at the end of that line, press enter twice. You should be presented with an HTTP response, which consists of HTTP headers, followed by two blank lines, followed by the page content you requested. Look for a header line returned by the webservers which starts with the string "Server:". Obviously, this can be a much simpler way to determine what software is running on a host. However, these headers also much easier for systems administrators to disable. (Record the headers returned by each server for later submission.)

    4. Once again, nmap has a feature which automates this kind of banner-grabbing. Read the man page on the -sV option. Then, run a scan against the two discovered systems using the -sS and -sV options. (Record the results of this scan.) More information about how these service probes works can be found here.

    B. Password Sniffing

    Once an attacker gains privileged access to a host, one of the common things he/she will do is sniff the network for passwords. There are many ways to do this, and many common protocols don't encrypt credentials as they are sent of the network. Since your Linux router already has access to all traffic that your Windows server sends and receives, we'll use it to steal HTTP passwords.

    1. First, log into your Linux router and start up tethereal. We want to have it dump packet contents, and limit it to sniffing port 80, so let's use the following command line:

          tethereal -x -f 'port 80'

    2. Log into your Windows server via RDP and open a browser. Open the URL: 

          http://strawman-fedora.nslab.ccs.neu.edu/secure
      When prompted for a password, type any username and password you like. You won't gain access to this resource, but for our purposes, this doesn't matter.

    3. Go back to tethereal and look for the Authorization: header in one of the browser requests. You'll notice some random-looking string at the end of this header line. This is actually a base 64 encoded string of the username and password. Decode this string using openssl: 

        echo CREDENTIALS | openssl base64 -d
      (When finished, record the full HTTP request which contained the credentials. Also, record the associated username/password that you decoded from it.)

  4. Man in the Middle (MitM) Attacks

    A. ARP Poisoning

    The address resolution protocol (ARP) is a layer 2 protocol whose purpose is to allow network devices to associate layer 3 addresses with layer 2 addresses. This relatively simple protocol consists of requests and replies. Requests are typically ethernet broadcasts which contain the IP address that the sender needs a layer 2 (typically a ethernet MAC) address for. If a participating owner of that IP address sees the request, it will respond with a reply, which contains the requested IP and its associated MAC. When a node receives a reply, it will cache that result for a short period of time, using that information for all layer 3 packets sent. Plenty of information about ARP and ARP poisoning is available on the web.

    There is no built-in form of authentication in ARP, therefore replies can be easily spoofed. By sending false ARP replies, it is easy to redirect just about any traffic to any other node on the same ethernet switch. By redirecting traffic back to your own system, it is trivial to listen in on others' conversations.

    1. WARNING: In this sub-section you will use a low-impact ARP poisoning attack to reroute another team's packets to your router. While many precautions have been taken to limit the impact of this on other teams, it is important you use tools to run ONLY the commands listed here. Otherwise, the other teams may have difficulty completing their lab assignments.

      First, open three ssh terminal windows to your Linux router.

    2. In the first terminal window, start up a tcpdump process to watch for packets on TCP port 27011. (This port isn't being used for anything, but will be sufficient for our purposes.) A sample command line:

          tcpdump -i eth0 port 27011

    3. In the second terminal window, you need to run a spoofed nmap scan against another team. The command line: 

          nmap -P0 -p 27011 -sS 10.0.0.V -S SOURCE -e eth0
      and you should replace V with your team number plus one. In other words, if you are team 6, then V=7. If you are on team 10, then let V=1. You need to set the SOURCE to the IP address of one of the systems you discovered in your ping sweep in section 1.A. Using this command line, nmap will send SYN packets to 10.0.0.V, as if they came from the address SOURCE.

    4. After running this scan once, go back to the tcpdump window and review what packets showed up. You will likely see two almost identical lines. Pay close attention to the TCP flags that show up after the ':' character. These two lines should both be SYN packets. Notice you won't see the response from 10.0.0.V, since it will respond to SOURCE, and those packets won't come back to your system.

    5. In the third terminal window, open up the man page on ettercap and become familiar with the command line options. In particular, review the ARP poisoning options.

    6. Next, in the third terminal window, run ettercap with the following command line:

          ettercap -Tq -M arp:oneway /10.0.0.V/ /SOURCE/
      This will ask ettercap to redirect packets from 10.0.0.V to SOURCE through your router first. It will then replay those packets on to the correct MAC address, so that neither host notices that ettercap is stealing these packets.

    7. Run the spoofed nmap scan again, then return to the tcpdump terminal. This time, you should see the responses from 10.0.0.V. (Record the output of tcpdump where both the SYNs and the associated responses are detected.)

      NOTE: If this step doesn't yield you responses to the SYN packets, you may have something set up wrong OR it may be because the team you are bouncing packets off of has set up a firewall in lab 3, and it is dropping those packets. In that case, try incrementing V and re-run the tcpdump and ettercap commands with the next team's system. Only redirect packets from one team at a time though, and be sure to quit out of ettercap cleanly before trying another system.

    8. When you are finished recording the tcpdump output, be sure to close ettercap by hitting 'q' in that terminal. Also note, that ettercap disables Linux IP forwarding (routing) while it is running. For some reason the version currently installed has problems re-enabling it when it is finished. When you are all done, be sure to re-enable routing manually, or you won't be able to route to your Windows server. This is done by simply running: 

          echo 1 > /proc/sys/net/ipv4/ip_forward

    B. DNS Cache Poisoning

    While ARP poisoning is a very powerful attack, it is generally only effective if the attacking system is on the same ethernet segment as one of the victims. Another MitM attack is possible by subverting the Domain Name System (DNS). Since DNS requests and replies are not generally authenticated, it is possible to trick a resolver into believing a certain domain points to an IP other than the correct one.

    1. The term DNS cache poisoning can refer to many different methods of achieving the same end: tricking a resolver into trusting a false record. Many forms of these attacks are a result of DNS software implementation bugs and a poorly designed protocol. Some of these attacks are described here.

      Some specific examples of DNS software bugs are described here, here, here, and here. Select one of these bugs and study it in depth. More background information on how the DNS works can be found here.

    2. In the absence of any DNS resolver vulnerabilities, cache poisoning is still possible. Obviously, if an attacker compromises a router or network in between a resolver and a DNS server, then it would be trivial to subvert records. However, even if an attacker doesn't have this kind of access, it may be possible to poison DNS caches.

      Suppose an attacker, Mallory, knows that Alice's DNS resolver will be sending a request for the domain example.org to Bob's DNS server (who is authoritative for that domain) at a particular time of day. Mallory knows the IP address of Alice's resolver and Bob's DNS server, but the request itself cannot be seen by Mallory. Suppose Mallory wishes to spoof a DNS response as if it came from Bob's server to trick Alice into believing a false record. Assuming Mallory sends this spoofed record at just the right time (eg. before Bob's reply gets to Alice), calculate the probability that Mallory will successfully poison Alice's resolver. (Record the result of your calculation and your reasoning behind it.)



Questions

  1. What method does nmap use by default to ping a host?

  2. What are the IP addresses of the hosts discovered in the nmap ping sweep?

  3. Which nmap scan typically runs faster, -sS or -sT? Why?

  4. What ports does nmap scan by default if -p is not specified by the user?

  5. In general, if any port scanner sends a datagram to a specific UDP port on system and receives NO response, what can be concluded without any other information? (Hint: see the nmap man page, and consider networks which use firewalls.)

  6. When running an idle scan against a victim, what happens if a specific port's SYN packets are dropped by the victim's firewall? How does this look to the attacker, compared to an open or closed port? If the scan target were running a tar-pit on every un-used TCP port, how effective would an idle scan be? (For more background on this last question, you may want to search for "iptables TARPIT" on the web.)

  7. There are a number of ways that IP stacks can be written to reduce or eliminate the information leak of system-wide incremental IP IDs. How does Linux's IP stack defend against this? (Name two techniques. See the "OS Vendors" section in this previously mentioned reference.) How do these help defend against side-channel attacks?

  8. Your work in section 3.B demonstrated how basic HTTP authentication is not secure against passive sniffing attacks. Name at least one other well-known application-layer protocol that is also vulnerable to such an attack.

  9. Suppose it was your task to design a simple heuristic to detect ARP poisoning attacks. What kinds of abnormalities could a passive sniffer look for that would be strongly indicative of this kind of MitM attack?

  10. In section 4.B.1 you studied a specific flaw in some DNS software which could allow an attacker to easily poison it. State which flaw you studied and describe the specific scenario(s) in which an attacker could exploit it. What would an attacker gain by exploiting it?

Submission Notes