Vulnerabilities & attack vectors of VPNs (Pt 1)

This is the first part of an article that will give an overview of known vulnerabilities and potential attack vectors against commonly used Virtual Private Network (VPN) protocols and technologies. This post will cover vulnerabilities and mitigation controls of the Point-to-Point Tunneling Protocol (PPTP) and IPsec. The second post will cover SSL-based VPNs like OpenVPN and the Secure Socket Tunneling Protocol (SSTP). As surveillance of Internet communications has become an important issue, besides the traditional goals of information security, typically referred as  confidentiality, integrity and authenticity, another security goal has become explicitly desirable: Perfect Forward Secrecy (PFS). PFS may be achieved if the initial session-key agreement generates unique keys for each session. This ensures that even if the private key would be compromised, older sessions (that one may have captured) can’t be decrypted. The concept of PFS will be covered in the second post.

PPTP

The Point-To-Point Tunneling Protocol (PPTP) was developed in the late 90s by a vendor consortium, including Microsoft and 3com. It was the very first VPN protocol that was supported by Microsoft Windows and even though it is no longer recommended by Microsoft, it is still widely deployed. PPTP’s purpose is to enable secure data transfer from a remote to a private system by creating a secure VPN. Initially it was developed as an extension to the Point-To-Point Protocol (PPP) which allows tunneling of PPP packets through an IP network.
The PPTP standard doesn’t define any security attributes at all. It also doesn’t specify any changes to PPP but rather defines a new way for carrying it. Typical PPTP deployments achieve authenticity and data confidentiality by applying two additional protocols:

• Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2): A challenge-response procedure which provides mutual authenticity.
• Microsoft Point-To-Point Encryption (MPPE) protocol: PPP packet encryption scheme, using RC4 stream-cipher to provide data confidentiality.

Vulnerabilities of PPTP that have been known for a long time reside either in MS-CHAP v2, MPPE or the combination (MS-CHAP v2 derives session keys for MPPE) of both.

Breaking MS-CHAP v2 authentication

Basically MS-CHAP v2 is just a simple challenge-response procedure where authentication works as follows: client and server share a secret that will be concatenated with random bytes (the challenge, generated by the server) and processed by a cryptographic hash function, whereas the output of the hash function is the response. If both parties compute the same response, client and server are mutually authenticated.
Although this might be a pretty simple and, depending on the security of the used hash function, reliable authentication procedure it seems like some Microsoft engineers were bored of its simplicity. Figure 1 shows an overview of the complete authentication process of MS-CHAP v2.

Back in 1999, Bruce Schneier and Mudge revealed some critical flaws of MS-CHAP v2 which have never been fixed. Their research has not only shown that the security of PPTPs authentication and encryption is only as secure as the user password, but also that MS-CHAP v2 authentication can be captured and broken by a dictionary attack. Although one might think people would have avoided PPTP-based VPNs ever since this analysis, PPTP is still widely used.
Most PPTP operators might have thought that their deployments are still secure as long as they choose good passphrases, believing that attackers would have to launch a dictionary attack on the response of the authentication process. But recent research has shown that the complexity of the authentication process can be broken down to a minimum of unknown information.

Figure 2 shows the only unknown information of the authentication process that isn’t sent in cleartext or can be easily derived from something sent in cleartext. This can now be broken down to just a single DES encryption, making this attack more feasible. Detailed information can be found at the CloudCracker blog.
There are two ways to mitigate the impact of this vulnerability:

• Implement PEAP-MS-CHAP v2: The security of MS-CHAPv2 can be extended by implementing the Protected Extensible Authentication Protocol (PEAP). This mitigates the major impact of the MS-CHAPv2 vulnerabilities by encapsulating the authentication data in TLS. Further information and implementation support is provided by Microsoft.
• Implement EAP-TLS: Instead of using the default challenge-response authentication provided by MS-CHAP v2, PPTP can also adapt EAP-TLS. EAP-TLS provides mutual authentication based on certificates, which enforces Man-in-the-Middle-safe configuration by utilizing extended key features of X.509 for certificate validation. But one has to keep the additional complexity in mind which arises as a consequence of deploying a PKI.

MPPE data confidentiality based on password strength

MPPE encrypts PPTP payloads (PPP packets) with a maximum session key size of 128 bit. Even though the RC4 algorithm may theoretically have 128-bits of entropy, the actual user passwords which are used to derive the encryption keys have much less. Therefore confidentiality provided by PPTP respectively MPPE is only as good as the used passwords.
There are some ways that may improve the security of the MPPE encryption in PPTP. They shouldn’t be understood as mitigations (it’s still a pretty weak encryption protocol) but should be considered for essential PPTP deployments:

