From Granizada

Abstract

Virtual Private Networks (VPNs) are a networking tool widely used to increase the security of IT systems. A VPN is a powerful tool, but is often inappropriate for the role it is given, or it is inadequately implemented. Some of the most common ways of implementing a VPN have the effect of increasing risk overall rather than reducing it. This risk is particularly acute since VPNs, intended to protect against external threat, increase exposure to internal threat - yet internal threat is usually the greatest risk to an organisation. VPNs are all-too-frequently considered in the context solely of the tunnel itself and the area the tunnel passes through, and not what goes on at either end, or what is allowed through that tunnel. This paper examines when and how a VPN should be used, and the risks many VPN users are running with their well-intentioned but dangerous VPN implementations.

Definition of a VPN

There are many types of VPN. The term VPN, much like the term Voice over IP (VoIP) is a blanket term referring not to a specific piece of technology, but a category of pieces of technology, all designed to work in similar ways and solve similar problems.

Very broadly, VPNs are designed to solve one problem effectively: seamlessly linking physically separate hosts and networks. Everything else VPNs do is related to this goal, or a special case of it.

The 5-minute Overview of Security

Security is often viewed as having three axes: confidentiality, integrity and availability. The common idea of security problems being mainly caused by evil-intentioned network crackers is a very poor stereotype, very often mistakes, inattention and internal minor malfeasance can cause serious problems.

Confidentiality; ensuring our data remains private

Integrity; ensuring that are data isn't subverted and changed

Availability; ensuring that our access to our data remains reliable

Why invest effort in defending against being attacked?

• Threat from accidental breaches to confidentiality, integrity, availability is clearly real.
• Threat from internal misapproriation is real
• Threat from Organised Crime is real

Cost in lost business, fines and reputation

See this survey for indicative effects, and then reflect that the majority of security breaches are reckoned to be unreported.

All business that handle any private information need to consider the Data Protection Act and its provisions. If you are in telecommunications, aerospace or transport there are very specific requirements. For financial services, the FSA takes breaches very seriously and can impose sanctions.

There can be serious reprecussions in terms of reputation.

The Problem VPNs Solve

People frequently want to link networks and clients when they all belong in some sense to a single organisation, or access common data or resources.

A business with several networks in different locations with their own sets of addresses uses a VPN to aggregate these into one big (inter)network where every computer can talk to every other computer -- potentially without massive infrastructural changes to those networks. The networks are seamlessly connected - computers can talk to each other without needing any knowledge of their data's transmission via a VPN, potentially, over thousands of miles and across the internet.

Elsewhere, a business with a corporate network at their head office may have employees with broadband connections each with their own, smaller, home networks. With a VPN linking them to an office, their home PC appears to exist within the internal network - or potentially, their entire home network appears as a branch of the internal network.

It makes sense for there to be links between these networks because of the common interest in the corporate network.

In every scenario, all clients on the network, whether physically connected to the same fabric as the VPN server or thousands of miles away in another site, appear to be part of the same group. It's like magic. ^[1]

What makes the instant VPN solution even more attractive is that not all physically separate networks are fixed physical locations such as the employees’ home networks. Travelling staff who need access to the company network while on the road can use a roadwarrior VPN to connect into the corporate LAN from anywhere in the world.

The problem then no longer consists of getting access to the network, it consists of managing that access in a safe manner – providing only the required level of access for staff, and not providing any degree of access to anyone else.

The Problems VPNs Introduce

Open networks up to insider risks

False sense of security

Very hard to lock down

Even harder to lock down after people get to like them

Extends the border of the network enormously, increasing risk

Implicit trust of unknowable networks... the CFO's mother-in-law, his neighbour's plumber...

How VPNs are Used Today

The two basic types of VPN

Remote Access (host-to-network)

Dialup access and VPNs have been used as a solution to this problem for some time. Rather than exposing business applications, fileservers, etc to the internet, a business in effect, creates a virtual tunnel into their network over the internet - sort of like a virtual network cable stretching from a sales laptop in a hotel in London, over the internet and into a trusted network in Glasgow.

