[ Lots of people have asked for a review of the updated version of PPTP. This is a quick and dirty check up on it, so it may not be fully accurate. ] Last year a number of vulnerabilities in the PPTP protocols and Microsoft's implementation where made public in a paper by Bruce Schneier and Mudge, as well as in an article I wrote for Phrack 53. These were the vulnerabilities found: · The control connection is not authenticated. · The MS-CHAP LANMAN hash response is vulnerable to a dictionary attack that can be speed up enormously. · The MS-CHAP NT hash response is vulnerable to a dictionary attack. · A attacker can steal a users password hashes via the MS-CHAP password change protocol version one. · The 40-bit LANMAN hash based session key is the same across sessions. · MPPE does not authenticate the server. · MPPE does not provide true 128-bit or 40-bit security. · MPPE does not encrypt Network Control Protocol PPP packets. · MPPE uses the same key in both directions. · MPPE is vulnerable to a Reset-Request attack. · MPPE is vulnerable to bit flipping attacks. For details check Schneier and Mudge's paper < http://www.counterpane.com/pptp.html > and my Phrack article < http://www.phrack.com/phrack53.tar.gz > . Microsoft tried to address these issues early on. In particular: · The PPTP Performance Update for Windows NT 4.0 added the option to reject PPTP client that attempt to use the LANMAN password hash for authentication. It also stops the Windows NT client from using the LANMAN password hash for authentication when configured for 128-bit encryption. · They introduced a "stateless" mode in MPPE which is not vulnerable to the Reset-Request attack. They implemented this mode in the PPTP Performance Update for Windows NT 4.0. On August of the same year Microsoft released a security bulletin stating they had developed a set of fixes for the Microsoft Dialup Networking on Windows 95, Microsoft Remote Access Services on Windows NT 4.0 (client and server), Microsoft Routing and Remote Access Server for Windows NT Server 4.0 and Microsoft Windows 98 Dialup Networking. Microsoft claims these patches fix the lack of server authentication, dictionary attack against the LAMNAN password hash response, the password change password theft vulnerability and the reuse of MPPE session keys. In essence this patches implement a new version of MSCHAP, version 2. From KB article Q189771: "A new MSCHAP secure mode (MSCHAP V2) has been implemented, providing mutual authentication, stronger initial data encryption keys, and different encryption keys for the transmit and receive paths." "To minimize the risk of password compromise during MSCHAP exchanges, MSCHAP V2 drops support for the MSCHAP password change V1, and will not transmit the LM password response." "For VPN connections, a Windows NT 4.0 server (updated as described below) will negotiate MSCHAP V2 before negotiating the original MSCHAP. An updated Windows 98 client will accept this offer and use MSCHAP V2 as the authentication method. To ensure that no VPN clients authenticate using MSCHAP, the server can be set to require MSCHAP V2. This will prevent legacy clients from presenting their credentials in an MSCHAP or PAP or CHAP exchange, and is a likely configuration for networks that require the most secure authentication method." A quick read of the appropriate RFC drafts revealed all of these claims appear to be true. Not to say there might not be other issues, after all I am no cryptologist and I only spent a few minutes on it. But overall Microsoft did what they said. Vulnerabilities that have not been addressed: · The control connection is not authenticated. This continues to be the case and leave PPTP connections vulnerable to denial of service attacks (an attacker can tore down a PPTP tunnel). · The MS-CHAP NT hash response is vulnerable to a dictionary attack. This is still true but it has been made very, very slow by the large number of call the to hash function (SHA1) by Microsoft to hash everything they can think off into the challenge/response. · MPPE does not provide true 128-bit or 40-bit security. This is still true. Under MSCHAPv2 the MPPE session keys continue to be derived from the user password, the challenges, and some magic numbers. All this information is public with the exception of the password, ergo the session key is only as strong at the password. · MPPE does not encrypt Network Control Protocol PPP packets. Information such as the client's internal IP address, DNS server address and other bits of information continue to be public. · MPPE is vulnerable to bit flipping attacks. To fix this they would have to either add a MAC to each packet or change to some other encryption algorithm. Note that its possible to play games to downgrade the clients into negotiating CHAPv1 and weak encryption so make sure you configure your client and servers to reject these options. References: Microsoft Security Bulletin (MS98-12) < http://www.microsoft.com/security/bulletins/ms98-012.asp > Microsoft PPP CHAP Extensions, Version 2 < http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-v2-02.txt > Deriving MPPE Keys From MS-CHAP V1 Credentials < http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschapv1-keys-00.txt > Deriving MPPE Keys From MS-CHAP V2 Credentials < http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschapv2-keys-02.txt > Microsoft Point-To-Point Encryption (MPPE) Protocol < http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-02.txt > Point-to-Point Tunneling Protocol (PPTP) < http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-07.txt >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:34:21 PDT