Once upon a time, long distance bills for remote dial-in users were through the roof, modem pools were growing more and more tangled, and Remote Access Servers pretty much translated to "nightmare" in any language. It was the dawning of a new era in secure remote access. The question of how to transmit information via publicly shared network infrastructures was on the minds of every company on a global scale. The answer would change the way we do business today. Virtual Private Networks, or VPNs, were thought to be the answer.

Virtual Private Networks allow organizations to establish secure links with business partners and extend communications to regional and isolated offices. In doing so, they significantly diminish the cost of communications for an increasingly mobile workforce. While VPNs are gaining widespread acceptance as security solutions, they are not a panacea.

Understanding a VPN

So, what is a VPN? A VPN is essentially a combination of tunneling, encryption, authentication, and access control technologies and services used to carry traffic over the Internet, a managed IP network, or a provider's backbone. Basically, what this boils down to is nothing more than a means to extend a Local Area Network (LAN) within a corporation to an outside remote site or traveling employee. The VPN is an encrypted solution to secure remote access. Thus, organizations are able to extend their corporate network to anywhere in the world.

The following is an example of an ideal VPN configuration. Notice the two "secure networks" on opposite sides of the Internet.

There are many types of VPN implementations, each with a specific set of technology requirements. However, VPN deployments can be grouped into three basic categories:

1. Intranet VPNs;
2. Remote Access VPNs; and,
3. Extranet VPNs.

The Intranet VPN is most often used to facilitate communications within a company's information structure, interlinking different offices in different cities or different buildings. The most important of the technological requirements is strong data encryption to protect the information being transferred along the network. Other important factors of the Intranet VPN are to prioritize the crucial applications on the network such as sales and customer database management, and document exchange. Scaleable management of the VPN is also very important to ensure that the number of users applications and offices are easily accommodated.

Remote Access VPNs are usually used to link the remote network to mobile users. The users can connect to the VPN through any ISP if they have the proper access and technology. The most important thing to consider in a remote access VPN is to ensure that strong authentication is applied to verify the identity of remote and mobile users in the most accurate and efficient manner possible. These VPNs can benefit companies with employees that travel on a regular basis.

The Extranet VPN (also known as Internet-based VPN) implements multiple technologies to create a large-scale VPN with more flexibility and options to the users. It uses the Internet as the large backbone. For example, organizations could have an extranet VPN that allows numerous branch offices, suppliers, and customers to have access to the VPN. Internet Security Protocol (IPSec) is the most commonly used and accepted standard to the Internet-based VPN.

IP 101, A Background on IP and IPSec

In August of 1995, RFC 1825 was introduced, thereby making way for a brand new, hybrid version of IPv4. This new protocol would soon become the standard in IP Security as well as the cornerstone for VPN technology to come: the IPSec protocol suite. This would be the technology on which Virtual Private Networks were built.

The IPSec protocol suite provides answers to the inherent security flaws found in the design of the Internet Protocol (IP). The original design of IP raises the concern of three important questions:

1. Is the person we are communicating with really that person?
2. Is someone listening in on our "conversation" or session?
3. Has the data sent between both parties is not altered in any way during transit.

These three concerns are referred to as, respectively, (1) authentication, (2) confidentiality, and (3) integrity. The architecture of the modern Internet Protocol makes all three of these concerns difficult to meet.

In order to understand this, one must understand how the data is constructed and sent across a network. Below is a rudimentary diagram of a TCP/IP packet broken down into chunks. As a packet passes down the OSI model, individual layers append their own header to the packet for delivery. Each packet contains three vital pieces of information: (1) data, (2) the IP address of the source, and (3) the IP address of the destination.

The inherent problems in this packet structure are several. The Source-IP address can be easily changed or crafted to be from a completely different machine than the one sending it. This practice is known as spoofing. Spoofing makes possible another serious type of attack called Session Hijacking, in which an attacker poses as a target system, sending an RST packet to the destination host, thereby ending the communication stream between the original two hosts. This allows the attacker to jump in on the session, masquerading as the destination machine.

Another type of attack that is vulnerable to Ethernet IP-based networks is sniffing. In most Ethernet LANs, packets are scattered across the network to every Ethernet node. Conventionally, each node's network card only listens and responds to packets specifically destined for its IP or MAC address. This is what gives a system the capability of sniffing out packets or communication between systems on a network.

The most obvious and apparent answers to the security flaws found on Ethernet IP networks is encryption technologies able to conceal and authenticate the data passed in IP packets.

IPSec 101

This is where IPSec has created its niche. IPSec employs a powerful suite of encryption technologies that make it possible to combat the numerous threats in traditional IP-based networks. These technologies include:

