MTI has over 18 years’ experience in the IT security industry and regularly work with public and private sector organisations across UK, France and Germany. We help customers maintain the highest levels of data and system security.
As a result, our highly experienced testing team has first-hand knowledge of the most common security vulnerabilities found in today’s businesses.
The below is blog 5 in a series of 8 that identifies the most common security vulnerabilities that we have experienced first hand.
Vulnerability #5: Virtual Private Networks
A Virtual Private Network (VPN) is typically one of two types: a Site-to-Site VPN or a Remote Access VPN.
A Site-to-Site VPN links two physical sites together, usually different offices or a partner organisation, to provide access to internally hosted resources. This setup is usually static, and once configured on both ends of the VPN it does not change.
A Remote Access VPN is typically an SSL based VPN that allows users to connect to the internally hosted resources, by either logging on to a VPN in their web browser or via a client that is installed on a laptop.
- Site-to-Site VPNs
There are inherent risks in both types of VPN, and the methods used to test them are very different:
Aggressive Mode / Main Mode
When establishing the VPN tunnel, a Security Association (SA) is established, which is used by the VPN devices to confirm the identity of each VPN endpoint, agree on a set of encryption and integrity checking protocols, and to authenticate to each other. A VPN device can be configured to do this using one of two ways – Main Mode and Aggressive Mode. When Main Mode is used, a Phase 1 Security Association is established, which serves to ensure that any authentication data, such as a Pre-
Shared Key, is only ever transmitted over an encrypted tunnel.
If Aggressive Mode is used, then the VPN endpoints will not establish this Phase 1 tunnel and will send an encrypted version of a PSK over a clear text connection to anyone who asks for it. Aggressive Mode is usually a quicker and less intensive way to set up the VPN; however, Main Mode is a much more secure method.
- Is Pre-Shared Key (PSK) in Use?
When establishing the VPN tunnel, both ends need to prove their identity and authenticate to each other. The options for this are to use a PSK that is identical on both ends of the VPN tunnel or to use a certificate; however, due to the ease of setup, using a PSK is by far the most common option. In certain vendor VPN devices, if Aggressive Mode is used, it can be possible to obtain an encrypted version of the
PSK and to then conduct an offline cracking attack against it. If this can be cracked then it could be possible to establish a “Phase 1” VPN connection to the endpoint and attempt to gain access to the internal hosts.
- Are Access Controls Implemented?
The upside of a Site-to-Site VPN is that the IP address of the device at the other end of the VPN needs to be known in advance; therefore, it is simple to set up an Access Control List (ACL) that only permits this IP Address(es) to access the VPN device, usually on port UDP:500 (ISAKMP). This, in turn, prevents anyone else from connecting to the VPN service and attempting to conduct any attacks, as unless they are using a permitted IP address the device will ignore the traffic.
- Transform Sets
Remote Access VPNs do not suffer from the same issues that Site-to-Site VPNs do and need to be tested in a completely different way.
It is still very common for a VPN to only require a username and password before granting access; often using the user’s Active Directory credentials. This can make it very easy for an attacker to gain access to internal resources if they can obtain or guess a valid set of credentials. During our tests we typically phone up users in a social engineering attack and pretend to be a member of the IT staff who needs to know their password so they can “upgrade their account” and it is surprising the number of times this works. We also do this attack the other way round and contact IT posing as a user who has forgotten their password and asks for it to be reset over the phone, again this has a remarkably high rate of success during our tests. Username/password combinations are also vulnerable to the tried and tested password brute force attack and rely only on a user choosing a secure password. For these reasons, all VPN authentication should use Two-Factor Authentication (2FA).
This means that a user must enter their username and password and then enter a random token code that is either obtained from a 2FA fob or sent to them in a text message; without this, an attacker who knows a valid username and password is still not able to connect to the VPN. There are still attacks that can be used against 2FA but these are much harder to carry out and have a lower chance of success.
- Host Checking
Host checking requires any device that is connecting to a VPN to meet a set of predefined requirements, such as having an AV enabled, having Operating System patches applied and being part of the corporate Active Directory domain. One of the best methods of protection that is often overlooked is having a check to make sure the device is on the corporate domain and is authorised to connect to the VPN. With this enabled, even if an attacker obtains a user’s username, password and 2FA fob unless they also have access to a corporate laptop that is part of the Active Directory domain, they still cannot connect to the VPN. MTI has been in this situation several times in the past where we have obtained a user’s username and password, orchestrated a scenario to make IT staff alter the phone number that a user’s 2FA code will be sent to, but have still not been able to connect to the VPN as we didn’t have access to a laptop that was authorised to connect. It is easy to overlook the benefits of host checking but they really are a formidable defence to deploy on a VPN.
Best practises dictate that a “Walled Garden” approach should be used for a VPN environment. Generally this means that when a user is connected to a VPN they should not have full unfiltered access to the entire internal network, but instead, only services that a user requires should be exposed to them and ideally from a segregated network / DMZ. This will then significantly limit the extent of a compromise should an attacker gain access to the VPN. This is the subject of a very useful guidance document provided by the National Cyber Security Centre (NCSC) and can be downloaded by anyone here. the phone, again this has a remarkably high rate of success during our tests.
Work with a testing service provider that provides technical build reviews, VPN testing services as well as provides ‘social engineering’ tests to expose any procedural or human vulnerabilities.