• Strong password policy: Strict password policies must be enforced to reach a higher degree of entropy. Passwords should at least be 20 characters long, containing lower- and uppercase letters, numbers and symbols.
• Generated passwords: Generate strong passwords that comply with the policies – don’t let users change them (to possible weaker ones).
• EAP-TLS instead of MS-CHAP v2: As described before, EAP-TLS implements a certificate-based mutual authentication for PPTP. Besides the generally known advantages of certificates, this may provide a higher entropy for the derived session keys (used in MPPE).

Integrity checking?

There’s none. PPTP has no capabilities of authenticating ciphertext. Combined with the RC4 stream-cipher it is vulnerable to a bit-flipping attack. Although this won’t reveal any plaintext information or key material, an attacker could alter messages by flipping bits, resulting in a different output text after decryption. Of course this sort of attacks might be detected or prevented by higher level protocols, e.g. by checksums or error codes.

PPTP conclusions

Issues with the MPPE protocol can’t really be fixed, because the whole PPTP protocol is based on this approach. Also integrity checking can’t be turned on, because it’s not implemented. PPTP is a broken-by-design protocol that should not be used anymore. Therefore switching to another protocol should be considered. Alternatives like L2TP inside of IPsec, SSTP or OpenVPN provide way better security enhancing capabilities like strong authentication and encryption, integrity checking and data origin authentication.

IPsec

IPsec is a protocol suite that is capable of ensuring confidentiality, integrity and authenticity of IP traffic. Although it was initially developed to just secure data that is sent over the Internet, it can also secure local traffic e.g. securing backbone communications. IPsec defines two protocols which can achieve different security goals:

• IP Authentication Header (AH): AH provides data origin authentication and nonrepudiation. It encrypts nonvolatile IP header fields and computes a message digest of the IP packet (header and payload data). After the message digest is computed, an encrypted AH header is inserted between the original IP header and the payload data of the packet. This encrypted header contains the former encrypted data and message digest.
• Encapsulating Security Payload (ESP): ESP provides various security services such as data origin authentication and connectionless integrity, but is mostly known for providing data confidentiality (AH can’t provide data confidentiality). Confidentiality is achieved by encrypting the data payload (in Transport Mode) or by encrypting and encapsulating the entire IP packet (in Tunnel Mode). ESP supports the use of the symmetric encryption algorithms DES, 3DES (Triple-DES) and AES. Message digest codes can be computed by either HMAC-MD5 or HMAC-SHA1.

In some situations either one of them may fulfill security needs, but to achieve a secure VPN setup both protocols can be combined. This will not only ensure confidentiality and data origin authentication of the payload data due to the use of ESP. AH will additionally secure the header data.
While the AH and ESP protocols are used to secure data sent over the wire, IPsec adopts an additional protocol for key-management: Internet Security Association and Key Management Protocol (ISAKMP). The main part used by IPsec is Internet Key Exchange (IKE), a sub-protocol that is responsible for peer authentication.
As the detailed functioning of IKE is not in the scope of this post, further information can be retrieved from the corresponding RFCs. To provide a better understanding of the following vulnerability, we’ll focus on phase one of IKE where the following two modes are supported:

• Main Mode: The secure mode which should always be used. Using this mode will mitigate the vulnerability presented in the remainder of this post.
• Aggressive Mode: A shortened authentication process which will be explained in more detail in the following.

IKE aggressive (a.k.a. vulnerable) mode

While IKA Main Mode sends six packets in total to complete the authentication process, Aggressive Mode reduces the same authentication to just three packets. The authentication process may be simpler and quicker but unfortunately this introduces a critical security flaw. We released a short overview about pre-shared key cracking when using IKE Aggressive Mode. Further explanation as well as a proof-of-concept can be retrieved from this document.
Unfortunately some vendors shipped VPN appliances with Aggressive Mode configured as default. Running insecure default configurations is a common reason why this vulnerability appears in the wild over and over again.
The following controls should be considered to mitigate this vulnerability:

• If pre-shared keys are unavoidable, strong passphrases should be enforced (at least 20 characters, lower- and uppercase, numbers and symbols). This situation might occur if:
  ¬    Your appliance doesn’t support any other authentication process.
  ¬    There is no network-budget.
  ¬    You don’t want to maintain a PKI.

• Don’t allow dynamic IP addresses in VPNs and don’t use dynamic crypto maps.
• Don’t use pre-shared keys for authentication (even with routers). Switch to something more reliable like smartcards, hardware tokens or X.509 certificate based authentication.
•  Disable Aggressive Mode if possible/supported.

The second part of this post is scheduled for next week, so stay tuned.

Regards,
Niklaus