VPNs were developed initially to deal with security issues of transmitting clear text data across a network. Clear text data is information that can examined and understood by any person, including the source, destination, and anyone in between. Examples of applications that send traffic in a clear text format are Telnet, file transfers via FTP or TFTP, e-mail using the Post Office Protocol (POP) or Simple Mail Transfer Protocol (SMTP), and many others. Unethical individuals, such as hackers, can take advantage of applications that send clear text data to execute the following types of attacks:
Each type of attack exposes your data and company assets to various risks. The following three sections discuss these attacks in more depth.
The most common type of attack with clear text data is eavesdropping. In an eavesdropping attack, a person examines the contents of packets as they are transmitted between two devices. Some types of applications and protocols are susceptible to eavesdropping attacks, including Telnet, POP, HTTP, TFTP, FTP, Simple Management Network Protocol (SNMP), and others.
With all of these applications and protocols, authentication information, like usernames and passwords, is passed, in clear text, between two devices. A hacker can use this information to execute access and other types of attacks.
Even though some protocols might send information in clear text, they, in many cases, have a minimal authentication method to verify an individual's identity before allowing that person access to a resource. For example, applications such as Telnet, POP, and SMTP allow for authentication, even though the authentication information is sent in clear text. Actually, these protocols initially were not designed for security, but to solve specific connectivity problems. However, things have changed since these applications were developed in the 1970s, 1980s, and early 1990s, especially with the explosion of Internet usage.
Typically, a protocol analyzer is used to examine (sniff) packets. The analyzer can be a hardware-based solution or a PC with a promiscuous network interface card (NIC) and appropriate software. For this kind of attack to work, the attacker must have access to a connection between the actual source and destination devices.
There are two main categories of protocol analyzers: general and attack. A general protocol analyzer captures all packets it sees and typically is used as a diagnostic tool to troubleshoot problems. There are many freeware, software-based protocol analyzers available that perform this function.
An attack protocol analyzer, on the other hand, is an enhanced form of a general protocol analyzer. Attack protocol analyzers look at certain types of applications and protocols for authentication, financial, and security information. An attacker will use this specific information to execute other types of attacks.
Sensitive information includes credit card information, personal information, Social Security numbers, telephone numbers and addresses, usernames and passwords, and proprietary information. Because many protocols and applications are insecure when transmitting sensitive information (they send their information in clear text), protection becomes necessary. One solution is to use one-time passwords (OTP) with token cards. This prevents someone from executing an access attack when using a protocol analyzer to capture password information. However, this solution only protects against password attacks; other types of information transmitted across the clear text connection are not protected.
One of the most common solutions for companies to protect credit card information in an e-commerce environment is to use HTTP with SSL (HTTPS) to encrypt user-sensitive information. Another common solution for corporate and partner access is to implement a VPN with encryption. Encryption scrambles the clear text information into what appears as a random string of characters; only the destination will be able to decipher the information. Encryption can be implemented with one of the two following methods:
Encryption is commonly used for external connections that traverse public networks; however, for certain types of sensitive data, you might want to encrypt it as it traverses your intranet. Of the two solutions, packet payload encryption is the most common one you'll see used in a VPN solution. The reason packet payload encryption is most common is that in many situations, the data must transfer multiple hops, and thus packet payload encryption is the most scalable: only two devices need to handle the encryption/decryption process and the intermediate devices just route the encrypted packets.
A masquerading attack is where an individual hides their identity, possibly even assuming someone else's identity. In a networking environment, this is accomplished by changing the source addressing information in packets. In the TCP/IP world, this is commonly referred to as spoofing. An attacker using spoofing typically combines this with either a denial of service (DoS) or unauthorized access attack.
Unlike eavesdropping attacks, many types of tools can be used in a masquerading attack. To change the source IP address in a packet, a specialized packet-generating program is needed. This allows the hacker to specify the source address to be used, instead of using the IP address associated with the hacker's PC NIC.
An attacker will typically try to use an authorized external source IP address to bypass any packet filters. Of course, any returning traffic would return to the actual authorized external address instead of to the attacker. To see the returning traffic, the attacker would have to combine this attack with a routing attack, allowing the returning traffic to be redirected to the attacker. To implement a simple DoS attack, the attacker will attempt to use an internal source address that a packet filter might allow through a firewall system.
In a Layer-2 network, a hacker could use ARP spoofing to redirect traffic between two devices to the hacker's device.
Of course, using a robust firewall system to restrict the kinds of packets into your network is a necessity. However, a firewall system will allow traffic from authorized external systems, even if it happens to be VPN traffic. Therefore, some type of packet authentication check is required. For example, you need to determine if packets are coming from a valid source, rather than from an attacker executing a masquerading attack.
The most common solution is to use a packet integrity check system, which is implemented with a hashing function. Hashing functions allow you to verify the source of transmitted packets. Because hashing functions use a one-way hash with a shared key, only the devices that have the key will be able to create and verify the hash values. With VPNs, the most common hashing functions used are MD5 and SHA.
Packet authentication is discussed in the "Packet Integrity" section later in this chapter and hashing functions are discussed in Chapter 2, "VPN Technologies."
A man-in-the-middle attack can take on many forms, including the two most common:
With a session replay attack, the attacker, sitting between two devices, captures the packets from the session. The attacker will then try to use the captured packets at a later time by replaying (resending) them. The attacker's goal is to gain access to the remote system with the same packets. In some instances, the attacker will change the contents of the packets to assist in this process.
The diagram in Figure 1-1 illustrates an example. In Step 1, the user sends traffic to the real server. In Step 2, the attacker intercepts traffic from the user to the real server (assume that it's a web session). Typically, an attacker would do this either by spoofing DNS replies with the attacker's source address instead of the real destination's address, which is a form of a masquerading attack, or by spoofing packets, combined with a rerouting attack. Of course, if the attacker has access to a link between the source and destination, the attacker can easily use a protocol analyzer to examine the packets. In this example, assume that the attacker is using a redirection attack and that all traffic is being sent to the attacker. The attacker pretends to be the real server and sends responses back to the user PC, possibly even malicious Java or ActiveX scripts, to capture any user-specific credentials. In this instance, the attacker would redirect the user's original traffic and responses to the real destination, as seen in Step 3.
Figure 1-1. Session Replay Attack
In a session hijacking attack, the attacker will attempt to insert himself into an existing connection and then take over the connection between two devices. Figure 1-2 illustrates a session hijacking attack.
Figure 1-2. Session Hijacking Attack
To execute this attack, the attacker will have to perform masquerading, where the attacker is pretending to be the source and destination devices. Plus, the attacker must have access to the packets flowing between the source and destination devices. Physically, this looks like the top part of Figure 1-2.
On the other hand, the diagram in the bottom part of Figure 1-2 is more representative of how a session hijacking attack occurs. In this example, when DeviceA sends traffic to DeviceB, the attacker intercepts the traffic and pretends to be DeviceB. He responds back to DeviceA with information similar to what DeviceB would send. From DeviceA's perspective, the device assumes it is really interacting with DeviceB. The attacker uses the same process when interacting with DeviceB. With data flowing back and forth between DeviceA and DeviceB, the attacker will typically perform a data manipulation attackmodifying data between the two devices to pull off the actual session hijacking. The attacker uses this process to learn more information about the two devices, including their security weaknesses.
With protocols such as UDP and ICMP, implementing a session hijacking attack is a simple process for the hacker because there are no real mechanics that define how a connection is maintained. With TCP, this becomes more difficult, especially with TCP's sequencing process. Sequence numbers should be random, making it very difficult for a hacker to guess what a sequence number might be for the next segment. Therefore, hijacking a TCP session can be difficult. However, not all TCP applications use random sequence numbers. In many instances, it is very easy to guess what the sequence number is, based on past numbers seen for an existing connection. A skilled attacker can then insert himself into the existing TCP connection. Of course, this is not a simple process. The hacker will need to perform quite a few steps and use some sophisticated tools to pull off this attack.
Attackers will typically use an attack protocol analyzer to capture packets with the two types of attacks described. With a session replay attack, the hacker might even use Java or ActiveX scripts to capture packets from a web server session. With TCP session hijacking attacks, the attacker will need some type of specialized TCP sequence-number-guessing program to successfully intercept and take over an existing TCP connection.
There are several solutions for man-in-the-middle attacks. For instance, to prevent the hijacking of TCP sessions, you could have a firewall system randomize TCP sequence numbers, ensuring that it becomes almost impossible for the attacker to predict future sequence numbers for the session. The Cisco PIX security appliance and other available devices can perform this function. However, an attacker can use other methods, as discussed in the last section, to take over a session.
TCP sequence numbers are 32 bits in length, providing over 2 billion possible combinations; randomizing sequence numbers makes it practically impossible to guess the next sequence number in a transmission.
The best solution to this kind of problem is to use a VPN. VPNs provide three tools to combat man-in-the-middle attacks:
With device authentication, you can be assured that the device that is sending traffic to you is an authorized device instead of a masquerading device. With packet integrity checking, you can be assured that the packets coming to you are from an authorized source, and haven't been tampered with or are spoofed. And with encryption, you can be assured that a man-in-the-middle device cannot eavesdrop on the actual data your two devices are trying to share with each other. These topics will be discussed more in the "VPN Components" section of this chapter.
Part I: VPNs
Overview of VPNs
PPTP and L2TP
Part II: Concentrators
Concentrator Product Information
Concentrator Remote Access Connections with IPsec
Concentrator Remote Access Connections with PPTP, L2TP, and WebVPN
Concentrator Site-to-Site Connections
Verifying and Troubleshooting Concentrator Connections
Part III: Clients
Cisco VPN Software Client
Windows Software Client
3002 Hardware Client
Part IV: IOS Routers
Router Product Information
Router ISAKMP/IKE Phase 1 Connectivity
Router Site-to-Site Connections
Router Remote Access Connections
Troubleshooting Router Connections
Part V: PIX Firewalls
PIX and ASA Product Information
PIX and ASA Site-to-Site Connections
PIX and ASA Remote Access Connections
Troubleshooting PIX and ASA Connections
Part VI: Case Study