1. Authentication Header (AH): AH ties data in each packet to a verifiable signature that allows recipients to verify the identity of the sending party as well as the ability to ensure the data has not been altered during transit.
2. Encapsulating Security Payload (ESP): Using powerful encryption, ESP scrambles up the data, more properly referred to as the payload, of the packet into unreadable chicken scratch that only the receiving party has the key to read. The encapsulation also conceals sensitive IP addresses of the sending and receiving party.
3. Internet Key Exchange (IKE): This is the protocol used in the negotiation between the two communicating hosts on what type of encryption algorithms to use, as well as the keys to use, and how long the keys will be valid before changing them. IKE also handles the responsibility required for the exchange of keys used to initiate and maintain the connection between the two hosts.

The Encapsulating Security Payload (ESP)

An IPSec packet is constructed in the following manner. ESP employs several technologies that allow sensitive IP information and the actual payload or data of the packet to be encrypted. Below is a diagram of how this compares to the traditional TCP/IP packet mentioned previously.

With the aforementioned encryption implementations in place, the idea of attacking an encrypted session would be, for lack of a better word, insanity. In reality, the idea of cracking a (3) Triple DES Encryption stream would be a feat that would be far from attainable, at least with current technologies.

Instead of targeting the encryption itself, attackers may prefer to set their sights on the improper implementation of such a technology from vendor to vendor. This should not therefore be construed as a criticism of IPSec itself; rather is is an attack on the way vendors have architected their VPNs. With no standards set in place, each vendor is faced with their own interpretation and ideology of what a VPN appliance should be. In the experience of the author, this has been nothing but a history of failed attempts.

Another difficulty that the VPN industry has faced (and continues to face) is an influx of vendors attempting to develop products with a degree of functionality that does not belong in a security device. This misguided tendency exemplified by vendors who have added such functions as archaic versions of Sendmail to turn a VPN into a combination VPN and Mail Server.

False Hopes

This weakness points out the fact that while the VPN technologies are powerful, they are not foolproof. More to the point, they are not hack-proof. They can be extremely difficult to configure properly, and even a small error can create a serious hole in a firewall. Even when configured properly, many of the protocols used in implementing VPNs have security problems and inherent implementation issues.

Case in point, in August of 2000, Fate Research Labs released its first VPN advisory, which targeted a VPN vendor called RapidStream. The problem outlined in this advisory focused on the company's implementation of SSH access for encrypted remote management. It was discovered that RapidStream had hard-coded the root account into the SSHD binary itself with a null passwd. In all likelihood, developers were unaware of the ability to append command execution to the end of an ssh(exec) string in *nix. A string of ssh -l rsadmin '/bin/sh -i' would coincidentally spawn a root shell on the remote VPN's underlying OS.

For example, a second Fate Labs advisory identified problems that were found in two underlying areas of VPN products, in this case developed by Avaya Corporation. The first problem identified was an unknown flaw relating to the way the VPN device handled packets. Due to a lack of communication with the vendor (threats of lawsuits and being ignored by the company), a definitive cause of the problem was not reached. It was assumed by Fate Labs that it was a problem somewhere in the NAT functions or bridging code of the VSU. This can be easily explained in the following diagram below using our original diagram of an IP packet.

By modifying the source IP address to match the internal network, the VPN passes the packet over, allowing us to initiate sessions with systems on the protected LAN.

The problem here is as one can see, not IPSec or the underlying protocols used by VPN; rather, it's the way in which these technologies have been integrated together into what are commonly (and misleadingly marketing) as "complete" solutions. As budgets for security solutions within companies grow smaller and smaller, and as a false sense of security is created by the purchase of a single firewall or even VPN, the potential loss that could be caused by a single compromise increases.

Many Fortune 500 corporations have been discovered to be deploying VPN solutions without a firewall in order to cut deployment costs or because of a lack of understanding and knowledge. Several of these organizations' networks have been compromised in legitimate penetration tests that used a VPN as a "ride-free" ticket into the local protected LAN. During a recent study, Fate Research Labs conducted a global penetration test on networks containing different VPN vendor appliances. Several Fortune 500 Corporations that have asked to not be identified in this paper used a VPN vendor that stored the password of its Client software configuration in plain readable text.

Final Words From The Author

It should be concluded that I am a very large advocate of the progression of Virtual Private Network technology. VPN Technology is indeed in its early, often untested, stages. This should be taken into consideration in the deployment of any VPN solution. At the same time, system and security administrators can prevent the exploitation of vulnerabilities such as those mentioned in this article by conducting comprehensive and regular assessments of the VPN implementation.

The advisories discussed in this article are not incredibly minute or convoluted discoveries. They are simple and logical issues - things such as source-routed packets, spoofed packets - that should not be allowed to cross a VPN.

Eric Hines has been working in information security for over 9 years. As an active contributor to the open disclosure community, he is widely sought after for recent advisories on circumventuing Virtual Private Network appliances and other security applications through his research team, Fate Labs.