search menu icon-carat-right cmu-wordmark

VPN - A Gateway for Vulnerabilities

Virtual Private Networks (VPNs) are the backbone of today's businesses providing a wide range of entities from remote employees to business partners and sometimes even to customers, with the ability to connect to sensitive corporate information securely. Long gone are the days of buying a leased line or a dedicated physical network (or fiber) for these types of communications. VPNs provide a simple way to take advantage of the larger public internet by creating virtual encrypted communications. However, in recent months a number of VPN vulnerabilities have been discovered and are known to be actively exploited (Cybersecurity Requirements Center Advisory), putting at risk what was once considered the most reliable and trusted way to access sensitive corporate resources. In this blog post, I hope to explore the path that brought us here and highlight some recommendations that will hopefully guide the various next steps needed for secure remote network access to various partners.

VPN are a Must for Today's Enterprise

Many businesses today are physically dispersed around the globe with operations that work around the clock. Remote locations range from a single employee to larger branch offices. Communications between these locations carry sensitive business data, such as business Intellectual Property (IP), employee's Personally Identifiable Information (PII) and sometimes even Personal Health Information (PHI). Business also have business partners and contract employees who are constantly exchanging information to perform their various business functions. VPNs provide much needed productivity enhancements extending internal tools such as Enterprise Resource Planning (ERP), Human Resource Information Systems (HRIS), chats, audio and video conferencing, and a plethora of other collaboration tools. As far as cost, VPN reduces the need for travel, special meeting places, conference rooms and even entire office buildings. Some large corporations have reported an annual savings in productivity due to remote employees--for example, Cisco reported a savings of $277 million. Cisco employees who participated in the company's survey also reported improved timeliness and quality of work, as well as an improvement in their quality of life (Cisco Press Article).

VPN == Secure

In a recent Ponemon Institute research report, "2018 State of Cybersecurity in Small and Medium Businesses," business professionals ranked VPN as #4 out of the 20 most essential security technologies (Ponemon 2018 State of Cybersecurity Study, page 22). Apart from the costs saved, VPN is an important privacy and security prerogative for any organization. From small businesses to large corporations, all have information that they need to protect and selectively share with partners and employees. This has become the default job description for the VPN. There is no other security device in the enterprise that can perform this role and provide the required privacy and security of communications. Many of the VPN appliances and VPN software products provide capabilities such as context-switching, virtual network mapping and Role Based Access Controls (RBAC) inherently. Even the recent proposals in IETF and much of research work in IEEE computer privacy and security have been considering the standardization of the way VPN provides security for today's digital data with granular role separations (RFC2764, Xu, Bo, Shu-qin GUO, and Min-fei LU. "Application of access control model based on expand RBAC to SSL VPN system [J]." and Journal of Zhejiang University of Technology 2 (2011). Bendong, Xiong Shufeng Zhou. "Application of Role-Based Access in the SSL VPN [J]." Computer & Digital Engineering 8 (2011)).

In general, corporations and industry seem to have considered VPN as the defacto way to provide secure access to various entities. This has made very large corporations depend on VPN not only as the entry point but also as the very final checkpoint for security. In fact, newer VPN appliances nowadays provide the capabilities of a rule-based firewall and the ability to use virtual routing (MPLS Multi-Protocol Label Switching) making it very convenient to depend entirely on these devices as the combined networking and security gear to provide secure access to a large variety of needs.

SSL VPN a New Way to Introduce Old Problems

Traditionally, VPN employed specific protocols (e.g., Internet Protocol Security (IPSec)) and either hardware or software devices to enable trusted communications using the public internet. Starting around 2005, the ubiquitous encryption technologies SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) were introduced into VPN products. These newer protocols, inherently present in modern browsers, make it easier for large corporations to adopt VPN with a simpler on-boarding process bypassing cumbersome provisioning and installation of traditional VPN software. The SSL VPN design allows for both client and clientless implementation, enabling users to seamlessly work remotely. A number of vendors also find the SSL VPN technology to have a quick time-to-market; this is due to the large number of resources allowing architects, developers, and designers to quickly bring many of the capabilities requested by the customers into production.

