PPTP VPN authentication protocol proven very susceptible to attack

Later today, Joshua Wright will release an upgraded version of his ultra-high speed password cracking tool called ASLEAP . For those of you already familiar with ASLEAP, you might be wondering what this has to do with Microsoft's PPTP VPN protocol since ASLEAP is a LEAP authentication dictionary attack tool. Well that was then and this is now. ASLEAP just added PPTP authentication support so that it can crack PPTP VPN authentication sessions just as easily as it could with LEAP Wireless LAN authentication. The end result is that we have yet another authentication protocol that has outlived its lifespan and just goes to show that Bill Gates wasn't kidding when he declared the password dead.

Three months ago, I was trying to explain the difference between PPTP and L2TP VPN to a friend while working on a breaking story on SP2 where Windows XP SP2 broke NAT-T operation in L2TP VPN by default. As I was trying to explain the differences, I noticed how similar PPTP authentication was to LEAP authentication where both relied solely on MSCHAPv2 to protect the user's password. I sent word to Joshua Wright and he immediately said that it would be possible to modify ASLEAP to work on PPTP just as it did on LEAP authentication. Three months later, the code is fully operational and I've had a chance to verify its effectiveness.

ASLEAP was created in 2003 by Joshua Wright to prove that a password based authentication system like Cisco LEAP is not a secure because of one glaring weakness, it relies on humans to memorize strong passwords. Eight months later in mid 2004 after Cisco had a chance to release an updated protocol to LEAP, Joshua released ASLEAP on to SourceForge. PPTP is a Microsoft VPN protocol published as an RFC in 1999 for secure remote access. In recent years, it has grown to be used in many Microsoft based networks, firewall appliances, and even pure Linux and Open Source environments. Strictly speaking, there never was anything technically wrong with the LEAP or PPTP MSCHAPv2 authentication protocol since they both worked as advertised. Both Cisco and Microsoft warned from the very beginning that strong passwords must be employed when using password based authentication schemes. Unfortunately, strong passwords (or even strong pass phrases) are simply incompatible with most Homo sapiens and if you force the issue, they will go out of their way to make it easy by writing passwords down on a sticky note and taping it to their monitor. Since strong passwords are rarely implemented in practice, you have a situation where the product simply isn't safe enough to protect us from ourselves. As Bruce Schneier likes to say, "any password you can reasonably expect a user to remember can be brute forced or guessed". ASLEAP just happens to make that point abundantly clear since it had the ability to scan through a 4 GB pre-computed password hash table at a rate of 45 million passwords a second using a common desktop computer. This new version of ASLEAP not only adds PPTP compatibility, but also extends maximum database size to 4 Terabytes and the ability to scan live off the air using a Wireless LAN card and a regular sniffer in Microsoft Windows. As a result, Wireless LAN hotspots have just became deadly to PPTP authentication and those who use PPTP to substitute for real Datalink layer Wireless LAN security aren't spared either and are wide open to password cracking.

When Joshua Wright reported this to Microsoft's official security response team, Microsoft gave this official response.

• Implement and enforce a strong password policy.
• If users wish to continue using PPTP, they should employ EAP-TLS authentication instead of the default MSCHAPv2 authentication mechanism.
• Switch to an L2TP/IPSEC based VPN.

Here is my assessment and recommendations on this advice:

• The problem with the first recommendation is that strong passwords are rarely implemented in reality and are very difficult for the users to use. The fact that the users will probably end up writing their passwords down in a convenient place will probably do more harm than good. Bill Gates is absolutely right when he says "the password is dead".
• As for using EAP-TLS authentication with PPTP, this is a strong solution and it will protect weak passwords during PPTP authentication. However, implementing EAP-TLS authentication with Microsoft PPTP requires server-side "Computer Certificates" and it requires client-side "User Certificates". Automatically deploying "Computer Certificates" on a Microsoft Windows 2000 or 2003 Active Directory based network is relatively simple, but "User Certificate" aren't so simple. You have to have Windows 2003 Enterprise Edition server to support automatic "User Certificate" enrollment.
• Converting to an L2TP/IPSEC base is probably the best advice here and you would be using standards based IPSEC 3DES encryption. Since L2TP only requires "Computer Certificates" on both the Server and Client, the Certificates can be automatically deployed by Windows 2000 or Windows 2003 Standard Edition shops. Note that in order for L2TP VPN to be practical, you must have Microsoft's latest NAT-T capable VPN client freely available for all versions of Windows. Windows XP SP2 has a built in NAT-T client, but it is partially crippled by default and this is explained in an earlier story. You can fix it if you read this Knowledge Base article. For more information on Microsoft's L2TP and Digital Certificates, you can go here and here.

Unrelated to Microsoft, there are many firewall appliances and Open Source projects that use PPTP with MSCHAPv2 authentication. For those organizations that fit in to this category, the recommendation is the same and they should switch to an L2TP/IPSEC VPN solution. Fortunately for them, L2TP and Digital Certificates are fully supported by Open Source. You can get some good information on Open Source L2TP implementations here.