Written by Jim Anthony on April 17, 2019
Why It’s (Still) Time to Kill the VPN
The recent warning about a security bug affecting several enterprise virtual private networking apps reminds us why VPNs are so vulnerable.
Recently, Carnegie Mellon University CERT Coordination Center issued a security alert warning that multiple Virtual Protection Network (VPN) applications store the authentication and/or session cookies insecurely in memory and/or log files. For traditional VPNs, these cookies can be used to establish a VPN connection from another device -- meaning any cybercriminal with access to the computer, or running malware on the computer, can retrieve credentials and use them on another system to resume the original VPN session without needing to log in. Suddenly, an organization’s internal network, applications, and sensitive data are exposed. Four VPN applications from Cisco, F5 Networks, Palo Alto Networks, and Pulse Secure are impacted and named in the alert.
Why are VPNs still vulnerable?
Traditional VPNs all basically function the same way -- once a user is authenticated, that ‘authorization’ is written to the user’s computer, usually in the form of a unencrypted cookie. If no special precautions are taken that cookie will also exist in memory, which is also normally unencrypted. And, if that laptop is already owned, meaning someone has already deployed malware to it, then that authorization cookie is available to that malware and can be exfiltrated and used to spoof that user’s authorization.
Have a cookie, will travel...inside your network!
Once all of the above happens, an attacker is inside your network. Relatively easily, actually. There are open, listening ports enabling this malicious user to execute the spoof once they’ve gained access to the unencrypted cookie. After the user is dropped off on a virtual LAN (VLAN), the back door is wide open to the entire network thanks to the lack of ephemeral private-user firewalls. Organizations often rely heavily on other technologies to prevent further movement, but in this scenario do not have posture checking and do not have time to live on ‘authorization’ cookie.
A quick fix - but not really
The impacted VPN applications will fix these vulnerability issues. Count on it. They will issue a patch (in some cases they already have) and change the way the authorization cookies are handled. This quick fix might include clearing the memory of the cookie, encrypting the cookie, storing it in a certificate store in the user’s operating system, etc. But is this really a long-term solution? No -- because all of the other issues with traditional VPNs still exist.
There is a long list of architectural flaws with VPNs that won’t go away by simply encrypting the authorization cookie. The concentrator will still be listening on a wide-open port. The user will still be dropped onto a VLAN. The various data centers will still be connected by wide-open, LAN-to-LAN connections, enabling cross-data center lateral movement. They will still use IPSec. Access will still not be tied to a TTL (Time to Live) setting, or posture checking. And the VPN application still won’t support dynamic destinations, or integration with other important business systems.
Long term solutions
To navigate today’s dynamic and complex network landscape, organizations need to deploy a Zero Trust cybersecurity model, leveraging a Software-Defined Perimeter (SDP), which evolved from the work done at the Defense Information Systems Agency (DISA) under the Global Information Grid (GIG) Black Core Network initiative. SDP is designed around the user and addresses VPN’s shortcomings. It is based on a need-to-know model, in which device posture and identity are verified before access to application infrastructure is granted. An SDP dynamically creates 1:1 network connections between users and the data they access. SDP reduces the attack surface in real-time by creating a discrete, encrypted network segment of one, making everything else invisible and inaccessible. A network “segment of one” is an individualized, micro-segmented network tailored for each individual user, device, and session. Finally, SDP is a holistic solution, providing a single secure-access control platform for both remote and on-premise users accessing remote and on-premise resources.
AppGate SDP is not vulnerable the way a traditional VPN is. Its claims and entitlement tokens require authentication with Single Packet Authorization (SPA) and a valid (client) certificate. The SPA key and certificates are securely stored in the OS credential store, as is the device onboarding cookie. And, because AppGate SDP does not work the same way as regular VPNs, we don’t have authentication token and session cookies in the way they do. AppGate SDP ensures we know as much about a user as we can BEFORE allowing them to make a connection to the network.