Most importantly, in this scenario, a client participating in a VPN itself will have a second (virtual) network card that the system can send data to, which is connected to the network on the other side of the VPN tunnel. This virtual NIC uses an IP address within the range of the remote network – so to all intents and purposes, this host is a participant in the network itself.

Site to Site (network-to-network)

Potentially, rather than one salesperson in London, we have a small office. In this instance, we might use a site-to-site VPN. In this instance, rather than having software configured on a laptop which allows just it to talk to the trusted network in Glasgow as if it were there, we have the software configured on the gateway in the London network. Access to the Glasgow office is transparent for all clients in London - they talk to the Glasgow 'trusted' network and the router intelligently takes their traffic and sends it across the VPN (or passes it to clients in the opposite direction).

In this scenario, both networks cannot use the same address range – this would create problems for the devices linking the two networks together (as well as clients themselves), as they would have no understanding as to which traffic was supposed to go where. In order to make the routing process function, the two networks need unique, non-overlapping sets of IP addresses.

Access to portions of an intranet - secure DMZs etc.

Large organisations frequently have networks of similar complexity to small segments of the internet - with many routers, different network subnets, and firewalls. Often these subnets are used for different forms of data, or different types of machine, or even wholly different business divisions. Organisations which are very large, such as big corporations and banks, often use IPsec and VPN technology to allow staff access to 'restricted' sections of the network, such as areas in which financial or HR data are stored.

Extra layer of security for wireless LAN

Wireless network security is a topic that's had a lot of coverage in the last few years, and before the advent of 802.11i and WPA(2) technology, VPNs were touted by analysts and networking professionals as /the/ way to secure a wireless network. Sit a VPN endpoint in between the untrusted wireless network and the trusted wired infrastructure, and force clients to setup an encrypted tunnel over the top of the existing wireless LAN.

Problems with Typical VPN Implementations

VPNs surely offer a large amount of flexibility. Unfortunately, as a result of this they've become somewhat overused. They're thrown at many problems, such as security on wireless networks, which there are simply better solutions for.

For the purposes of this discussion, the most critical aspect of VPN Security is how a VPN is implemented and what it's used for. Even VPN packages based on well-proven, trusted software such as OpenSSL frequently leave large security holes in networks that probably weren't intended by the people who designed them. In part, this is a question of looking at what you get with a VPN without asking for it. In IT, solving 100% of requirements is good but solving 3000% of the requirements, or over-engineering your solution, is asking for trouble. In many instances, an overly complex solution which is not used by users, and bypassed (or, worse, which causes users to lose faith in, and not use, a portion of an infrastructure like a wireless LAN) can be damaging to security and productivity.

In a business environment, VPNs are frequently used for:

• email
• LAN file access
• web provision
• access to critical information systems
• VOIP services

Consider one example; the Microsoft Exchange groupware server, used by a large number of businesses for accessing e-mail, calenders, and other business data. MAPI exchange clients (eg. the MS Outlook and Entourage clients) require a large number of ports in order to be able to authenticate to an Exchange environment and access the user's mailbox. The documentation for Exchange 2000 lists almost 30 distinct ports and services that might be used by a fully loaded Exchange 2000 server^[2]

For a VPN client to access a single exchange server, firewall holes are needed not only to Exchange servers, but for Active Directory authentication also, to Domain Controllers which form a core part of a Microsoft-based infrastructure, and which are top of the list of any malicious attacker in an AD environment. This is very difficult to secure using a packet filtering firewall, so rather than trying - or using an alternative mechanism to access this data - IT personnel don't bother. They implement a VPN and just throw the difficult to deal with traffic down it.

General problems

The problems associated with VPNs aren't confined to security issues. Performance is also a concern. Tunnelling network traffic inherently requires more bandwidth than not tunnelling it, and due to the technicalities of the Transmission Control Protocol(TCP), which is used for a majority of services used by business in a networked environment, a slow or unreliable internet connection can render services delivered by VPN practically unusable.

Certain types of traffic inherently react very badly with VPNs. The added delay caused by the additional bandwidth and processing requirements of a VPN, for instance, wreak havoc on VoIP. For businesses which have migrated their telephony infrastructure to a VoIP system in which their computer network and telephony are integrated, this breaks one critical feature VoIP has which analog telephony does not - the ability to use a VoIP softphone or hardphone anywhere where there's access to the company network.

