Is PPTP Safe?

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.