While SSL and TLS have brought a great amount of privacy and security into the market, they have not been without growing pains. The problems of using SSL and TLS vary from incorrect implementations to the inherent limitations of the chosen protocol. As computing power has increased, it has also become evident that legacy implementations can be easily broken with modern computing power (using GPU's to attack RC4). In fact, the success of various attacks on TLS and SSL was so prevalent, that IETF even published a Request for Comments (RFC) "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)."

The adoption of SSL into VPN has had its own growing pains as well. In 2009, Cisco released a number of updates to its Adaptive Security Appliance (ASA) platform against vulnerabilities in cross-site scripting (CVE-2009-1201), HTML rewriting bypass (CVE-2009-1202) and authentication credentials theft (CVE-2009-1203). These were well-known problems in web servers and web browsers that were mitigated in the past, but cropped up again in SSL VPN implementations. In 2018, Cisco released another advisory that continued to reveal these grim security issues with "no workarounds but upgrade" - Cisco Advisory 20180129-asa1. This story continued into 2019, with a variety of vendors, Palo Alto's SSL VPN, FortiGate VPN, and Pulse Secure VPN, releasing their own advisories due to critical vulnerabilities in their devices. These were prompted due to the discovery of a number of vulnerabilities in these VPN products by security researchers Orange Tsai and Meh Chang from the DEVCORE team. In fact, these researchers presented some of their findings in BlackHat 2019 conference revealing the fact that more than 200 high severity Common Vulnerability Exposures (CVEs) were assigned to major VPN products just in the year 2018 (Infiltrating Corporate Intranet like NSA, slide 20) . Inherent secure designs that were implemented in webservers to protect using "zones" (same origin policy) were absent in a variety of SSLVPN implementations (VU#261869). Attacks such as cross-site scripting can also be performed against VPNs and be used to steal credentials or active sessions (see CVE-2017-14186 for example). As vendors scrambled to put out patches regularly for VPN products, they soon realized that the adoption of patches into VPN by their customers is not that simple.

VPNs Have No Scheduled Downtimes, Therefore No Patching

Many of the IT services, such as webservices and email servers, have scheduled downtimes announced and expected by end users of large enterprises. However, there is no such luxury of downtime afforded for VPN servers. For example, both Pulse Secure and FortiGate SSL VPN announced critical vulnerabilities around the end of April 2018 and patches were quickly released by the vendors. However, even by August 2019, over 50,000 Pulse Secure VPNs and 480,000 FortiGate SSL VPNs were still found vulnerable and accessible over the Internet (Infiltrating Corporate Intranet like NSA, slide 21). The team from Bad Packets observed that around 14,500 Internet accessible VPN devices were vulnerable to one specific vulnerability, CVE-2019-11510 (Over 14,500 Pulse Secure endpoints vulnerable). This was more than 3 months after the patch was released by the vendor. This delay can be attributed to the fact that VPNs are rarely patched as they are expected to be operational at all times. In general, patching is difficult and critical patches take an average of 34 days to apply after the vendor provided patch is released (It Takes an Average 38 Days to Patch a Vulnerability). Those numbers are likely to be worse for equipment such as VPNs due to their critical role in the organization to provide continued connectivity.

VPN is Not a Forgotten Target for the Adversary

Unlike your security and patch management team who struggle to patch your VPN, mainstream hackers target VPN regularly. In February of 2019, Talos Intelligence published an article on "DNS Hijacking abuse" in which they observed "state-sponsored" attacks using DNS and targeting VPN as a prime method to steal credentials and compromise a number of Saudi Arabia's top-level domains (.sa). In this case the vulnerability was not in the VPN itself, but the VPN was targeted as the right place to find entry points into an enterprise. More recently in September 2019, Airbus was informed that sensitive data was stolen through their supplier Expleo using their VPN connection. When referring to this attack, an Expleo technical source commented that "it was very sophisticated and targeted the VPN which connected the company to Airbus." The attack provided the hackers with a stable foothold using VPN. This supply chain attack began with the VPN as the target to compromise a large aviation corporation like the Airbus SE (Airbus hacked through supplier VPNs).

The US National Security Agency (NSA) released an advisory in October 2019 (Cybersecurity Requirements Center Advisory) pointing out "Advanced Persistent Threat actors actively exploiting VPN vulnerabilities" - referring specifically to the three large vendors: Palo Alto, Pulse Secure and FortiGate. NSA advisories like this one are rare; speaking on a different recent vulnerability NSA press officer Donna Lohr said the "NSA would like the community to understand that there is always sound reasoning behind the timing of our advisories; they should be viewed as a call to act." (Cyberscoop NSA warning). VPN continues to be an attractive attack vector for attackers to access the internal networks of large corporation and help in their attempt to gain persistent access to sensitive corporate resources. Many organizations that do not include VPN in their threat model are likely to find out how much their VPN is the target only post a cybersecurity incident.

The VPN Way Forward

This revelation brings me to a point where I can identify some of the VPN best practices and recommend that we build on them to future-proof corporate VPN servers and VPN systems from attacks. There are a number of recommendations captured in NIST 800-77 and NIST 800-113 that deal with both traditional VPNs and the newer SSL VPNs. I would like highlight a few relevant recommendations with details here for enterprises that ought to plan their environment to be resilient to VPN attacks.

1. Implement and Ensure Trust Models in SSL VPN Scenarios - Especially Clientless Implementations

SSL VPNs provide a convenient entry point into the enterprise, but as mentioned above, they lack many of the security concerns that have plagued various TLS implementations. For example, in a recent vulnerability discovered in Pulse Secure VPN, an old directory traversal vulnerability from 1999 was still being exploited. In this case, the pre-authentication SSL session did not provide enough restrictions from access of sensitive resources. This shows how SSL VPN has repeated many of the security mistakes seen in early webserver implementations. Another example would be the vulnerability "Clientless SSL VPN products break web browser domain-based security models" published by CERT (VU#261869). In this Vulnerability note, there were a number of vendors shown to have not ensured trust models of domain-based security into their products. These best practices are to be adopted by the SSL VPN vendors and enforced using proper configuration by the enterprise to ensure services have sufficient protection from well-known HTTPS attacks.

2. Embed VPN as a Critical Attack Vector in Your Threat Map and Your Ongoing Security Monitoring

The full lifecycle of VPN adoption (from design, implementation, ongoing monitoring into end-of-life) should be a critical consideration for your enterprise's security architecture and security monitoring teams. For example, VPN placement is a crucial decision that should be reviewed by your security architecture team (see recommendations in NIST 800-133 Section 4 "Architecture"). Teams that do penetration testing and threat modeling should look at VPN as an important part of your enterprise's attack and threat vector. Even when VPNs are placed securely in the enterprise's demilitarized zone (DMZ), they sometimes go virtually unnoticed or unmonitored by many Security Operations Centers (SOCs). Your SOC should be very familiar with VPNs and modeled response plans for scenarios such as VPN compromise. These clear processes should be in your SOC's handbook to know how to operate when an alert is confirmed that your VPN is compromised. In industries such as Critical Infrastructure Sectors, corporate VPN has spelled out by ICS-CERT as a critical consideration in Cyber Vulnerabilities assessments.

3. Design VPN High Availability and Redundancy, Moving from Continuous Monitoring to Continuous Patching

NIST 800-113 section 3.3.3 specifically captures high-availability considerations for VPN. In many large organizations, VPN cannot be patched or repaired due to the lack of high availability in the VPN setup. Although VPN products provided by many vendors come with preset capabilities for running VPN in high-availability modes, they are not configured and used in a way that it is possible to do patching and maintenance. The newer VPN products also provide the ability to operate VPN in active/active configurations allowing organizations to patch and restore VPN service with no downtime and even provide live migration of active sessions. This crucial design in the VPN architecture gives Information Technology (IT) teams the ability to pursue patching without hesitation when vulnerabilities are announced by the vendor. VPN vendors are also recommended to continuously move their devices into a live-patching capability to minimize downtime and be more effective in ensuring ongoing security of this critical system for the enterprise.

Looking Ahead - High Assurance and More

Forbes recently published a post on "The Future of VPNs," in which they highlight the trends in VPN from cloud to consumer drivers making VPN "advance across the board." As the article highlights, the VPN trends follow recent computing trends that impact organizations from very small businesses to large corporations interconnected through the Internet. Many systems from entertainment/gaming to mission-critical infrastructure all take advantage of the Internet while they depend on their private communications through a VPN of some sort. Today's critical day-to-day transactions from credit card processing to smart grid switching systems depend on secure communications enabled by VPN to provide reliable (atomic) transactions that will complete accurately within guaranteed time windows. VPN security is crucial for us, enabling a secure yet cost-effective way to use the Internet for many essential business needs from the individual to the enterprise.

About the Author

We're redesigning the blog—you can help by telling us about your blog experience.
I'll do it No thanks