With a properly implemented converged VoIP and networking infrastructure, the saleswoman in London can use the VoIP softphone on her laptop via the hotel internet connection as if she were in the office, but with a bad VPN this becomes practically impossible.

Use in wireless LANs

Many analysts and networking professionals initially recommended VPNs as a solution for wireless networks. Although prior to the inception of the 802.11i and WPA technologies this was not an unreasonable solution, WPA (a subset of 802.11i) and WPA2 (essentially the marketing name for the mandatory aspects of the 802.11i specification) provide similar levels of security, and are far more usable.

In conjunction with a RADIUS Server, 802.1x may be used to authenticate clients using credentials or certificates centrally, as they connect to the wireless network. Once authenticated, clients may have an individually-encrypted wireless connection (unlike WEP and WPA with pre-shared keys), and can even be separated into different network segments based on network policy.

This protection, then, is performed at a lower level than with IPSec or a VPN. With clients maintaining their own VPNs over the top of a semi-secure wireless network, malicious clients on the semi-secure wlan can attack other clients, even if those clients are authenticated to the VPN (similarly to when VPNs are used on a public wifi network to connect over the internet).

This mechanism is also non-transparent for users – a user must start his or her VPN connection when (s)he connects to the wireless access point, and if (s)he moves to a different site or area onsite and ‘roams’ to a different wireless access point, the VPN connection must be re-established. Unattended machines on a wireless LAN using VPNs for security will not be manageable in the same way as attended ones – since the VPN itself is setup (and initiated) by a user.

There are ways to automate some of these problems with a VPN – but they still do not eliminate the holes that this approach has, or make it less complex and difficult to manage. WPA2-Enterprise offers AES encryption, granular control over authentication, integration with a business’s authentication framework (Active Directory, eDirectory, samba, or simply authentication based on static usernames and passwords or PKI/Certificates), and is highly scalable.

There are products on the market, ranging from open source replacement firmware for low-end networking devices up to enterprise network equipment such as the HP Procurve AP530, which have built in Radius servers – an access point like this, inexpensive when compared to the cost of an access point and server for a branch office, allow the high level of security WPA2 provides to be provisioned even in a small office, and potentially with a far reduced level of maintenance and increased degree of efficiency.

Architectural Security problems

Aside the difficulty of firewalling applications such as Exchange, there are other reasons people deploy VPNs in a remote access scenario too. Businesses frequently use applications such as ACT!, Sage, or homespun database-driven applications which they aren't comfortable delivering over the internet (or can't, because they rely on hard-to-firewall protocols we've mentioned already like SMB).

Rather than mitigate the risks involved with these applications by redesigning them more securely or fixing flaws in code, the VPN approach allows this risk to be eliminated through the assumption that only authorised users will have access to the applications, and that these authorised users would never try to break into the application, so the risk of not fixing them is justified.

Unfortunately, many businesses will not carry out the work required to refactor applications to fix problems such as these which have become ingrained as part of their infrastructure. In many instances, the most acceptable approach is simply to migrate (or upgrade) these applications to better, less troublesome alternatives as part of the normal IT lifecycle.

Account Lockout / Username Enumeration

As a VPN by its very nature allows external users to attempt to authenticate using local or network/domain credentials, a VPN provides an attacker with a way to enumerate usernames and to attempt to bruteforce passwords. In many instances, the lack of a mechanism for forcing a delay in between authentication attempts, or to lockout accounts after a predetermined number of failed logins makes brute forcing of passwords a reality.

In instances in which such policies are implemented, a VPN can provide a very effective way to lockout a large number of users remotely! Imagine the chaos that could be caused by an organisation which indefinitely locked out accounts after a given number of failed logins. For an attacker with a pregenerated list of account names (possibly acquired via username enumeration), this could provide quite an effective mechanism through which to cost a company many mandays of lost productivity whilst unlocking the accounts locked out over a weekend by a malicious attacker.

Lack of effective firewalling

