Is PPTP Safe?

Do Microsoft's hotfixes make PPTP secure enough for your network?

In the December 1997 issue, Zubair Ahmad considered the question "Is RAS Safe?" He determined that RAS was secure because it uses industry-standard security protocols and encryption algorithms. However, in the past year, users and intruders have revealed serious flaws in Microsoft's implementation of PPTP, RAS's VPN component. (For an introduction to PPTP, see Douglas Toombs, "Point-to-Point Tunneling Protocol," June 1997.)

Distant rumblings of the coming storm began in April 1998, when users posted questions such as "Is PPTP secure?" on security forums, followed by descriptions of possible VPN vulnerabilities. In June 1998, Counterpane Systems released "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP)" (http://www.counterpane.com/pptp-paper.html), a formal analysis that demonstrates PPTP vulnerabilities. Later that summer, L0pht Heavy Industries (LHI—http://www.L0pht.com) released Readsmb (a program that comes with L0phtCrack 2.0), a sniffer that can derive users' passwords from the challenges and responses that pass across most Windows NT networks. (For more information about Readsmb, see "Protect Your Passwords," October 1998.)

At the same time the security community was revealing these vulnerabilities, Microsoft was developing updates to the PPTP specification and subsequent code releases. By August 1998, Microsoft had released three PPTP hotfixes and other updates to DUN.

In the past year, keeping up with intruders' claims and Microsoft's responses has been a confusing ordeal that keeps alive the question of whether PPTP is secure. I'll help answer this question by detailing PPTP's weaknesses and discussing how well Microsoft has addressed these weaknesses with the cumulative enhancements in the PPTP3 Update. Also, I'll show you where to find Microsoft's security enhancements.

Filling the Holes
Users and intruders have revealed several PPTP weaknesses that compromise your systems' security. Microsoft addressed these vulnerabilities with various security updates and hotfixes.

Password hashing and the Microsoft Challenge Handshake Authentication Protocol (MSCHAP). In "Protect Your Passwords" (October 1998), I discussed how Microsoft's OSs store derivatives of passwords rather than clear-text passwords. These derivatives result from a one-way encryption function, in which NT inputs the password to the function and the function yields a hash, the derivative string of bytes that the function relates to the password. In this encryption process, an NT client requests a connection to the server. The server responds with a challenge of 8 random bytes. The client hashes the user's password, encrypts the server's challenge with this hash, and sends the encrypted challenge back to the server. (The client sends two responses to the server: One response uses the LAN Manager hash and another response uses the stronger NT hash.) The server then compares the client's response hash with the client's hash in the SAM Registry hive. If the client's response hash matches the client's SAM hash on the server, authentication is successful. PPTP and network services such as file and printer sharing depend on this password-hashing process for security. This dependence leads to the OS's security weaknesses.

NT's backward compatibility with LAN Manager hashing is at the root of NT's security problems because this process severely weakens even well-chosen passwords. LAN Manager's hash function doesn't support lowercase letters and splits maximum-length 14-character passwords into two 7-byte halves before it hashes the passwords. (LAN Manager uses each 7-byte half to encrypt an 8-byte constant via the Data Encryption Standard—DES. LAN Manager then concatenates the two encrypted constants, yielding a 16-byte hash.) LAN Manager's lack of lowercase-letter support and a password-splitting hash function makes easy targets of NT passwords and speeds dictionary and brute-force password-cracking attempts that use programs such as L0phtCrack. Although NT maintains another stronger hash method, the OS is only as strong as its weakest link.

A DUN client can use several protocols to authenticate to a PPTP server, but MSCHAP is the only protocol that supports subsequent encryption of network traffic. MSCHAP also uses a challenge-and-response encryption process. However, MSCHAP 1.0 is weak because it uses short encryption keys at two points in the authentication process. First, MSCHAP appends 5 null bytes to the client's 16-byte LAN Manager hash. Then, it divides the resulting 21 bytes into thirds. Third, MSCHAP uses each 7-byte portion of the LAN Manager hash to encrypt the server's 8-byte challenge three times, yielding a 24-byte response. MSCHAP's encryption method repeatedly uses short encryption keys and pads the client's password hashes with constants. Intruders can leverage these weaknesses in MSCHAP's encryption process to derive a client's original password as evidenced by LHI's PPTP challenge-and-response sniffer and password cracker. (The current version of LHI's PPTP sniffer runs on only Solaris.)

MSCHAP authenticates only the client and not the server. This vulnerability lets an attacker masquerade as the intended PPTP server and launch several attacks. For example, a rogue server can return a password-expired error to the requesting client, which prompts unwitting users to create a new password and send it to the attacker. MSCHAP's lack of server authentication permits various man-in-the-middle attacks.

Microsoft addressed these vulnerabilities in the PPTP3 Update for NT 4.0 Service Pack 3 (SP3), which SP4 includes. In this fix, Microsoft introduced MSCHAP 2.0. According to Microsoft, MSCHAP 2.0 uses server and client challenges to provide mutual authentication to NT. In addition, MSCHAP 2.0 doesn't support the password changes MSCHAP 1.0 performs. These modifications make masquerading as the PPTP server and using the password-expired trick to steal passwords more difficult for intruders. Also, MSCHAP 2.0 doesn't send the LAN Manager hash in challenge-and-response exchanges, which makes the current version of the PPTP sniffer ineffectual.

