Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00


                                            `Date: Sat, 13 Feb 1999 11:28:40 -0800  
From: aleph1@UNDERGROUND.ORG  
To: BUGTRAQ@netspace.org  
Subject: PPTP Revisited  
[ The following text is in the "iso-8859-1" character set. ]  
[ Your display is set for the "US-ASCII" character set. ]  
[ Some characters may be displayed incorrectly. ]  
[ 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.  
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 >