In environments in which VPNs are deployed in order to avoid the complexities of implementing a proper firewall policy or internet-publishable applications, identifying which staff are using what application is even rarer. In this scenario, any firewalling of traffic entering an organisation via VPN is rare. At best, the majority of the (small number of) businesses which do filter this traffic provide only /one/ firewall policy, common to all staff. Since IT staff frequently use VPN technology for remote support and troubleshooting, this tendancy not to firewall VPN traffic is compounded.

One analogy that is useful to demonstrate this problem is that of a bank. In order to enter a bank, one must generally walk through doors designed to lock in the event of a burglary, sometimes flanked by security guards and generally with CCTV. In some instances, one must swipe a valid bank card in order to enter. Once into the bank, however, one does not have an all access pass to visit every area of the bank, solely in order to use the bureau de change; the bank vault, staff areas, and other sensitive parts are protected by separate access controls. A bad VPN does not provide this fine-grained control - once past the front door, a VPN client may use the bureau de change, peek at the bankvault, and use the staff canteen.

It is very difficult in this environment to control what your users gain access too, and this is the least of your concerns. Staff are able to configure many types of VPN on Windows, Linux, and OSX Clients, and work from third party computers in internet cafes, at home, or at partners sites. The VPN connectoids that they configure may, or may not, be removed from those computers. Their usernames and passwords may or may not be logged by nasty software installed on those PCs. Without even having a computer used as a VPN client compromised, a user's password may simply be weak - as well as allowing users to connect via VPN, a publically exposed VPN server allows anyone, anywhere in the world to attempt to guess your users' usernames and passwords if you use password-based authentication.

Some forms of remote access technology which can use usernames and passwords, such as SSH, are already subject to attacks like this - anyone who runs an SSH server on the default port (tcp:22) and who reads their logfiles will bear witness to the large number of (badly written) automated scripts which attempt to propagate using a dictionary list of weak passwords to move from SSH server to SSH server.

Split Tunneling

Remote Access clients such as our fictional salesperson frequently connect to untrusted networks, and use these to piggyback a VPN connection. These networks, which may be in a coffeeshop, airport lounge, or just an unsecured accesspoint in a residential district, provide no guarantee that any clients associated with them and using them for connectivity will not be attacked by other clients on the network. Firewalling wireless clients from each other is a fairly complex task, and one only supported by higher end accesspoints such as those manufactured by HP and Cisco.

VPN Clients, whether they are configured to use the VPN as the 'default route' (the default configuration in most instances) or simply to access the address space at the other end of the tunnel (referred to as 'split tunneling'), may be attacked by other network users on the same network segment. Once a sales laptop has been compromised due to a disabled firewall or software vulnerability, an attacker with access to the laptop can make full use of the VPN, using a remote machine as a conduit through which to gain complete access to any and all resources the user of the laptop has access to.

http://www.isaserver.org/tutorials/2004fixipsectunnel.html

The Difficulty of auditing VPN traffic

Without monitoring VPN traffic in a manner beyond most VPN solutions, too, it's very hard to detect unauthorised access, when you consider what types of activity unauthorised access constitutes and how hard it would even be to trap certain types of activity with an IDS and correlate the activity against which user account originated the VPN tunnel the activity came from. VPNs are just very hard to lock down effectively.

Obviously there are always going to be stupid IT people in companies, whether they have VPNs or not - but if they hadn't given him VPN access for mail and to access some project files, if they'd stuck the data on a publically accessible intranet site, wiki, etc, and given him webmail access, outlook anywhere/rpc-over-http access, imaps, etc, he wouldn't ever have been in a position to make this happen.

Protocol-Specific Risks

So far, we've focused largely upon risks associated with VPNs which do not involve a direct compromise of the VPN package or protocol itself. These, it should go without saying, are not, however, invulnerable to security risks through software flaws themselves.

One of the best-known technologies used for securing remote access, IPSec, uses a technology called IKE, Internet Key Exchange, to enable clients on the internet to exchange encryption keys and avoid the need for having to manually manage keys. IKE software from a number of sources such as Cisco, OpenBSD, Nortel, Sun Microsystems and Openswan have all been vulnerable to bugs in their IKE software, ranging from Denial of Service attacks that prevent services from operating as expected to attacks which allow users to gain unauthorised access to systems and gain a foothold in breaking into an organisation's IT Infrastructure via the VPN Server.