Microsoft Point-to-Point Encryption (MPPE) protocol. PPTP lets you encrypt user data that NT carries over the VPN. According to Microsoft, this encryption uses a 40-bit key if the client or server is running the exportable version of NT, or a 128-bit key if both systems are running the domestic version. However, the encryption key is a derivative of the password and not a truly random string of 40 or 128 bits. NT limits the type and number of characters available to users for passwords; as a result, PPTP keys aren't true randomly generated keys. Your data encryption is only as strong as your password.

To provide this data encryption, PPTP uses a subprotocol called MPPE, which uses the RC4 encryption algorithm. This algorithm outputs a continuous stream of unpredictable bytes that it bases on an initial seed (i.e., the encryption key). MPPE uses exclusive OR (XOR) with this stream of bytes and the stream of user data it's encrypting. MPPE sends the resulting cipher to the receiver. The receiver uses XOR with the cipher MPPE sends and the RC4 stream of unpredictable bytes to decrypt the data.

This encryption method works well if you use it correctly, which means you must never encrypt two data streams with one key. If intruders capture both encrypted streams and they know the clear text of a portion of one of the streams or they can predict a portion, they can decrypt an equal portion of the other stream's text. Unfortunately, Microsoft used the same RC4 key to encrypt data from client to server and from server to client.

To take advantage of this vulnerability, an intruder must sniff the PPTP traffic as it traverses the Internet and know or predict the data in one of the streams. An intruder can use several methods to launch this attack. For example, the user data MPPE encrypts are Point-to-Point Protocol (PPP) packets that contain predictable header information. An intruder might be able to predict the clear-text header of PPP packets traveling in one direction and therefore recover a corresponding amount of clear text traveling in the opposite direction. However, most of the data an intruder recovers with this method is boring packet headers because of MPPE's uniform packet construction and cipher stream synchronization. Alternatively, an attacker can provide the clear text traveling in one direction to decipher data sent in the opposite direction. This method requires the attacker to have an accomplice within the trusted LAN who pumps known data across the PPTP connection while the attacker sniffs the traffic. In a third method, the attacker sends a huge amount of unsolicited commercial email (UCE) to PPTP users. The email waits at the users' SMTP server, which is most likely behind the PPTP server. When remote users retrieve their email, the attacker might be able to decode data sent in the opposite direction.

The latest version of PPTP uses unique session keys for both directions of traffic. PPTP now derives the keys from the password-hash and challenge method that MSCHAP 2.0 uses. The challenge is different each time, so the keys are unique. Each direction of traffic has a separate session key: one based on the server's challenge and another based on the client's challenge. Although Microsoft claims this enhancement provides stronger initial encryption keys, PPTP keys are still not true randomly generated keys.

In addition, MPPE updates the session key every 265 packets, which makes the key a moving target. However, the way MPPE handles lost packets creates another security weakness. MPPE uses a coherency counter that it increments with each packet to keep data senders and receivers synchronized. When MPPE receives a packet that has an unexpected coherency counter, it flushes the RC4 cipher stream and resynchronizes the stream with the data sender, and thus resets the counter to the next key change. An attacker can prevent MPPE from changing the session key by regularly spoofing a bad coherency counter. This trick causes MPPE to use the same key for encryption, which makes it easier for the attacker to sniff. Microsoft addressed this risk with a history-less mode for MPPE key management that defeats the attack.

Security Enhancements
You need to update your server and clients to take advantage of the PPTP security enhancements I've discussed. To update your systems, you need to install NT 4.0 SP3 or SP4 and the PPTP3 Update on your NT servers and clients. If you're running SP3 and RRAS from the NT 4.0 Option Pack, you must install the RRAS fix after you install the PPTP3 Update. If you're running Windows 95 clients, you need to install DUN 1.3; Win98 clients need the DUN Upgrade. You can find these updates at http://www.microsoft.com/ security/bulletins/ms98-012.asp.

Poor PPTP?
Although Microsoft has filled some of PPTP's security holes, it hasn't addressed all the protocol's vulnerabilities. PPTP conducts all its control operations, such as connection setup and maintenance, in a clear-text channel without authentication. This design flaw leaves PPTP wide open to denial-of-service attacks (i.e., an assault that floods the network with so many requests that the attack slows or completely interrupts regular traffic). In addition, intruders can glean a lot of information about your PPTP server from this unencrypted and unauthenticated control channel.

However, PPTP is not a terrible protocol. PTTP's problems arise in Microsoft's implementation of the protocol. Microsoft used inferior key-generation techniques that produce weak encryption. In addition, the company compromised the RC4 algorithm by encrypting multiple data streams with the same key. By not encrypting the control channel and not requiring mutual authentication, Microsoft left PPTP open to man-in-the-middle attacks and designed its PPTP implementation to give away information.

Is PPTP secure? Microsoft claims to have fixed most security holes, and the users and intruders who discovered the vulnerabilities haven't disputed the company's claim. Most analysts agree that PPTP is safe for lightweight VPN needs and, if you implement the PPTP enhancements, is fairly difficult to hack.

PPTP is a safe option for small companies that are spread out geographically. Such companies can enjoy the business connectivity of a WAN for the price of a phone line and ISP account, with sufficient peace of mind. Large organizations that need to transmit confidential information over the Internet need to look at third-party tools that use industry standards such as Layer 2 Tunneling Protocol (L2TP) or IP Security (IPSec). If you stick with PPTP, you can look forward to Windows 2000's (Win2K's) native IPSec support.