This chapter is from the book
This chapter is from the book
This chapter is from the book
5.2 PPTP
We studied the tunneling aspects of PPTP in Chapter 4, where we viewed it as a type of remote access server that doesn't require expensive capital expenditures on modem banks and telco lines. As we mentioned, users view PPTP primarily as a VPN technology—they perceive its main benefit as secure communications. In this section, we take a brief look at PPTP's VPN properties.
If we reexamine the PPTP message types, we see that none of them deals with encryption or authentication. That's because PPTP really is a tunneling protocol, not a VPN protocol. PPTP relies on the underlying PPP protocol for its encryption and authentication services: In practice, that means Microsoft's Microsoft Point-to-Point Encryption (MPPE) [Pall and Zorn 2001] and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) [Zorn and Cobb 1998].
At first glance, these seem like reasonable cryptographic protocols. MPPE uses RC4, which we saw and remarked on in Chapter 3. MS-CHAP is Microsoft's version of PPP CHAP, a typical challenge/response protocol. Unfortunately, Microsoft's implementation of these protocols has several problems.
The MS-CHAPv1 protocol has several weaknesses that make recovery of the user's password comparatively easy using a dictionary attack. MS-CHAPv2 fixes the worst of these weaknesses but is still susceptible to an attack where a dictionary of N trial passwords can be checked at a cost of about N/216 attempts and some precomputation.
The version of MPPE used with MS-CHAPv1 has a fatal flaw: It uses the same RC4 key for both the PAC and PNS, resulting in reuse of the key stream. As we saw in Chapter 3, this leads directly to the recovery of both plaintext streams. With MSCHAPv2, Microsoft changed MPPE to avoid the key stream reuse, but serious problems remain. The main problem is that the RC4 session keys are derived in a deterministic way from the user's password and information passed in the clear. Thus, the keys have the same entropy as the password instead of the 128 bits that a randomly generated session key would have. Because user passwords are generally low entropy and, with MSCHAP, susceptible to a particularly effective dictionary attack, PPTP cannot be considered to have robust encryption.
Finally, there is no per packet authentication. This means that various bit-flipping attacks are possible on the encrypted data.
We can "flip," or change, any bit without detection when using RC4 and similar stream ciphers. If we know that a certain bit in a message is important for some reason, we can easily change it. Suppose, for example, that we know that the most significant bit of byte X in a message enables certain features that make it more difficult for an attacker to compromise the security of the system. If we know that the bit is turned on, we can turn it off by merely exclusive-ORing 0x80 with byte X of the ciphertext. Note that we don't have to know the encryption key or even the plaintext value of byte X to do this: only that we want to change the most significant bit. It's easy to see how we can generalize this to alter larger units of data if we know their plaintext values and positions in the data stream.
The PPP control protocols, such as LCP, are particularly vulnerable, and it may be possible to convince the client and server to use the older MS-CHAPv1 protocol, resulting in fairly easy user password recovery and compromise of the RC4 cipher stream.
The fact that MS-CHAPv2 considerably strengthened the Microsoft version of PPTP notwithstanding, almost all experts recommend against using PPTP. The specifics of the MS-CHAP and MPPE weaknesses are detailed in [Schneier and Mudge 1998] and [Schneier, Mudge, and Wagner 1999].
The weaknesses we have been discussing are specific to the Microsoft implementation, of course, but this implementation is the preponderant one. Virtually all other PPTP implementations are written to interoperate with Microsoft's, so they are likely to share the same weaknesses.