[9549] in bugtraq
PPTP Revisited
daemon@ATHENA.MIT.EDU (aleph1@UNDERGROUND.ORG)
Sat Feb 13 15:06:37 1999
Date: Sat, 13 Feb 1999 11:28:40 -0800
Reply-To: aleph1@UNDERGROUND.ORG
From: aleph1@UNDERGROUND.ORG
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199902112112.PAA00201@dfw.nationwide.net>; from Ryan Russell on
Mon, Feb 08, 1999 at 10:47:17AM -0800
[ 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 accu=
rate. ]
Last year a number of vulnerabilities in the PPTP protocols and Microso=
ft'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:
=B7 The control connection is not authenticated.
=B7 The MS-CHAP LANMAN hash response is vulnerable to a dictionary atta=
ck that
can be speed up enormously.
=B7 The MS-CHAP NT hash response is vulnerable to a dictionary attack.
=B7 A attacker can steal a users password hashes via the MS-CHAP passwo=
rd
change protocol version one.
=B7 The 40-bit LANMAN hash based session key is the same across session=
s.
=B7 MPPE does not authenticate the server.
=B7 MPPE does not provide true 128-bit or 40-bit security.
=B7 MPPE does not encrypt Network Control Protocol PPP packets.
=B7 MPPE uses the same key in both directions.
=B7 MPPE is vulnerable to a Reset-Request attack.
=B7 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:
=B7 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 authenti=
cation.
It also stops the Windows NT client from using the LANMAN password ha=
sh for
authentication when configured for 128-bit encryption.
=B7 They introduced a "stateless" mode in MPPE which is not vulnerable =
to the
Reset-Request attack. They implemented this mode in the PPTP Performa=
nce
Update for Windows NT 4.0.
On August of the same year Microsoft released a security bulletin stati=
ng
they had developed a set of fixes for the Microsoft Dialup Networking o=
n
Windows 95, Microsoft Remote Access Services on Windows NT 4.0 (client =
and
server), Microsoft Routing and Remote Access Server for Windows NT Ser=
ver
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 passwo=
rd
change password theft vulnerability and the reuse of MPPE session keys.
In essence this patches implement a new version of MSCHAP, version 2. F=
rom KB
article Q189771:
"A new MSCHAP secure mode (MSCHAP V2) has been implemented, providing m=
utual
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, M=
SCHAP
V2 drops support for the MSCHAP password change V1, and will not transm=
it the
LM password response."
"For VPN connections, a Windows NT 4.0 server (updated as described bel=
ow)
will negotiate MSCHAP V2 before negotiating the original MSCHAP. An upd=
ated
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 l=
egacy
clients from presenting their credentials in an MSCHAP or PAP or CHAP
exchange, and is a likely configuration for networks that require the m=
ost
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 Microsof=
t did
what they said.
Vulnerabilities that have not been addressed:
=B7 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).
=B7 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 nu=
mber of
call the to hash function (SHA1) by Microsoft to hash everything they c=
an
think off into the challenge/response.
=B7 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.
=B7 MPPE does not encrypt Network Control Protocol PPP packets.
Information such as the client's internal IP address, DNS server addres=
s and
other bits of information continue to be public.
=B7 MPPE is vulnerable to bit flipping attacks.
To fix this they would have to either add a MAC to each packet or chang=
e 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.tx=
t >
Deriving MPPE Keys From MS-CHAP V1 Credentials
< http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschapv1-keys-0=
0.txt >
Deriving MPPE Keys From MS-CHAP V2 Credentials
< http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschapv2-keys-0=
2.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 >
