Security issues with Virtual Private Network (VPN)

and proxy services

Sanjeeth Rajeshwaran Mrityunjay Singh Prakhar Dubey
Computer Science and Engineering Computer Science and Engineering Computer Science and Engineering
Shiv Nadar University Shiv Nadar University Shiv Nadar University
[email protected] [email protected] [email protected]
Ekansh Agarwal
Computer Science and Engineering
Shiv Nadar University
[email protected]

Abstract— The paper aims to explore the vulnerabilities VPN service provider may have servers all over the world.
associated with VPN services and assess any security flaws that That means the user’s search activity could appear to origi-
VPN service providers may have exposed their clientele to. nate at any one of them. Search engines also track your
Initially delving into common security flaws with VPN, this search history, but they would associate that information
paper then shifts its focus to client-side vulnerabilities with with the IP address of the VPN server. Privacy with regard
VPN arising due to poor configuration of VPN services and to online activity is still maintained.
default configurations.
VPN protects privacy:
1. INTRODUCTION
A VPN can hide a lot of information that can put user’s
The term virtual private network (abbreviated VPN) privacy at risk. A few are elicited below:
describes any technology that can encapsulate and transmit
network data, typically Internet Protocol data, over another • Browsing history:
network. Users of the internet increasingly rely on commer- The Internet Service Provider and the user’s web brows-
cial virtual private network (VPN) services to protect their er can track every activity on the internet. A lot of websites
security and privacy. The VPN services route the client’s track every activity on the internet and may also keep an
traffic over an encrypted tunnel to a VPN gateway in the activity log or access history. This information in conjunc-
cloud. Thus, they hide the client’s real IP address from on- tion with the user’s IP address can be used for targeted ad-
line services, and they also shield the user’s connections vertising. The website in an attempt to reap profits may col-
from perceived threats in the access networks. lude with a malicious third-party.
Before addressing the security issues with VPN, it is The VPN services aim to protect the above private de-
essential to understand to underlie answers to some ques- tails.
tions concerning VPN.
• IP address and location:
Need for a VPN service
IP address is the equivalent of the return address on a
Surfing the web or transacting on an unsecured Wi-Fi letter. It routes back to the originating device. Anyone with
network is tantamount exposing private information and access to the IP address of a machine can access the search
browsing habits. A VPN is used in these cases to conceal history of the machine on the internet and the last pinged
this private information and maintain privacy. location of that device.
While using public networks the susceptibility to eaves- Through routing, VPN uses an IP address different than
droppers on the same network increases. While employing that of the user to maintain online privacy of the user allow-
an efficient VPN service, they can provide encryption and ing them to search the web anonymously.
anonymity that helps protect user’s online activities: sending
emails, shopping online, or paying bills. VPNs also help • Devices:
keep user’s web browsing anonymous. A VPN can help protect user devices, including desktop
How a VPN protects user’s IP address and privacy computer, laptop, tablet, and smart phone from prying eyes.
These devices are prime targets for cybercriminals when
VPNs essentially create a data tunnel between user’s users access the internet, especially if they are on a public
local network and an exit node in another location, seeming- Wi-Fi network. VPN helps encrypt and protect the data sent
ly convenient to pose the user’s device in another place. and received to obfuscate this information form hackers.
This benefits the user attempting to access apps and web-
sites on the go, by promising online freedom. • Web activity — to maintain internet freedom:
In an attempt to obfuscate data, VPN’s use encryption to If the VPN provider does not maintain user browser his-
scramble data when it’s sent over a Wi-Fi network. Encryp- tory, VPNs can help protect user’s internet freedom by con-
tion makes the data unreadable. Data security is especially cealing the user’s IP address.
important when using a public Wi-Fi network, because it
prevents anyone else on the network from eavesdropping on 2. RELATED WORK
user’s internet activity. [1] concentrates on outlining security flaws with remote
access VPN configurations using the IPsec protocol al-
Without a VPN, the internet service provider is privy to though, some of the findings are also applicable to site-to-
the user’s entire browsing history. With a VPN, the user’s site VPNs. Some of the elicited problems were new discov-
search history is hidden, as the web activity will be associat- eries of the period such as username enumeration whereas
ed with the VPN server’s IP address and not the user’s. A
others were known limitations of the protocols employed • Storing the plain-text password in memory
exposed due to poor configuration.
Storing the hashed password in the registry is bad
The authors in [3] studied the security of commercial enough as explained above, many clients tend to store the
VPN services. They focussed on how the client applications plaintext version of the password in the memory. In this
set up VPN tunnels, and how the service providers instruct case, anyone with access to the client computer can obtain
the users to configure generic client software. They analysed the password by starting the VPN client and then dumping
common VPN protocols and implementations on Windows, the process memory with a tool such as pmdump or crash-
macOS and Ubuntu. They found that VPN clients have vari- ing the computer to get a dump of physical memory.
ous configuration flaws, which an attacker could exploit to
strip off traffic encryption or to bypass authentication of the • Weak registry or file permissions for stored credentials
VPN gateway. In some cases, the attacker could also steal Caching credentials is inane, but it can be worsened if
the VPN user’s username and password. They have also they are stored in a file or registry entry with read right to
suggested mitigation solutions to the discovered vulnerabili- the public users. This allows these details to be obtained
ties. from guest or anonymous network connections as well as
via physical access to the client system.
3. TECHNICAL DETAILS AND RESULTS
B. Username enumeration vulnerabilities
I. COMMON SECURITY FLAWS WITH VPN
Many remote access VPNs use IKE Aggressive Mode
A. Insecure Storage of Authentication Credentials by VPN with pre-shared key (PSK) authentication as the default au-
Clients thentication method. The PSK authentication method is in
Many VPN client programs offer to store some or all the essence the well-known username/password scheme. One of
authentication credentials (e.g., username and password), the basic requirements of a password-based authentication
with this being the default setting for some clients. While scheme is that the response to an incorrect login attempt
adding to the ease of use of the VPN, this can however in- should not leak information about which of the credentials
troduce security risks, especially if the credentials are not (username/password) was incorrect as this would inadver-
well protected. tently reveal more information to the attacker who can de-
duce a particular username’s validity.
The authors in [1] have witnessed the following
common client issues: Many implementations of PSK authentication do not
abide by this and give different responses to invalid and
• Storing the username unencrypted in a file or the reg- valid usernames.
istry
• Some VPN servers only respond to the client if the
Users privy to the client computer can obtain the user- username is valid, they do not respond at all to invalid
name. If the VPN were using IKE (Internet Key Exchange) usernames.
Aggressive Mode, knowledge of the username allows an
offline cracking attack against the password (explained later • Some VPN servers will respond with a notification
in this paper). message, e.g., NO-PROPOSAL-CHOSEN, if the username
is incorrect.
• Storing the password in a scrambled form
• Some VPN servers respond to both valid and invalid
Often referred to as “encryption”, this but a form of ob- usernames, but the hash payload for invalid usernames is
fuscation of details as there is no unique key to decrypt this. calculated using a null password, and it is simple for the
Should the attacker have knowledge of the obfuscation client to determine this.
(hashing) algorithm, he can follow a dictionary attack to
arrive at the matched password. An example of this issue is shown below. In this exam-
ple, ike-scan is used to demonstrate that the VPN server
responds to valid usernames normally, but to invalid user-
names with a notify message. This shows that, for this VPN authenticated nature of the phase 1 SA. Without complete
server, the username fred is valid, but the username jim is phase authentication, this protocol does not provide any
not. [1] authentication at all, since it becomes easily vulnerable to
Man-in-the-Middle (MitM) attacks.
The pre-shared key is merely used for authentication and
$ ike-scan --aggressive --id=fred not for encryption. IPsec tunnels rely on the ISAKMP/IKE
172.16.2.2 protocols to exchange the keys for encryption, etc. But be-
Starting ike-scan 1.7 with 1 hosts fore IKE can work, both peers need to authenticate each
(http://www.nta-monitor.com/ike-scan/) other (mutual authentication). This is the only part in which
the PSKs are used (RFC 2409). During this stage of mutual
172.16.2.2 Aggressive Mode Handshake authentication, all a Man-in-the-middle attacker has to do is
returned to forward the authentication challenge to the client at the
SA=(Enc=3DES Hash=SHA1 Auth=PSK other end, receive and pass on the response to the VPN
Group=2:modp1024 LifeType=Seconds server. Now the attacker is connected to the client and is
fully authenticated to the VPN server and can intercept the
LifeDuration(4)=0x00007080) network traffic and may log/alter the traffic, thus breaching
KeyExchange(128 bytes) VPN security.

Nonce(20 bytes) The detailed explanation of launching a MitM attack can

be found in [1]
ID(Type=ID_IPV4_ADDR,
Value=172.16.2.2) E. Lack of account lockout
• Many VPN implementations do not support system
Hash(20 bytes) lockout after multiple login attempts and allow an unlim-
ited number of login attempts. This may allow variants of
brute-force attacks or online dictionary attacks since there
$ ike-scan --aggressive --id=jim are no lockouts.
172.16.2.2
F. Poor default configurations
Starting ike-scan 1.7 with 1 hosts
(http://www.nta-monitor.com/ike-scan/) The default configurations for a VPN server are geared
towards usability rather than security. Typically, the default
172.16.2.2 Notify message 14 (NO-PRO- authentication method is IKE Aggressive Mode with pre-
POSAL-CHOSEN) shared keys, even when stronger authentication methods
such as Main Mode with certificates are available. IKE Ag-
The knowledge of the validity of the username entered gressive Mode with pre-shared key authentication has
by a malicious attacker through different responses as known issues, few of which have been discussed earlier.
shown above is indispensable. Since usernames are mostly
derived from names/monikers or email addresses, they re- The end-users are under the assumption that the default
veal more information about the user. Understanding the configurations suffice their security needs due to a sense of
username format for one user can allow the attacker to de- trust towards the vendors. Mostly documentations or guides
duce the format of usernames for other users in the organi- do not alert them to change these default configurations to
zation. better protocols.
C. Offline Password Cracking G. Poor guidance and documentation
Having obtained a valid username using IKE Aggressive The lack of sufficient guidance and documentation from
Mode, it makes it possible to obtain a hash from the VPN VPN implementations or providers hinders the ability of
server. This hash can be used to mount an offline attack to end-users to make informed decisions about the choice of
crack the password (dictionary attack). As shown in above configurations to use. Guidance to use stronger ciphers, elic-
example all necessary details for calculating the hash can be iting the risks of using IKE Aggressive Mode with pre-
obtained from the first initiator and IKE responder packets shared key is expected from the providers. With no warn-
barring the PSK on which a dictionary attack is initiated. ings about these in the documentations and no warnings
Offline attacks are resilient to system lockout as it not being when selecting these configurations, the users are oblivious
done on the system. to safe and unsafe options. This is not in good faith consid-
ering that VPN is a critical part of the user security perime-
D. Man-in-the-middle attacks ter.
For VPN servers using IKE Aggressive Mode, it is evi-
dently possible to determine a valid username and password, The further sections shall delve deeper into these issues
then an ISAKMP SA (Internet Security Association and Key with poor default configurations and poor documentations
Management Protocol Security Association) can be estab- and how this can lead to more vulnerabilities. Vulnerabili-
lished to the VPN server. Even if the VPN employs a second ties in various VPN protocols shall be explored when sub-
level of authentication this often relies on the security of this ject to poor configurations.
ISAKMP SA. In this case, if it is possible to establish an
ISAKMP SA then the second level of authentication would
not provide complete protection because it would be vulner- II. CLIENT-SIDE VULNERABILITIES WITH VPN
able to a man-in-the-middle attack. With reference to [3] this paper analyses commercial
This risk is acknowledged in the XAUTH IETF draft[2] VPN services and the various protocols in their employ and
elicits the vulnerabilities specifying the particular operating
The protocol described in this memo strictly extends the system in tandem with the configuration in which the vul-
authentication methods described in [IKE]. It does not in nerability was found. [3] reveals various vulnerabilities in
any way affect the authenticated nature of the phase 1 secu- the configurations of VPN clients, which allow attackers to
rity association. In fact, this protocol heavily relies on the strip off traffic encryption or to bypass server authentica-
tion. By exploiting these vulnerabilities, attackers can inter- a) Point-to-point Tunnelling Protocol
cept network traffic to and from the victim.
Point-to-Point Tunnelling Protocol (PPTP) was created
A. Background by Microsoft, and it is one of the oldest VPN protocols. It
has well-known weaknesses and is no longer considered
• Commercial VPN services allow users to tunnel their secure. The protocol however, remains widely deployed and
Internet traffic via the service provider’s gateway used since many firewalls do not block it.
server somewhere in the cloud. Typical use of com- The vulnerability associated with PPTP is that of optional
mercial VPN’s includes accessing geo-blocked or encryption. Windows by default does not enforce encryption
country-specific media contents and for securing on any VPN connection.
sensitive online activities while using public Wi-Fi
networks. The authors found that many of the commercial VPN ser-
• Most commercial VPN providers have a native client vices in their study did not instruct their users to change this
setting while configuring PPTP with the built-in client on
application which sets up the VPN connection for the Windows. This can be used to advantage by a network at-
user. The native client applications rely on the oper- tacker to perform several impersonation attacks, primarily to
ating system’s built in VPN client functionality launch a Man-in-the-Middle attack as follows:
whenever it exists.
• First, the client establishes a connection to the speci- First, the attacker acts as a man-in-the-middle to forward
traffic between the client and the honest server until the au-
fied server with the selected protocol. The client and thentication phase is finished The attacker then switches to
the server then authenticate each other in the selected performing server impersonation and negotiates with the
protocol with the previously configure credentials client not to encrypt the data exchange. The client agrees to
and roots of trust. After successful authentication, the this because it is not mandatory to use encryption. As the
client and server negotiate various parameters for the result, the attacker obtains all traffic of the victim just as if
VPN connection, such as the encryption scheme and no VPN was used.
the DNS servers. When the negotiation is completed,
the client computer’s routing table or
• Firewall rules are configured to tunnel all network
traffic through the VPN connection.

B. Study of Commercial VPN services as conducted in [3]

i) Adversary Model
The authors have considered two types of attackers:
Network attackers: An active network attacker is one who
can intercept and modify network traffic originating from FIGURE 1: POINT TO POINT TUNNELING PROTOCOL
and destined to the user’s machine. The attacker could, for
example, be a rogue hotspot operator at a hotel or airport, or
a compromised core-network operator.
Local attackers: Misconfigured IPC (Inter Process Connec- b) SSTP
tions) may be vulnerable to attacks by non-privileged pro- Secure socket tunnelling protocol (SSTP) is another VPN
cesses of other users, including guest users, who have access protocol created by Microsoft. It utilizes PPP to transport
to the same computer (so-called Man-in-the-Machine at- network traffic, but instead of using GRE as PPTP does, it
tacks). These unprivileged attackers could exploit the IPC encapsulates the PPP packets in HTTPS (Hyper Text Trans-
channels of VPN client applications to steal sensitive infor- fer Protocol).
mation or to modify the VPN connection settings. They are
the local attackers.
ii) Methodology
The authors focussed on the standardized and most com-
monly supported VPN protocols: PPTP, IPsec, IKEv2,
L2TP/IPsec, SSTP, OpenVPN, Cisco and SoftEther VPN.
Potential misconfigurations and architectural mistakes that
might compromise the security were looked for. They did
not try to find flaws in the cryptographic protocols them-
selves or code-level implementation errors.
The details of experimental verification can be found in [3].
This paper shall not deliberate on the methodology but lays
focus on the end results of the study conducted in [3]. FIGURE 2: SSTP CONNECTION
iii) Study results
The results of the study conducted by the authors in [3] are
summarized here. The protocol under study is described The associated vulnerability is that of Ignored Certificate
briefly followed by its vulnerabilities:- verification failures.
The results are specific to Ubuntu. sstp-client on
Ubuntu does not consider whether the server’s certificate is
trusted. By inspecting the source code of sstp-client, %any will force the client to accept any certified server re-
the authors found the reason for this unexpected behaviour: garded of its identity. The network attacker may pick any
the sstp-client is integrated into Ubuntu network con- domain under his ownership and get it certified by a trusted
nection manager, which allows the user to configure Certifying Authority (CA).The attacker can then imperson-
whether the connection should be terminated when the cer- ate the server in the server authentication step because the
tificate verification fails, but sstp-client ignores cer- VPN client does not check the name in the certificate.
tificate verification errors regardless of this setting. However, MS-CHAPv2 actually provides mutual au-
Ignoring the certificate verification failure allows the thentication with the user password. The binding of this
network attacker to perform a server impersonation attack as authentication to the SA prevents the attacker from complet-
follows. First, the fake server presents a self-signed TLS ing the protocol without knowing the user password. Thus,
certificate to the honest client. Under the pretence of the the misconfiguration effectively reduces the security of
client the fake server connects to the honest server. The at- IKEv2 to that of MS-CHAPv2, which unfortunately is equal
tacker forwards traffic between the honest client and the to the strength of a single DES encryption and vulnerable to
honest server until the PPP authentication is completed and password cracking. The resulting security is significantly
the attacker sees the Call-Connected message. The attacker weaker than expected because usually these weaknesses of
then stops forwarding traffic to the honest server and finish- MS-CHAPv2 are masked when it is used inside a server-
es the PPP negotiation by itself. When the SSTP connection authenticated tunnel.
is successfully established, the attacker’s fake server can act d)OpenVPN
as the VPN gateway and obtain all the victim’s traffic.
OpenVPN appears to be the most widely supported proto-
col by commercial VPN services. It uses TLS (Transport
c) IKEv2 Layer Security) as the underlying authentication and key
exchange protocol. Commercial VPN services deploy
IKEv2 VPN is a more modern VPN protocol based on OpenVPN in the client-server mode. In this mode, the server
IPsec. It uses IKEv2 for authentication as well as establish- authenticates itself to the client with an X.509 certificate
ing and maintaining security associations. One improvement signed by a CA that the client trusts while the client proves
of IKEv2 over IKEv1 is that the new protocol allows each its identity to the server with a username and password.
endpoint to use a different authentication method. IKEv2
also supports EAP, extending the selection of available au- Despite the wide spectrum of configuration options that
thentication methods. [3] OpenVPN supports, the authors were not able to find any
broken configuration examples susceptible to attack from a
network attacker to compromise the connection. This can be
attributed to the detailed documentation and configuration
guidelines of OpenVPN. The authors found, however, that
local attackers, i.e., non-privileged local users and process-
es, can steal the username and password used for authenti-
cating the client.
Credential Leakage
The VPN applications which store the credentials in
configuration files that are readable to all the users on the
client computer are specifically careless while passing the
username and password to the OpenVPN daemon. On Win-
dows, the configurations are usually stored in the Pro-
FIGURE 3: IKEv2 CONNECTION gramData or Program File folders, and the vul-
nerable software does not set the access-control list to pre-
vent access by unauthorized users. Thus, the local (i.e., any
unprivileged process running on the same computer) can
Unspecified Server Name capture this sensitive information. Even though some ser-
vices remove the credentials from the file after the estab-
Specific to the implementation on Ubuntu, to establish an lishment of the connection, this still leaves an opportune
IKEv2 connection with StrongSwan on Ubuntu, the user has window of a few seconds to access this information.
to create a profile for the connection in /etc/ipsec.-
conf. Several commercial VPN providers in the study in- Lack of admin password
structed their users to create the profile as follows Most of the commercial VPN services in the study do not
leftauth =eap−mschapv2 enable password protection on the management interface.
Denial-of-Service attacks may be launched to annoy the
. . . victim user.
right =<server−address >
rightauth =pubkey e) SoftEther VPN
rightid =%any SoftEther VPN is yet another VPN protocol with an open-
... source implementation that tunnels Ethernet frames over
HTTPS. Similar to OpenVPN in the client-server mode, the
With left and right indicative of the client and the server, SoftEther VPN server proves its identity to the client with a
respectively, with such a profile, the server uses a public key TLS certificate while the client has a username and pass-
for authentication while the client uses EAP-MSCHAPv2. word for its authentication.
With the rightid setting which is informative of how the
server should be identified in the authentication, setting it to
No Server Verification cols one after another until it succeeds in creating a VPN
connection. Users typically find themselves using this op-
When creating a new SoftEther VPN connection, the GUI tion if the firewall in the access network blocks some VPN
for some commercial VPN services allow the user to choose protocols or if they wish to not find themselves buried in the
whether the client verifies the server’s certificate. The de- documentation of the various technical intricacies of choos-
fault setting is False, and the VPN services do not tell their ing the right protocol and configuration.
users to change the setting.
Fallback to weakest option
Hide.me (A VPN service) supports SoftEther VPN on its
GUI. However, the CheckServerCert parameter is set It is evident that the security of the fallback option the
to false by default in its client configuration. Consequently, fallback strategy is equal to that of the weakest option which
the client does not verify the server’s certificate. This allows the application is willing to try. As a means of intervention,
the network attacker to perform a MitM attack on its con- the network attacker can simply block all other connection
nections. The attacker can thus obtain the victim’s creden- attempts. The authors found that some commercial VPN
tials and network traffic. services include L2TP/IPsec with publicly known pre-
shared key as an option in their automatic mode. For exam-
Wrong VPN server ple, ExpressVPN attempts to use the following protocols:
Another problem identified with Hide.me is that its GUI OpenVPN, SSTP, and L2TP/IPsec. If the network attacker
does not require password authentication on the manage- blocks the first two (e.g., by filtering the corresponding
ment interface of the vpnclient process. This allows the ports), it effectively forces the client to use L2TP/IPsec. As
local attacker to connect to the interface and, for example, the result, the attacker can perform a MitM attack on the
may launch a new VPN connection that routes all network VPN connection and obtain the traffic as explained in previ-
traffic of the victim to a malicious server under the attack- ous sections.
er’s control.
v) Mitigation Solutions
f)L2TP/IPsec The authors in [3] have proposed mitigation solutions to the
26/30 VPN services in the study still employ known pre- above identified vulnerabilities in the various protocols and
shared key to authenticate IPsec tunnels. VPN services examined. They have been summarized in
brief as follows:-
In the L2TP/IPsec VPN connection, L2TP and IPsec
together provide two layers of authentication as (1) IKEv1 a)PPTP
for authenticating the communicating machines and (2) The VPN service providers simply need to update their in-
PasswordAuthentication Protocol (PAP) or Challenge- structions to tell Windows users to change the Data encryp-
Handshake Authentication Protocol (CHAP) for authenticat- tion setting of the PPTP connection adapter from Optional
ing the user. However, the confidentiality and integrity of encryption to Maximum strength encryption. This enforces
the resulting connection relies entirely on the IPsec tunnel MPPE encryption with a 128- bit key on the connection.
because L2TP does not provide any transport protection. If
the network attacker manages to break the IPsec tunnel, the b)SSTP
integrity and confidentiality of the connection are compro- The sstp-client in Ubuntu ignores certificate verifica-
mised. By using a known pre-shared key to authenticate the
tion failures. The flaw is in the sstp-client library
IPsec tunnel, commercial VPN providers enable the network
attacker to perform a MitM attack on the L2TP/IPsec con- code. Until it is fixed, commercial VPN services should
nection and to capture the victim’s network traffic. [3] explicitly instruct their users to not use sstp-client and
possibly provide an alternative. The broader issue here is
that modern software development practices create complex
dependencies on free and third-party components, for which
there may not be guaranteed maintenance. One would ex-
pect security-critical services, such as commercial VPNs, to
manage their dependencies carefully. [3]
c)IKEv2
Setting the rightid value of a StrongSwan’s IKEv2 con-
figuration to %any could be useful, for example, when test-
ing a VPN server. However, the setting should never be used
in production. To fix the problem, the commercial VPN
providers should give clear instructions to the users to set
rightid to the server’s domain name or to the Distin-
guished Name from the server’s certificate. Alternatively, if
the right parameter (i.e. the address of the server) is already
FIGURE 4: L2TP/IPSEC CONNECTION set to the server’s domain name, rightid does not need
to be configured because it equals the value of right by de-
fault. [3]
iv) Fallback Strategy d)OpenVPN
Commercial VPN services usually have a list of protocols at The pertinent solution to unauthorized users reading the
the disposal of the user. The user can choose on the GUI of OpenVPN configuration file is to set the access controls on
the provided application. A special option that several ser- the file, which is world-readable by default. Another solu-
vices in the study offered is “AUTOMATIC”. This means tion is to avoid writing the VPN username and password to
that the application will automatically select the protocol for the file by communicating them over the management inter-
the user. To realize this the application tries different proto-
face. Password authentication on the management interface GUI may not warn when selecting certain configurations
is also a good practice. and this only adds to the disdain.
e) SoftEther VPN • User awareness is of prime importance as they are the
end consumers. Should they choose to rely on free VPN
To fix the server verification problem that we described, the services they are often required to make compromises as
CheckServerCert parameter of the SoftEther VPN these free services may log user data and activity to
connection must be set to true so that the client verifies the launch targeted ads. These services may just be used to
server’s certificate during the establishment of the connec- bypass geographical blocks and should not be expected to
tion. This can be done either by changing the default value provide anonymity or data security.
of CheckServerCert in SoftEther, or the VPN services
can provide explicit instructions to their customers to do the Having elicited the study results after examination of
same. This again highlights the importance of safe default various VPN protocols and services, vulnerabilities have
values and the danger of allowing easy but insecure settings. been found in most implementations of the protocols of
studied VPN services. These vulnerabilities allow network
f) L2TP/IPsec attackers to initiate Man-in-the-Middle attacks on suscepti-
A solution is to switch from pre-shared keys to certificate ble users using these VPN services with default configura-
authentication. For this, the commercial VPN services must tions and intercept or modify their network traffic, defeating
obtain certificates for their VPN servers from a widely trust- the sole purpose of using VPN services rendering them re-
ed commercial CA. The client certificates, on the other dundant. It is concluded that security flaws, either accidental
hand, can be provisioned by the VPN service provider itself. or intentional, are not always deeply hidden in the code or
cryptography. Instead, simple configuration mistakes, poor
g)Fallback Strategy instructions, insecure default values, and failure to disable
Since the security of a fallback strategy is equal to the broken legacy features can result in widespread security
weakest allowed option, L2TP/IPsec with the known pre- failures across an entire industry.
shared key and PPTP with its cryptographic weaknesses
should be disabled in any automatic protocol selection
process. 5. ABBREVIATIONS
One of the main reasons why commercial VPN services • VPN: Virtual Private Network
provide fallback options is to bypass firewall filters. An al- • IP: Internet Protocol
ternative approach would be to only try safe firewall tra-
versal techniques such as using server ports that are usually • IKE: Internet Key Exchange
not blocked. • PSK: Pre-shared Key
• SA: Security Association
4. CONCLUSION • MitM: Man-in-the-Middle
VPN systems are not invulnerable as they have been • PPTP: Point-to-point Tunnelling Protocol
perceived to be. Through the above sections the vulnerabili-
ties of the various implementations of VPN protocols by • SSTP: Secure Socket Tunnelling Protocol
VPN services have been exposed. A brief summary follows. • L2TP: Layer 2 Tunnelling Protocol
SUMMARY
• TCP: Transport Layer Protocol
• A lot of attention is focused on the cryptography, but
in practice, the security problems are not normally in the • GUI: Graphical User Interface
cryptographic algorithms that are used. The vulnerabilities • TLS: Transport Layer Security
are generally caused by poor configuration or bad imple-
mentation rather than the cryptography.
• VPN vendors do not always employ well accepted 6. ACKNOWLEDGMENT
security policies. Aspects to security like not revealing We as a group would like to thank our professor and
information about valid usernames and system lockout guide Dr. Sweta Mishra who gave us her valuable sug-
after unsuccessful attempts have been in practice for gestions and ideas when we were in need of them. She en-
decades but have not been implemented by VPN service couraged us to work on this paper and has a big role to play
providers. in the completion of the same.We would also like to thank
• Ease-of-use supersedes user security. Many remote- all of the people who helped us in the completion of the
access VPNs use IKE Aggressive Mode with pre-shared paper. We are immensely thankful to all who helped us in
key authentication as the default configuration. This is the project and without whose guidance it would not have
worrisome as users tend to trust the VPN services enough been possible to finish the paper in prescribed time.
to use the default configurations perceiving them to be
sensible and secure. It is an argument that vendors are REFERENCES
failing their customers by choosing insecure default con-
figurations. 1. Roy Hills, NTA Monitor Ltd. (2005, January). Common VPN Securi-
ty Flaws. http://www.nta-monitor.com/
• Customers do not always understand the configuration 2. R. Pereira and S. Beaulieu, Extended Authentication within ISAKMP/
options as they are often difficult to understand by the Oakley (XAUTH), December 1999.
end-user not privy to the technical intricacies. The VPN 3. Bui, T., Prakash Rao, S., Antikainen, M., & Aura, T. (2019). Client-
services do not offer sufficient guidance as to what con- side Vulnerabilities in Commercial VPNs. ArXiv:1912.04669v1, 1–
figurations are potentially secure. The documentation may 12. https://arxiv.org/abs/1912.04669v1
be exhaustive but not concise with little guidance. The
4. Mocan, T. (2020, September 2). The Top 8 VPN Security Risks (What
to Look Out for). CactusVPN. https://www.cactusvpn.com/vpn/vpn-
security-risks/
5. Bogner, E. (n.d.). Top 5 VPN Security Threats | Pipeline Magazine |
Security and Assurance. Pipelinepub. Retrieved April 15, 2021, from
https://www.pipelinepub.com/Security-and-Assurance/VPN-security-
threats
6. Monga, D. H. (2017). An approach to Virtual Private Networks and
security. International Journal of Advanced Research in Computer
Science, Volume 8(No.5), 1–6. https://www.ijarcs.info
7. Symanovich, S. (n.d.). What is a VPN? Norton. Retrieved April 23,
2021, from https://us.norton.com/internetsecurity-privacy-what-is-a-
vpn.html