At this week's Black Hat 2010 in Las Vegas, NCP engineering is releasing a new white paper that sheds light on common VPN vulnerabilities that put organizations at risk. It's prudent to occasionally survey the threat landscape with a fresh lens because while VPNs aren't new, the threats they combat are constantly changing and require regular monitoring and security updates to stop. The white paper, Remote Access—Attack Vectors: Threats, Findings & Remedies, chronicles some of the major recent breaches and gleans lessons for all organizations that allow remote access to their network. For example, the infamous breach at Heartland Payment Systems in 2008 occurred, in part, using a VPN. This was followed by incidents at Google earlier this year and a major breach at Energy Future Holdings that caused $26,000 in lost business.
Vulnerabilities in VPN can often be found on vendor support sites, as well as security notification bulletins and the US NVD. Vendors will notify customers of the vulnerability after a fix has been created, but advance notice is sometimes possible by monitoring disclosure and security forums. Advance notice is often useful when vulnerabilities are urgent or critical in severity and will require planning or immediate attention. Although the vast majority of breaches involve management issues, design and quality are still very important considerations. Both design and quality are among the best ways to differentiate VPN products and solutions. The following sections detail several vulnerabilities in quality and design.
Information leaks
After the installation of VPN software, network traffic might still exit through other interfaces. A high-profile vulnerability was announced in 2010, caused by the combination of IPv6 and PPTP-based VPN, and exposed users' IP address, MAC address and computer name. The Findnot.com VPN in 2006 was found to redirect traffic unencrypted to the public net when its servers were congested, without notifying its users. A similar issue may occur after the installation of multiple VPNs that do not work well together and therefore fail to isolate traffic, causing information leakage across the VPNs. This was the case with Cisco VPNs that had a bug when processing extended communities. Cisco's VPNs incorrectly used a corrupted route target (RT) to forward traffic, causing a leak—from one VPN to another. The solution to these leaks, aside from vendor patches, is hardening a system specifically to prevent route failures, DNS leaks and IP leaks outside a VPN connection, even after the preferred VPN connection fails.
Another recent vulnerability in this area is related to clientless VPN products. These devices retrieve content from different sites and then serve the data so it appears to be from the SSL VPN. This circumvents same-origin restrictions. A same-origin policy is designed to enforce trust domains and block malicious scripts. The SSL VPN design breaks this by trying to present remote site data with different domains as its own. An attacker with a malicious page viewed through a clientless VPN thus can hijack a user's session or capture keystrokes. The solution to this is to configure VPN clients to access only trusted domains.
IKE aggressive mode (AM) has a vulnerability that can lead to a serious leak of information. Attackers are able to extract password hashes and attempt password brute force methods due to different responses returned for valid and invalid usernames. This is prevented by configuring devices to deny and never initiate any IKE AM connections.
Caching and duplication
VPN client programs often store authentication credentials (e.g., username and password) to make network access more convenient. This may even be a default setting in some VPN products, making sensitive data extremely vulnerable. An attacker may search for cached credentials to exploit a VPN, which can be as simple as looking for plain-text passwords in memory or the registry. A 2007 vulnerability with the CheckPoint VPN-1 SecuRemote/SecureClient AutoLogin feature, for example, had to do with authentication credentials stored in the Windows registry (subkey ‘Credentials' in HKLMSoftwareCheckpointSecuRemote). A local user could easily access the credentials to authenticate to a VPN as a target user. A similar problem is that some clients use non-encrypted (obfuscated) passwords, which are very easy for attackers to find. Likewise, sensitive data may be left behind on a system after a VPN session ends. Passwords should be protected properly at all times, and the cache of a client that has accessed a VPN should be cleaned after every session.
Duplication or replay of VPN traffic also continues to be an important vulnerability. Data may be encrypted in communication and signatures used to authenticate every packet, but a motivated attacker may still perform a replay with success. VPN implementations of IPsec apply a sequence number to packets, using the Encapsulating Security Payload (ESP). A table of these are maintained by the destination host and then used to monitor for duplicate packets and invalid traffic. This system works only when the sequence number is also encrypted or signed. Otherwise, it is possible for an attacker to monitor and figure out the sequence patterns.
Both of these vulnerabilities demonstrate the importance of quality in VPN products as well as the need for careful design.
Denial of service
Packets that are malformed or those that do not conform to RFC specifications, can cause overflows in buffers and terminate services by exhausting resources. This affects a VPN like any other network system.
SSL-based VPNs, for example, may be based on a standard TCP connection. They can be configured to use UDP instead, perhaps to get higher performance. The use of UDP, however, makes blocking and detecting denial-of-service attacks much more difficult. UDP also makes it very easy to detect a VPN on a network (TCP-based traffic is more easily hidden—traffic on port 443 looks like HTTPS). One attack on Nortel VPNs was due to a malformed ISAKMP header that was undetectable by IDS because it was so similar to a standard IKE header. The hidden attack packets would cause an immediate crash that would either force the device to reboot (five-minute outage) or cause it to hang indefinitely. Another view of denial-of-service is resource exhaustion by a flow of many packets that cause a VPN server to run out of negotiation slots. This makes a server unable to process legitimate connections. The Cisco VPN 3000 was found to be vulnerable if bad traffic was sent on a particular port, in this case, port 80. However, only a short stream of fewer than 50 packets was needed to hang the device.
Ultimately, while poor management continues to be a leading cause for VPN breaches, design and quality shouldn't be ignored. After all, manageability is often in your hands, but design and quality flaws often don't emerge until it's too late.
