COMMAND
PPTP (MS-CHAPv2)
SYSTEMS AFFECTED
WinNT
PROBLEM
Following is based on Cryptanalysis of Microsoft's PPTP
Authentication Extensions (MS-CHAPv2) and Cryptanalysis of MS's
PPTP Authentication Extensions (MS-CHAPv2) from:
http://www.counterpane.com/pptpv2-paper.html
and some responses to it. The Point-to-Point Tunneling Protocol
(PPTP) is used to secure PPP connections over TCP/IP link. In
response to previous analysis, MS released extensions to the PPTP
authentication mechanism (MS-CHAP), called MS-CHAPv2. L0pht and
Bruce Schneier present an overview of the changes in the
authentication and encryption-key generation portions of
MS-CHAPv2, and assess the improvements and remaining weaknesses
in MS's PPTP implementation. The Point-to-Point Tunneling Protocol
(PPTP) is a protocol that allows Point-to-Point Protocol (PPP)
connections to be tunneled through an IP network, creating a
Virtual Private Network (VPN). MS has implemented its own
algorithms and protocols to support PPTP. This implementation of
PPTP, called Microsoft PPTP, is used extensively in commercial
VPN products precisely because it is already a part of the
Microsoft Windows 95, 98, and NT operating systems. The
authentication protocol in Microsoft PPTP is the Microsoft
Challenge/Reply Handshake Protocol (MS-CHAP); the encryption
protocol is Microsoft Point to Point Encryption (MPPE). After
MS's PPTP was cryptanalyzed and significant weaknesses were
publicized, Microsoft upgraded their protocols. The new version
is called MS-CHAP version 2 (MS-CHAPv2); the older version has
been renamed as MS-CHAP version 1 (MS-CHAPv1). MS-CHAPv2 is
available as an upgrade for Microsoft Windows 95, Windows 98, and
Windows NT 4.0 (DUN 1.3). Even though this upgrade is available,
authors above believe that most implementations of PPTP use
MS-CHAPv1. This paper examines MS-CHAPv2 and discusses how well
it addresses the security weaknesses outlined in original
advisory. The most significant changes from MS-CHAPv1 to
MS-CHAPv2 are:
The weaker LAN Manager hash is no longer sent along with the
stronger Windows NT hash. This is to prevent automatic
password crackers like L0phtcrack from first breaking the
weaker LAN Manager hash and then using that information to
break the stronger NT hash. An authentication scheme for the
server has been introduced. This is to prevent malicious
servers from masquerading as legitimate servers. The change
password packets from MS-CHAPv1 have been replaced by a single
change password packet in MS-CHAPv2. This is to prevent the
active attack of spoofing MS-CHAP failure packets. MPPE uses
unique keys in each direction. This is to prevent the trivial
cryptanalytic attack of XORing the text stream in each
direction to remove the effects of the encryption.
These changes do correct the major security weaknesses of the
original protocol: the inclusion of the LAN Manager hash function
and the use of the same OFB encryption key multiple times.
However, many security problems are still unaddressed: e.g., how
the client protects itself, the fact that the encryption key has
the same entropy as the user's password, and the fact that enough
data is passed on the wire to allow attackers to mount
crypt-and-compare attacks. This being said, Microsoft obviously
took this opportunity to not only fix some of the major
cryptographic weaknesses in their implementation of PPTP, but also
to improve the quality of their code. The new version is much
more robust against denial-of-service style attacks and no longer
leaks information regarding the number of active VPN sessions.
The MS-CHAPv1 challenge/response mechanism was described in one
paper before. Briefly:
- Client requests a login challenge from the Server.
- The Server sends back an 8-byte random challenge.
- The Client uses the LAN Manager hash of its password to derive
three DES keys.
- Each of these keys is used to encrypt the challenge. All three
encrypted blocks are concatenated into a 24-byte reply. The
Client creates a second 24-byte reply using the Windows NT
hash and the same procedure.
- The server uses the hashes of the Client's password, stored in
a database, to decrypt the replies. If the decrypted blocks
match the challenge, the authentication completes and sends a
"success" packet back to the client.
This exchange has been modified in MS-CHAPv2. The following is
the revised protocol:
1. Client requests a login challenge from the Server.
2. The Server sends back a 16-byte random challenge.
3a. The Client generates a random 16-byte number, called the
"Peer Authenticator Challenge."
3b. The Client generates an 8-byte challenge by hashing the
16-byte challenge received in step (2), the 16-byte Peer
Authenticator Challenge generated in step (3a), and the
Client's username.
3c. The Client creates a 24-byte reply, using the Windows NT
hash function and the 8-byte challenge generated in step
(3b). This process is identical to MS-CHAPv1.
3d. The Client sends the Server the results of steps (3a) and
(3c).
4a. The Server uses the hashes of the Client's password,
stored in a database, to decrypt the replies. If the
decrypted blocks match the challenge, the Client is
authenticated.
4b. The Server uses the 16-byte Peer Authenticator Challenge
from the client, as well as the Client's hashed password,
to create a 20-byte "Authenticator Response." (See Section
4 for details.)
5. The Client also computes the Authenticator Response. If
the computed response matches the received response, the
Server is authenticated.
A general description of the changes between MS-CHAPv1 and
MS-CHAPv2 is given in Figure 1. MS-CHAP Version 1MS-CHAP Version 2
Negotiates CHAP with an algorithm value of 0x80. Negotiates
CHAP with an algorithm value of 0x81.
Server sends an 8-byte challenge value.Server sends a 16-byte
value to be used by the client in creating an 8-byte challenge
value. Client sends 24-byte LANMAN and 24-byte NT response
to 8-byte challenge.Client sends 16-byte peer challenge that
was used in creating the hidden 8-byte challenge, and the
24-byte NT response. Server sends a response stating SUCCESS
or FAILURE.Server sends a response stating SUCCESS or FAILURE
and piggybacks an Authenticator Response to the 16-byte peer
challenge.
Client decides to continue or end based upon the SUCCESS or
FAILURE response above.Client decides to continue or end based
upon the SUCCESS or FAILURE response above. In addition, the
Client checks the validity of the Authenticator Response and
disconnects if it is not the expected value.
Some basic differences between MSCHAP V1 and MSCHAP V2
authentication. This protocol works, and eliminates the most
serious weaknesses that plagued MS-CHAPv1. In MS-CHAPv1, two
parallel hash values were sent from the Client to the Server: the
LAN Manager hash and the Windows NT hash. These were two
different hashes of the same User password. The LAN Manager hash
is a much weaker hash function, and password-cracker programs
such as L0phtcrack were able to break the LAN Manager hash and
then use that information to break the Windows NT hash. By
eliminating the LAN Manager hash in MS-CHAPv2, Microsoft has made
this divide-and-conquer attack impossible. Still, the security of
this protocol is based on the password used, and L0phtcrack can
still break weak passwords using a dictionary attack.
As we will discuss later, multiple layers of hashing are used in
the different steps of MS-CHAPv2. While this hashing serves to
obscure some of the values, it is unclear what the cryptographic
significance of them are. All they seem to do is to slow down the
execution of the protocol. There are also concerns over the
amount of control the client has in the influence of the ultimate
8-byte challenge that is used, though authors have not yet been
able to come up with a viable attack to exploit this. Certainly
it opens the possibility of subliminal channels, which can be
exploited in other contexts.
Deriving the 8-byte Challenge for the 24-byte Response In
MS-CHAPv1, the Server sends the Client an 8-byte random challenge.
This challenge is used, together with the Client's password and a
hash function, to create a pair of 24-byte responses. In
MS-CHAPv2, the Server sends the Client a 16-byte challenge. This
challenge is not used by the Client directly; the Client derives
an 8-byte value from this 16-byte challenge. The derivation
process is as follows:
- The Client creates a 16-byte random number, called the Peer
Authenticator Challenge.
- The Client concatenates the Peer Authenticator Challenge
with the 16-byte challenge received from the server and the
Client's username.
- The client hashes the result with SHA-1.
- The first eight bytes of the hash become the 8-byte
challenge.
It is these 8 bytes that the Client will use to encrypt the
16-byte local password hash (using the Windows NT hash function)
to obtain the 24-byte response, which the Client will send to the
server. This method is identical to MS-CHAPv1, and has been
described in previous paper. It is unclear to why this protocol
is so complicated. At first glance, it seems reasonable that
the Client not use the challenge from the Server directly, since
it is known to an eavesdropper. But instead of deriving a new
challenge from some secret information-the password hash, for
example-the Client uses a unique random number that is sent to
the Server later in the protocol. There is no reason why the
Client cannot use the Server's challenge directly and not use the
Peer Authenticator Challenge at all.
In MS-CHAPv2, the Server sends the Client a 20-byte Authenticator
Response. The Client calculates the same value, and then compares
it with the value received from the Server in order to complete
the mutual authentication process. This value is created as
follows:
- The Server (or the Client) hashes the 16-byte NT password hash
with to get password-hash-hash. (The Server stores the client's
password hashed with MD4; this is the NT password hash value.)
- The Server concatenates the password-hash-hash, the 24-byte NT
response, and the literal string "Magic server to client
constant", and then hashes the result with SHA.
- The Server concatenates the 20-byte SHA output from step (2),
the initial 8-byte generated challenge and the literal string
"Pad to make it do more than one iteration", and then hashes the
result with SHA.
The resulting 20 bytes are the mutual authenticator response.
Authors do not know why Microsoft chose such a complicated
protocol, since this is not stronger than the following:
- The Server sends the Client an 8-byte challenge.
- The Client encrypts the 16-byte local password hash with an
8-byte challenge and sends the Server the 24-byte response,
an 8-byte challenge of its own, and the username.
- The Server sends a pass/fail packet with a 24-byte response
to the Client's challenge, which is the user's
password-hash-hash encrypted with the Client's 8-byte
challenge.
The downside to the MS-CHAPv2 protocol is that an eavesdropper can
obtain two copies of the same plaintext, encrypted with two
different keys. However, in the current model, watching the
network for any length of time will still give you multiple copies
of a user challenge/response as the user logs in and out, which
will be encrypted with different keys. As it stands, a passive
listener is still able to get the 8-byte challenge and the
24-byte response from the information sent. The popular hacker
tool L0phtcrack, which breaks Windows NT passwords, works with
this data as input. This task was much easier with MS-CHAPv1,
since the weaker LAN Manager hash was sent alongside the stronger
Windows NT hash; L0phtcrack first broke the former and then used
that information to break the latter. L0phtcrack can still break
most common passwords from the Windows NT hash alone. And this
still does not solve the problem of using the user's hash for
MPPE keying, PPTP authentication, etc. without negotiating, at
least, machine public key/private key methods of exchanging such
an important key.
Since Microsoft has attempted to retain some backwards
compatibility with MS-CHAPv1, it is possible for an attacker to
mount a "version rollback attack" against MS-CHAP. In this
attack, the attacker convinces both the Client and the Server not
to negotiate the more secure MS-CHAPv2 protocol, but to use the
less secure MS-CHAPv1 protocol. In its documentation, Microsoft
claims that the operating systems will try to negotiate MS-CHAPv2
first, and only drop back to MS-CHAPv1 if the first negotiation
fails. Additionally, it is possible to set the Server to require
MS-CHAPv2. Authors find this scenario implausible for two
reasons. One, the software switches to turn off backwards
compatibility are registry settings, and can be difficult to find.
And two, since older versions of Windows cannot support MS-CHAPv2,
backwards compatibility must be turned on if there are any legacy
users on the network. We conclude that version rollback attacks
are a significant threat.
The original encryption mechanism in Microsoft's Point to Point
Encryption protocol (MPPE) used the same encryption keys in each
direction (Client to Server, and Server to Client). Since the
bulk data encryption routine is the RC4 stream cipher, this
created a cryptographic attack by XORing the two streams against
each other and performing standard cryptanalysis against the
result. In the more recent version, the MPPE keys are derived
from MS-CHAPv2 credentials and a unique key is used in each
direction. The keys for each direction are still derived from
the same value (the Client's NT password hash), but differently
depending on the direction.
MPPE keys can be either 40 bits or 128 bits, and they can be
derived from either MS-CHAPv1 credentials or MS-CHAPv2
credentials. The original derivation protocol (from MS-CHAPv1)
was described in previous paper. Briefly, the password hash is
hashed again using SHA, and then truncated. For a 40-bit key,
the SHA hash is truncated to 64 bits, and then the high-order 24
bits are set to 0xd1269e. For a 128-bit key, the SHA hash is
truncated to 128 bits. This key is used to encrypt traffic from
the Client to the Server and traffic from the Server to the
Client, opening a major security vulnerability. This has been
corrected in MS-CHAPv2. Deriving MPPE keys from MS-CHAPv2
credentials works as follows:
Hash the 16-byte NT password hash, the 24-byte response from
the MS-CHAPv2 exchange, and a 27-byte constant (the string
"This is the MPPE Master Key") with SHA. Truncate to get a
16-byte master-master key. Using a deterministic process,
convert the master-master key to a pair of session keys.
For 40-bit session keys, this is done as follows:
Hash the master-master key, 40 bytes of 0x00, an 84-byte
constant and 40 bytes of 0xF2 with SHA. Truncate to get an
8-byte output. Set the high-order 24 bits of 0xd1269e,
resulting in a 40-bit key.
The magic constants are different, depending on whether the key
is used to encrypt traffic from the Client to the Server, or from
the Server to the Client. For 128-bit session keys, the process
is as follows:
Hash the master-master key, 40 bytes of 0x00, an 84-byte
constant (magic constant 2 or 3), and 40 bytes of 0xF2 with
SHA. Truncate to get a 16-byte output.
This modification means that unique keys are used in each
direction, but does not solve the serious problem of weak keys.
The keys are still a function of the password, and hence contain
no more entropy than the password. Even though the RC4 algorithm
may theoretically have 128-bits of entropy, the actual passwords
used for key generation have much less. This having been said,
using different keys in each direction is still a major
improvement in the protocol.
SOLUTION
Microsoft has improved PPTP to correct the major security
weaknesses described in furst paper. However, the fundamental
weakness of the authentication and encryption protocol is that it
is only as secure as the password chosen by the user. As
computers get faster and distributed attacks against password
files become more feasible, the list of bad passwords-dictionary
words, words with random capitalization, words with the addition
of numbers, words with numbers replacing letters, reversed words,
acronyms, words with the addition of punctuation-becomes larger.
Windows 2000 will have an SSL/TLS based scheme. See the Internet
Draft:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-eaptls-05.txt.