2 Reasons Why Your VPN Solution is Loved by Hackers

VPN Technologies have been around for many years. IPSec VPN and later SSL VPN are very popular for providing that critical remote access to your applications. While the way your users access the applications has evolved over the years – with smart phones, tablets, etc. – the VPN technology has not changed much. And behind the VPN, even the way you host your applications has evolved in the last few years – with the use of SaaS applications, PaaS and IaaS to host your own custom applications or even a managed Private Cloud – instead of having everything on-premises. VPN solutions have just morphed from being physical appliances to being virtual appliances, with very little changes internally, to address this move of applications being served in these newer ways. I will not go into the many security issues that have been reported on, as they are all very well documented based on the different sets of exploits that are present, based on vulnerabilities in specific systems, and instead focus on the two main reasons that VPN’s are the soft targets.

Reason #1: Full Network Access
VPN’s were created to ensure data in transit is encrypted to achieve the Confidentiality and Integrity pillars. However, once inside the network, there was (and still mostly has) no encryption on the data in transit and the only security was (and still is) a network firewall and probably an IDS / IPS. Hence, if a user is authenticated on the VPN, he has full access to the network – same as any user that is physically present in the office. The only thing that prevents a VPN user from accessing any application, network device, security device, AD server, file server or a database is the password. Why so? You ask… It’s elementary dear Watson… the network firewall is configured to allow all VPN IP addresses to the entire network since there is no way of controlling “User access” based on the dynamic IP address his / her laptop / mobile device will be assigned.

This is great news for the Hacker! The attacker just has to send an email to your remote user (employees, management (loved), IT staff (most loved), contractor, business partner, vendor etc.) with a nice PDF or Word document or a fancy presentation explaining the latest trends in hiring, salary reports etc. Such reports are oh-so-tempting to look at and gain useful info that it’s certain that your user almost always opens the email and goes on to open the document too. Result – Game Over! The attachment, laced with an off-the-shelf malware, helps the attacker get full access into the laptop or the mobile device and then gains full access to the entire network the moment the remote user logs into the VPN.

Reason #2: Unauthorized devices
Many best practices or compliances require companies to check the endpoint / user’s devices prior to allowing VPN access, to have the latest software patches, anti-virus updates and so on to prevent malware from entering the network. Many or almost all VPN solutions worth their salt provide this feature to different degrees. Further, most VPN’s also provide the ability to push client certificates to authenticate the device. However, I have rarely ever seen companies using this feature (due to various reasons), and instead use passwords (mostly), and few add the use of 2FA (using a soft / hard token or an OTP) to authenticate the user. 2FA or MFA is a very touchy subject – required or mandated by compliance and security, but hated by the users.
These checks look great, and does improve security significantly – however, the device checks, device authentication (using certificates), and the user authentication are not tied together properly – meaning the authorization systems do not check that the device (say Laptop with Serial 82AF4B) is registered to the user (say john.doe@acme.com) and only that user (john.doe@acme.com) can be authenticated from that device (laptop with serial 82AF4B). This gap is exploited by the hackers since, they can still steal the password or OTP and continue to work from their own systems till they get their foot inside the door. Once inside, the attacker exploits many other ways to come in and go out freely, without the VPN itself.

The Complete Picture

The inability to limit network access via VPN and the inability to tie the device and the user is a dangerous combination. Not only is the device not tied to the user, even client applications or tools used by users are not restricted from accessing the VPN. This combination makes the life of the hacker easier since, he/she just has to compromise the endpoint. Game Over! (I know… I said it before ). The attacker can now move into the network and become an insider, and the average time to find such a breach is many months if not years*.

The Obvious Solution

Do not give full network access to your VPN users. Simple. Yes, simple to say and difficult to implement. Hence, you need to find VPN solutions that can help you configure access controls based on the user / user groups and roles to the specific applications or group of applications – i.e. John.doe@acme.com gets access only to CRM, HRMS and the SharePoint over port 443.

Register devices the user can use to connect to the VPN – There are very few solutions out there that can tie the device and the user together to gain the huge benefits of this combination. The combination of device authentication and restricting user login to only the device owner creates an MFA method which is intuitively simpler to implement and manage. This method involves lesser or no changes for the user workflow, giving the added benefit of easier user adoption with the resultant higher level of security. Result – john.doe@acme.com can access CRM, HRMS and SharePoint on port 443 only from his registered devices.
Further, whitelisting client apps or tools used by users on their devices (laptops, mobile devices) that are allowed to access the VPN tunnel, is a very strong control that can prevent malware from spreading from exploited endpoints, on to your data network. This will prevent malware from using the VPN tunnel, ensuring, only the traffic from authorized apps on a registered device used by an authenticated user is coming into your network.