There are a variety of other problems, too, which are commonly associated with VPN packages and implementations.

Client Weaknesses

Client VPN Software necessarily either prompts users for credentials or other data used to authenticate (such as a certificate), or stores these itself. Due to the inconvenience of being prompted every time one connects, the latter is generally the more common configuration option, and therefore how client data is stored on a VPN endpoint becomes of critical importance. Having corporate assets hidden behind an impregnable VPN which is kept up to date is great, but if a corporate laptop is lost and the username and password used not only to authenticate via the VPN but also to connect to resources is stored in plain text on the machine's hard disk, the VPN counts for very little.

VPNs, then, are not a substitute for other safeguards, such as the use of two-factor authentication where possible (eg. using certificates or smartcards and passwords), and proper security policies and safeguards for mobile clients, the use of hard drive encryption, and locked down laptop builds which resist (or at least make tremendously inconvenient) attempts to do evil things with laptops lost on trains or left in taxis.

Many VPN protocols do not verify the identity of the server to which a client is connecting. When this is the case, the server may be impersonated by an attacker, and the user's traffic intercepted - or worse, their credentials stolen. Given that a roadwarrior VPN client is almost always connecting through a network which is to a certain extent untrusted by definition, using a VPN solution which does not allow the client to verify that they are connecting to a legitimate VPN Server is a bizarre oversight.

IKE

An unfortunate common configuration with IKE is for "Pre-Shared Keys" to be used in place of certificates. These substantially weaken the security afforded by an IPSec VPN, and should be avoided where possible. In IKE Aggressive Mode, the use of PSK can even result in the PSK itself being transmitted over the wire in a hashed, and crackable format.^[3]

There are other, less well known techniques for attack and reconnaissance which are possible with VPN Servers too. Thanks to the IKE protocol (used alongside IPSec) and the use of keys with VPN systems, an attacker is able to gather information about an organisation without doing anything other than connecting, unauthenticated, to the VPN server. Tools such as ike-scan allow an attacker to complete the handshake process involved in connecting to a system using IPSec, and find out what types of encryption and authentication it uses.

Differences between vendor implementations of IPSec also allow an attacker to fairly accurately determine what sort of device or operating system is running IPSec - even if all other ports are filtered, and normal methods of performing OS fingerprinting using malformed TCP/UDP data are prevented from functioning.

$ ike-scan -M --trans=5,2,1,2 --showbackoff 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1      Main Mode Handshake returned
	SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
10.0.0.1        1       1121251508.773117       0.000000
10.0.0.1        2       1121251510.772474       1.999357
10.0.0.1        3       1121251512.775259       2.002785
10.0.0.1        4       1121251514.777952       2.002693
10.0.0.1        5       1121251516.780746       2.002794
10.0.0.1        6       1121251518.783504       2.002758
10.0.0.1        7       1121251520.786298       2.002794
10.0.0.1        8       1121251524.791781       4.005483
10.0.0.1        9       1121251528.797329       4.005548
10.0.0.1        10      1121251532.802822       4.005493
10.0.0.1        11      1121251536.808370       4.005548
10.0.0.1        12      1121251540.813874       4.005504
10.0.0.1        Implementation guess: Firewall-1 4.1/NG/NGX

This example from the ike-scan tool's user guide(http://www.nta-monitor.com/wiki/index.php/Ike-scan_User_Guide) demonstrates the results of a scan executed against Checkpoint Firewall1. In combination with other tools, this information is extremely useful to an attacker.

Various forms of authentication using IPSec can grant an attacker the ability to find out more about an organisation.

Cert-based auth with IPSec / CA identity

The IPSec Key Exchange process can be used by attackers to identify which Certificate Authorities an IPSec peer's certificate was issued by (and hence which certificates can be used to mutually authenticate the IPSec peers). This information is carried in the CRP (Certificate Reuqest Payload). This information can potentially tell an attacker more about an organisation's PKI Infrastructure, since an attacker can use information on root CAs to map out an organisation's infrastructure or determine what is required in order to be allowed secure communication with a given host. Some IPSec implementations, such as Microsoft's, allow the Certificate Request Payloads to be omitted from the IKE process, thus closing this avenue of information disclosure; configuration of this option on windows is considered a best practice.

