Virtual Private Networks (VPNs) are commonly deployed in businesses to provide either client-to-site or site-to-site network connectivity. VPNs are most frequently deployed within a business context to provide a secure method of delivering operated technical services to a target audience without exposing them on a public network. However, despite acting as a security mechanism, VPNs are often themselves subject to various security weaknesses due to either technical flaws or misconfigurations. In both cases, the end result can be the undermining of an organisation’s security posture that leads to potentially damaging exploitation.
In this blog post, we look at some of the common risks associated with VPN deployment, and how they can best be avoided so that technical services and functions can be delivered to the required audiences with greater security assurance.
The primary routing protocol used between computer systems and networks is known as “IP” (“Internet Protocol”). It forms the layer within the Internet protocol suite that is tasked with providing network layer communications: that is, in delivering network packets from a given source to their destination. IP works through a system of addresses that define where the data is to be delivered, with routing determined by defined routing tables that can incorporate both static (fixed) routes as well as routes generated via dynamic routing protocols.
Routing occurs via a system of repeated packet forwarding in which a packet is not sent directly from source to destination over a dedicated connection but makes its way via a series of “hops” between gateways or routers along its path, each of which may be operated by a different entity such as a network backbone provider or service provider. Each router bridges two or more networks and maintains a routing table that decides how each packet received is routed, essentially signposting it to its next “hop” along its path. Since there are millions of potential addresses, the routing tables cannot explicitly list every possible IP and the route to take for each, but instead, group potentially millions of IP addresses into a relatively small number of summary routes. This is conceptually analogous to a sign on a motorway that reads “A1 The South” rather than the address of every single house in the south of the country. At each stage of its journey, a packet needs only to be routed closer to its destination at each hop, not know its entire route in advance.
There are fundamentally two different IP address types: those assigned for public routing on the internet, and a set of reserved or special-use addresses that are restricted for use on private networks within organisations but which cannot be routed to via the internet. Of the approximately four billion addresses defined in IPv4, about 18 million addresses in three ranges are reserved for use within private networks. Packet addresses in these private ranges are not routable via the public Internet; they are ignored by all public routers. Most organisations have a private network that they use internally, with hosts assigned IPs from these private ranges. However, sometimes an organisation wishes to grant access to certain local resources within their private network to an external entity: a VPN is a mechanism that can be configured to bridge or tunnel between two or more of these private IP address spaces, allowing hosts or clients within one private network the ability to route to (and therefore access) hosts within the paired private network and its address space.
There are many uses of a VPN, varying in configuration, some allow the bridging of networks while some allow access to a remote gateway for the purposes of hiding internet traffic but in this article, we will be focusing on the typical networking use case used by the organisation to link private networks together.
A VPN works by acting as a special form of gateway that is able to bridge the connection between public and private address spaces in order to provide access to private networks across the public internet. Normal routers and gateways are also able to bridge private and public networks – by using network address translation to provide a mapping between private IP addresses and public IP addresses – however VPNs do not expose the private address space directly and require authentication in order for the address space to be accessed.
A VPN conceptually acts as though the two private networks were directly connected via a single router and hides the abstraction of the connecting hops across the intervening public network. That is, it forms a logical link between two networks that may be widely dispersed physically. To hosts on either side of the VPN connection, it appears as though the two networks are directly connected, and the VPN connection is often described as a tunnel (and the protocols used referred to as tunneling protocols) since traffic sent to a VPN router on one network appears to simply “pop out” within the second private network. Although not strictly required, VPNs almost always negotiate and establish transport-layer encryption across the link when it is established, meaning that the communications between the two private networks are theoretically secured from eavesdropping during transmission.
In many cases, organisations need to offer access to external parties to local resources located within their private network but are reluctant to expose them directly to the internet, by either provisioning them with a direct public network interface or by mapping their private network address to a public one via network address translation. In both cases, the service would become publicly available on the internet and hence visible to a very wide audience, something that significantly increases the threat surface or attack surface of the operated host and service and making it more susceptible to potential exploitation, if any security vulnerabilities are exposed.
One method of minimising the attack surface of a service is through exposing the device on a public IP and then using packet filtering firewalls in order to restrict access to the given service or host such that the firewall rejects requests to the service that do not originate from specific, whitelisted source IP addresses or ranges.. However, VPNs can offer both a more secure, as well as a more flexible approach: they can deliver enhanced security by natively incorporating both encryption and authentication measures in the service access, to provide greater assurance of confidentiality; and they can support connection from multiple clients that operate from dynamic (roaming) IP addresses rather than only those that operate on a fixed source IP address.
VPNs services are delivered by specialised dedicated hardware known as VPN routers or as a software solution on an existing server that is deployed at the network edge – the boundary between the public and private network segments of an organisation. They handle the setup of VPN tunnels and then subsequently act as one terminal or end of an established tunnel, where tunnelled traffic enters and exits the private network. The VPN router has network connections or leg in both the private and public network spheres, so clients connect from one end of the tunnel across a public network can have their packets “dropped” into the private network when they exit the VPN tunnel.
It is possible to deploy VPNs in both “client to site” and “site to site” configurations. In the former configuration, there is only a fixed VPN router at one end of the connection: it acts as the “server” establishing individual tunnels dynamically upon requests from one or more requesting remote clients. This form of VPN router is commonly referred to as a VPN concentrator since it acts as a concentration point for a potentially large number of discrete VPN tunnels. Client-to-site VPNs are often used in order to provide remote workers with access to internal corporate systems:
The second type of configuration, known as site-to-site, is used instead to securely integrate multiple separated private networks and has twin VPN routers, one deployed within each of the connected private networks. This configuration can be used by enterprises to join multiple physically separated private networks (such as branch offices in different cities or separate physical and cloud network infrastructure) into a single logical private network. It can also be used to provide third-parties such as business partners with secure access to an organisation’s systems in scenarios where collaboration or outsourcing requires shared system access. A site-to-site VPN typically establishes a semi-permanent or “always on” connection between the two remote private networks rather than establishing connections on-demand, and has a VPN router at each end of the connection:
VPN technology can vary but the protocols most widely used for VPNs are Point-to-Point Tunneling (PPTP), Internet Protocol Security (IPsec), Secure Socket Tunneling (SSTP) and Internet Key Exchange (IKEv2). All of these protocols have the potential to be deployed insecurely, as well as to suffer from underlying weaknesses due to errors in their implementation, as we shall see below.
VPN routers and concentrators are extremely attractive targets for attackers. Not only are they internet-facing, and hence easy for attackers to scan or probe for vulnerabilities, but attackers are aware that the router will have a leg or second interface that bridges to a local/private network. This means that if the device can be compromised, an attacker may be able to gain access to a privileged network segment. Many public-facing hosts and services such as web servers may typically be deployed within a screened network segment known as a DMZ or demilitarized zone that is itself firewalled from more sensitive network segments. VPN routers, however, can often offer routing to network segments within the application or data tiers, offering an attacker that is able to compromise them a much more privileged network position.
It is therefore critical that VPN routers are suitably hardened against attack. Hardening is a process that involves changes to a host system configuration that aims to make it more resistant to attack. This can involve reducing its attack surface by – for example – reducing the number of operated network services to the minimum number necessary for essential service delivery. It can also involve reducing the privileges of system accounts used to operate network services, and various other measures as outlined in our dedicated blog post on this topic.
In addition to hardening the device configuration, the VPN router or concentrator also needs to be subject to strong vulnerability management practices including foremost the regular patching of the device for security updates in particular. Devices such as VPN routers can sometimes be neglected even under established patch management programmes operated by security teams since they can often operate proprietary operating systems or otherwise be difficult to integrate into broader patching practices and tooling that covers the majority of the hosted estate.
It is clearly important that VPN routers establish VPN tunnels only with trusted connecting parties, rather than establishing tunnels with anyone who requests it. This requires validating the identity of any remote party making a connection request (whether that be a client or a partner VPN router). This is performed using authentication services, but the implementation details can vary significantly, and how authentication is performed is perhaps the single most important factor that determines the security of an operated VPN service.
The weakest option for authentication is requiring only a single authentication factor – typically a password. Single-factor authentication is when only one form of verification is used to prove a claimed identity. The factor is one of three primary types, normally described as “something you know” (for example a password), “something you have” (such as a hardware token) and “something you are” (a biometric, such as a fingerprint). Although the exact components used can vary – including digital certificates, passwords, access tokens and encryption keys), the key to strong authentication is generally recognised as requiring multiple factors to be provided (and satisfied) before agreeing that a claimed identity has been proven or established and granting access. Most VPN services permit configuration of strong, multi-factor authentication.
One common anti-pattern seen in VPN configuration is issuing access credentials based upon organisation identity rather than individual identity: that is to set up an account (and associated access credentials) based upon the name of or assignment to a group (or even an entire organisation) rather than a named individual.
There are several potential issues with this approach, but primarily it means that the trust relationship has been established with a nebulous entity rather than a known individual. This means that an issued credential may be known to and shared by a large number of individuals. At no time is it therefore possible to establish who exactly is using the VPN access, meaning that in the event of a compromise it may be difficult to determine who the responsible party was. As employees naturally move on from an organisation, it also means that the credentials may remain known to them, when they have no business requirement for doing so.
Closely related to the issue of identity allocation is the wider issue of concerns around what is known as the identity management lifecycle. This involves procedures around identity management throughout the forecast term of the account. Rather than issuing an account that is evergreen and valid in perpetuity, it is best practice to ensure that the account is provisioned only for a fixed period (for example relating to a negotiated contract). It is also vital to ensure that accounts are subject to periodic review to ensure that they are still required and that they are disabled once they are no longer needed.
As with accounts, issued credentials should not be considered to be issued in perpetuity, or even for the lifetime of the account, but should ideally be rotated or replaced. The issue is that the longer that a credential is in service, the greater the likelihood that it will eventually be compromised or known to attackers and unauthorised parties. This may be either through basic information leakage, or in the case of cryptographic elements such as keys by eventual brute-forcing of the key.
The encryption used to secure VPN tunnels – whether using IPsec or any other cryptographic alternative – typically offers a number of algorithms and ciphers within a cipher suite. The exact cipher used to encrypt a given connection may vary from one connection to another, depending on the capabilities of the initiating client and server, which are often operating different technology stacks yet nevertheless need to communicate over a common set of protocols and standards. This means that the majority of VPN routers will offer a large number of possible ciphers, and the cipher chosen for a given connection is negotiated at connection initiation based on the highest common denominator of the two parties’ capabilities.
However, support for old and weaker ciphers may lead to the compromise of a given VPN tunnel by an attacker. As ciphers age, they are subject to weakening in two ways. Firstly, as computing power increases over time, what was once a secure key strength may become practically breakable and exploitable via cryptographic brute force. Both peers in an IPsec VPN connection must use the same Diffie-Hellman group, for example, which is negotiated during Phase 1 of the IPsec negotiation process. Many devices operating today will still offer the legacy “Group1” set, which has a strength of 768-bits and was proven to be vulnerable to brute-forced attacks over 12 years ago, making it absolutely practical to break today.
Secondly, ciphers and algorithms are subject to greater and greater scrutiny and research over time and exploits are commonly found that undermine their cryptographic strength completely.
These issues are especially problematic since it is common for VPN routers to have relatively long service lives and for given VPN tunnels to be configured once and never subsequently subject to re-review.
IPsec and other VPN technologies typically use a system of public key (asymmetric) cryptography to negotiate a secure connection initially since it allows a secure connection to be established over an insecure channel. However, it is computationally expensive, so rather than securing the connection itself and all the data transferred over it, it is normally used in an initial phase only to establish a secure connection over which a symmetric key can be transferred between the two parties, and which can then encrypt all future traffic over the connection.
The longer this symmetric session key is used, however, the longer time an attacker has to attempt to crack the key and decrypt the VPN tunnel contents. It is therefore strongly advised to set a relatively short session key lifetime, after which the two VPN peers must re-negotiation a new session key.
VPN routers are often dedicated hardware appliances provided by vendors (as opposed to software running on commodity server hardware) and lack a local keyboard/monitor interface. Access to configuration is therefore most commonly via a management console or similar that is exposed on a network port (such as SSH or HTTP) for remote access by administration staff.
Even though the management interface will typically be secured using strong authentication, is intended that this management interface is only exposed on local network interfaces within the private network – and ideally to a trusted or restricted rather than general-access network segment. If misconfigured and the administrative or management interface is exposed on a public network segment (i.e., directly on the internet) then the attack surface of the VPN router extends to be accessible by a much wider range of remote attackers.
Unlike the management interface, the service interface that is used for clients and peer devices to connect clearly needs to be exposed on a public network interface. This means however that the service interfaces of VPN devices are internet facing, and hence exposed to attackers.
In the case of client-to-site VPN concentrators this is an unavoidable consequence of the service design and needs to be mitigated as best as possible using the various other measures outlined in this list. However, in the case of site-to-site VPN routers, it is often possible to remove this risk entirely by ensuring that the interface is exposed only to trusted external parties. VPN technologies such as IPsec explicitly contain configuration options to identify unique peers via IP address and to assign discrete access and peering credentials to them. However, since this is implemented at the VPN service level, it does not prevent other IP addresses from making initial connections to the VPN service. In the case of protocol vulnerabilities that can be exploited sufficiently early in the connection negotiation sequence, therefore, a VPN service may be exploitable by attackers even where the peering is restricted to a known whitelist of IPs.
This can be prevented by screening the VPN router behind a firewall and mirroring the peer list of IP addresses in a service access whitelist, preventing unrecognized and untrusted IPs from even seeing the VPN service port, let alone attempting to establish a connection and potentially being able to exploit a protocol weakness.
An extremely common misconfiguration is for VPN tunnel to deliver overly broad network access to authenticated clients in an “all or nothing” fashion. In this scenario, the private network “leg” of the VPN router resides in a trusted network segment on the local network, “behind” the firewall and with unrestricted access to application and data tier services. If a client (or peer router) is authenticated successfully, then they gain unrestricted access into the heart of an organisation’s network, and to every single service that is located there regardless of whether they have a valid business reason for accessing it. This violates the security principle of least privilege and causes a range of security issues.
A more secure solution is to terminate VPN tunnels on the private network, but in a demilitarized segment: one that is segregated from other network segments by a firewall and with a default-deny for onward access, with routing permitted only to explicitly permitted hosts and services. Some VPN devices and network architectures now extend this principle into the concept of zero-trust access. This better aligns with the principle of least privilege outlined above, and only allows a remote client or peer to access exactly the services and applications they need. Systems such as Cisco’s Security Group Tags (SGTs) provide unique labels that describe which privileges a given account is permitted within the network, but this capability is also provided by many other vendors.
Although the measures outlined above provide varying levels of mitigation against various risks to operated VPN services, risk can never entirely be eliminated via technical controls and some remnant risk always remains. In addition to preventative controls (those that prevent exploit), it is therefore always advisable to implement partnering and robust detective controls (those that detect a security breach or incident should it occur).
Best practice in this area involves the setup of effective logging from the VPN device, especially of key security events such as failed (and successful) authentication events, tunnel connections and disconnections, and changes to any configuration parameters. But logging is only part of the story: effective monitoring means ensuring that log events are subject to both periodic manual reviews, as well as used for the basis of automated alarming and alerting if suspicious events are detected. Security events that may need investigation can be either qualitative or quantitative: that is, some single events may trigger an alert in themselves due simply to their severity or unexpectedness, whereas other events may only trigger an alarm if they exceed a certain count of threshold (such as failed logins).
AppCheck helps you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities – including many common VPN vulnerabilities including missing patches, weak and outdated ciphers, and weak authentication.
The AppCheck Vulnerability Analysis Engine provides a detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, networks, and cloud infrastructure. AppCheck is authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@localhost
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorized by te Common Vulnerabilities and Exposures (CVE) Program aas a CVE Numbering Authority (CNA)
