Lab Objective:
Learn how to detect vulnerabilities in the resolution process.
Lab Purpose:
Understand how to properly identify vulnerabilities in TCP/IP communication.
Lab Tool:
Wireshark is installed on a PC, Ethernet switch, or router (cable/Wi-Fi).
Lab Topology:
Use the topology shown in the figure below to complete this lab exercise. A PC (equipped with Wireshark) is connected via a wireless or wired connection to a network router that has Internet access.
Lab Walkthrough:
Task 1:
Suspect traffic is traffic that does not match network baselines. It is either out of place because the protocol type is not right, the used port is incorrect, the packet frequency is strange, etc. Sometimes, normal network communications we are not familiar with, or traffic with unusual patterns, can be considered suspect.
Suspect traffic may simply be caused by poorly behaving applications, misconfigurations, innocent mistakes, or faulty devices. To rule out the causes of suspect traffic, you must first understand what is normal. This is where the baselines become a precious resource.
Understanding normal TCP/IP communications is important for identifying abnormal communications. The standard flow for TCP/IP communications is based on the following steps:
Port Resolution ➔ Name Resolution ➔ Mac Address Resolution (or, if the target is remote, ➔ Route Resolution ➔ Mac Address Resolution)
For each step, at least one security issue must be considered.
If you consider the Port Resolution vulnerabilities, you must know that port resolution relies on the integrity of the services file and the application requesting to use a particular port number. If a malicious user or program has altered the content of the services file, the port resolution process may be affected. Applications can also define the ports they use. A malicious FTP program might use port 80, knowing that many companies do not block outbound traffic to this port.
Bot-infected hosts could use non-standard ports to communicate through standard protocols. For example, it can use Internet Relay Chat (IRC) to communicate with Command-and-Control (C&C) servers. In this case, the bot-infected host connects to the IRC server on a non-standard port, and Wireshark defines the IRC communications as simply “Data”.
To handle such issues in Wireshark, in the Packet List pane, select a packet, right-click it, and then select ‘Decode As’. This forces Wireshark to temporarily dissect traffic to and from a non-standard port as different protocol traffic, as shown in the figure below.
From the list of provided protocols, select the protocol that you are interested in.
When you restart Wireshark or change to another profile, the dissector will not be in place.
You can also save the ‘Decode As’ settings in a profile. After you have applied a temporary decode, select Analyze > Decode as on the main menu. Click ‘Save’. Wireshark retains your new decode setting in a decode_as_entries file in your profile directory.
You can also define preferences for certain applications, such as HTTP, and configure Wireshark to recognize additional or alternative port numbers for those applications. On the main menu, click Edit > Preferences. In the Preferences dialog box, select a protocol in the left tree view (for example, HTTP) and then, in the port settings, set TCP ports to be decoded as HTTP traffic. Also, set the port that will be dissected as SSL/TLS traffic.
Task 2:
Another possibility is a vulnerability in the Name Resolution process. If a malicious application has altered the client’s hosts file, the client’s system will use the information in that file before generating a DNS query. Unless a secure form of DNS is used to validate responses and the responding DNS server, clients accept any DNS responses as long as the transaction ID number and the restated query match the original request.
If the DNS information supplied is not correct or leads to an alternate host, the client continues the resolution processes to connect to the incorrect host. If this information is kept in the DNS cache, the client uses it again (until the information has expired). In fact, unless you know the IP address that corresponds to a hostname, it is difficult to spot traffic with malicious intent.
In the case of bot-infected hosts, however, it is not uncommon to see DNS queries that return canonical name records with multiple IP addresses. To spot this situation, you can create a coloring rule to identify DNS responses that contain more than 5 IP addresses. Create a coloring rule with the syntax (dns.flags.response==1) && (dns.count.answers > 5), as shown in the figure below.
Another vulnerability concerns the MAC Address Resolution process. When resolving the hardware address of a local target or router, the client relies on the validity of ARP responses or entries in the local ARP cache to use the correct MAC address in subsequent packets.
MAC address redirection can be used by some attackers to perpetrate a man-in-the-middle attack. ARP poisoning is an example of unusual ARP traffic.
The last example of vulnerability concerns Route Resolution. When a client needs to send data to a target on a remote network, it checks its routing tables to identify the best gateway or, if present, the default gateway. If the local route table has been poisoned, the client sends packets in the wrong direction, and they can’t reach the intended target. This route redirection can be used for the man-in-the-middle attacks.
Task 3:
Wireshark usually can reveal unusual patterns of network scans, attempted logins, insecure communications, strange protocols, or unusual application behavior. You can make unusual traffic easier to identify by colorizing the traffic that is of concern. The syntax used by display filters and coloring rules should be chosen appropriately to make this traffic more visible in Wireshark.
Scanning traffic is typically considered unacceptable on the network, but in some cases, scans may be generated by network monitoring devices that build and maintain a database of network devices.
Some examples of unacceptable traffic on the network are:
- Maliciously malformed packets—intentionally malicious packets
- Traffic to invalid or ‘dark’ addresses—packets addressed to unassigned IP or MAC addresses
- Flooding or denial-of-service traffic—traffic sent at a high packet per second rate to a single, group, or all hosts
- Clear text passwords—passwords that are visible and therefore, insecure
- Clear text data—data that is visible or able to be reconstructed
- Phone home traffic—traffic patterns indicating an application is checking in periodically with a remote host
- Unusual protocols and applications—protocols and applications that are not commonly seen or allowed on the network
- Route redirections—ICMP-based route redirections in preparation for man-in-the-middle attacks
- ARP poisoning—altering target ARP tables for redirection of local traffic through another host—used for man-in-the-middle attacks
- IP fragmentation and overwriting—using the IP fragment offset field setting to overwrite previous data sent to a target
- TCP splicing—obscuring the actual TCP data to be processed at the peer
- Password cracking attempts—repeated attempts to guess an account password over a single connection or multiple connections
Task 4:
Given the numerous resolution processes for host and hardware addresses, it is unusual to see traffic destined for unassigned addresses. For example, consider your network configured as 192.168.1.0/16, and you have assigned the addresses 192.168.1.1 through 192.168.1.20. You would not expect to see traffic destined for 192.168.1.99.
Unassigned MAC addresses are also called “dark MAC addresses and unassigned IP addresses are also called “dark IP addresses.” Traffic sent to or referencing unassigned addresses may indicate blind discovery processes, i.e., someone is trying to find hosts on the network by scanning those addresses and listening for responses.
To try to reproduce this issue, in Wireshark, capture traffic for a few minutes on an active network interface. Open a terminal window, and run the command nmap –PR 192.168.1.14/24 –sn, as shown in the figure below.
Stop the capture and save the file.
In the figure below, numerous subsequent ARP requests in the Packet List pane indicate an issue that must be investigated.
Traffic sent to unusual target addresses is also an indication of a possible configuration or application problem. For example, traffic sent to 127.0.0.1 (the loopback address) would be considered quite unusual. You can locate traffic to or from addresses that are not in use, but the display filter may be quite long if you use non-contiguous addressing.
The following can be an example of a non-contiguous address if your network is configured to use these IP address ranges:
192.168.1.1–4 is assigned to routers
192.168.1.100–112 is assigned to servers
192.168.1.140–211 is assigned to clients
To display the packets of your interest in an efficient way, create a display filter like the following one:
ip.dst > 192.168.0.4 && ip.dst < 192.168.0.100) ||
(ip.dst > 192.168.0.112 && ip.dst < 192.168.0.140) ||
(ip.dst > 192.168.0.211 && ip.dst <= 192.168.0.255)
The parentheses group together the addresses that you want to display.
Notes:
To gain confidence in discovering vulnerabilities and malformed packets, repeat the previous steps, capturing on your local network and simulating some attacks with the Nmap tool. Scan the network for dark addresses. Get the necessary confidence in using the display filters and coloring rules to make the packets you are interested in more visible.