Kerberos

Kerberos can also be used to authenticate IPSec peers. The use of kerberos, as with certificates, gives an attacker more information on an IPSec peer's kerberos domain membership and position within a large IT Infrastructure.

PPTP

PPTP is a protocol jointly created by Microsoft and Cisco. PPTP has been historically fairly insecure, with relatively comprehensive high profile coverage of some of its larger failings.^[4] Whilst it is possible to configure PPTP in a relatively secure state, using Server Authentication with MSCHAPv2, some of these securer options are not supported by older platforms, and rely on administrators understanding how to competently configure the protocol and related authentication functionality.

Improving on the VPN

Application Refactoring

Simply rethinking how businesses give people access to their data in these sorts of scenarios can both improve security and make accessing data far, far easier; replace Outlook/MAPI with RPC-over-HTTP (which isn't as scary as it sounds) or Outlook Web Access. Replace accessing SMB shares remotely with webdav over SSL. LoB apps are a little harder, but most major vendors of business software are adapting to allow their apps to be delivered over the web, and ACT! is no exception.

Replacing applications delivered over VPNs with a web-based equivalent allows you to expose a subset of your services to distinct users. Whilst at a transport level, the SSL tunnel that your mail accessed via HTTPS is being delivered over is no securer than an SSL VPN, once using this solution, you're now /only/ allowing clients (who can be authenticated securely with Certificates) to access those application-layer resources that you've decided they're allowed to talk to, at a high level, over that SSL tunnel - and not giving them the ability to route traffic into your internal network, removing a swathe of potential attacks.

In a conventional VPN usage scenario, if we assume that the credentials or certificate used for VPN and web authentication are compromised, a VPN infrastructure, at worst, gives an attacker access to our entire internal network. Typically, the credentials used for a VPN are likely to be good for authenticating to other network resources, too, allowing a hypothetical attacker to carry out authenticated as well as unauthenticated attacks.

By contrast, the compromise of the credentials used to access that person's mail via webmail or some other SSL-ified protocol (such as imaps, rpc-over-http, etc) generally only gives us access to that person's data.

With a compromised webapp, we have the capability now to leverage authenticated attacks against whatever app we have exposed, but with common types of web application vulnerabilities such as XSS, Session Management problems, and SQL Injection relatively well understood, even an imperfect web application presented to an attacker is likely to be a less terrifying prospect than full routed network access via openvpn. This, then, is a relatively contained compromise compared to the fairly unbounded access a VPN gives an attacker to most businesses.

There are also a very wide range of solutions and products designed to protect web applications and mitigate the risk of exposing them to users, from Application Layer Firewalls and Proxy Servers like ISA Server, Squid, and Apache, along with plugins such as mod_security, to the simple act of logging requests along with where they came from.

In addition to this, if you unencapsulate https traffic at the very edge of your network - as many reverse proxying application layer firewalls and proxy implementations will allow you can do, you can very effectively filter that traffic at the application layer (and even perform preauthentication) before it goes near any of the services your client is actually talking to.

Why are the alternatives better?

When VPNs Should be Used

Conclusion - VPN as a Last Resort

Footnotes

1. ↑ Many regard a VPN as a magical object of power, as J.R.R. Tolkien said, One ring to bring them all..., J.R.R. Tolkien. Handing power over to an unknown force is never a good idea.
2. ↑ http://support.microsoft.com/?kbid=278339
3. ↑ http://ikecrack.sourceforge.net/
4. ↑ http://www.schneier.com/pptp-faq.html

TODO

• NAC
• cisco webvpn
• NAQC/NAP

Additional Resources

NTA VPN Flaws Whitepaper (2005)

Cisco Network Admission Control

Cisco WebVPN product page

Microsoft Cable Guy - IKE for IPSec SA

Building and Installing openSwan

securityfocus: pentesting IPSec VPNs

microsoft technet: IPSec Best Practices

IKE Vulnerability risks (ppt)

OpenVPN

Hamachi

OpenSwan

mod_security