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