Re: [NTSEC] PPTP (again)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: [NTSEC] PPTP (again)
- To: NTBUGTRAQ
LISTSERV.NTBUGTRAQ.COM
- Subject: Re: [NTSEC] PPTP (again)
- From: Paul Leach <paulleMICROSOFT.COM>
- Date: Tue, 5 May 1998 18:53:08 -0700
- Comments: To: Aleph One <aleph1nationwide.net>, Vin McLellan <vinshore.net>
- Comments: cc: ntsecurityiss.net, secure-ntwwa.com, NTSECURITYLISTSERV.NTBUGTRAQ.COM
- Reply-To: Paul Leach <paulleMICROSOFT.COM>
- Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
-----BEGIN PGP SIGNED MESSAGE-----
- -----Original Message-----
From: Aleph One <aleph1nationwide.net>
Date: Saturday, May 02, 1998 5:26 AM
Some comments on some parts of Aleph's message. Please reply to the
NTSECURITYLISTSERV.NTBUGTRAQ.COM list.
>MPPE
>
>The are two drafts for MPPE. The Dec 1996 draft and the Apr 1998 one.
>(A year and a half for a draft revision?). I'll discuss the 1996
version
>first.
>
>MPPE uses RC4, a stream cipher, to encrypt the PPP datagrams. It
currently
>supports session keys of 40 and 128 bit, although more key lengths
can be
>defined. MMPE is actually negotiated as a PPP compression control
protocol.
>
>The 40-bit session key is derived from the first 8 bytes of the
LANMAN hash.
>This session key will be the same for all sessions.
AS you note below, in the '98 draft, this only happens in the
deprecated "L" mode, which clients of the update can be configured to
not use, and servers to not accept (by not sending the LM hash-derived
response). In "N" mode in the '98 draft, the session key computation
will be different if the server sends different challenges.
Just don't want to leave a mistaken impression about the current spec.
>
>The 128-bit session key is derived from the first 16 of the MD4 hash
of the
>first 16 bytes of the NT hash and the challenge sent by the server.
Don't ask
>me why the need to hash the NT hash again. This session key will be
>different across sessions as long as the server sends different
challenges.
A fact not noted by many.
>
>MPPE being a sub-protocol of PPP, a datagram protocol, does not
expect
>a reliable link. Instead if maintains a 12 bit counter for each
packet
>to keep the encryption tables synchronized. If it ever sees a packet
>with a packet count it is not expecting it sends a CCP Reset-Request
packet
>to the other end to resynchronize the tables. The other end upon
seeing
>a CCP Reset-Request packet will re-initialize the RC4 tables using
the
>current session key. The next packet it sends will have the flushed
bit
>set. This will indicate to the other end if should re-initialize is
own tables.
>In this way the resynchronize.
This mode is now deprecated.
>
>Note that the protocol draft is rather vague. For example it does not
>state if you have two coherency counts - one for each direction. This
is
>the only sensible thing so I am assuming this is the way it works.
You are correct.
>
>Every time the low order byte of the sequence number equals 0xFF
(every
>256 packets) the session keys are regenerated based on the original
>session key and the current session key.
>
>The encrypted part of the packet contain a two(?) byte protocol ID
>followed by a network packet (e.g. IP header + TCP header + data).
>
>What does this all mean to us? Well it means we can force both ends
>of the connection to keep encrypting their packets with the same key
>until the low order sequence number reaches 256.
Only if you use a deprecated mode. See the '98 draft.
>
>Now most of these encrypted packets will have very common structures
>(IP headers, TCP headers, etc). Any cryptoanalyst worth its salt
should
>be able to decrypt the stream with this much data to work with.
The revelation of the IP/TCP headers in one direction will only enable
the decryption of the headers in the other direction, because the
predicatable parts are the same length. Pretty boring.
>
>The Apr 1998 version of the draft add a "stateless mode" option to
the
>negotiated packet. This option tells MPPE to change the session key
after
>every packet. In the Security Consideration section they admit that
different
>packets may be encrypted with the same key.
It was referring to the bug you describe above which stateless mode
fixes.
>
>They also added an option to use a 40-bit key derived from the NT
hash.
>In the Security Considerations section they state that 40-bit session
>keys are the same across all sessions. This is wrong. Only the 40-bit
>session key derived from the LANMAN hash is the same across sessions.
>The 40-bit key derived from the NT hash is also derived from the
MS-CHAP
>server challenge.
Yup. So each session gets its own key.
>
>This "stateless mode" seems like a band-aid. Why the hell are you
going
>to change the session key of a stream cipher after each packet? By
doing
>this you loose all the performance. If you are using a good
algorithm,
>(and RC4 is good) then you should be able to use the session key
longer
>than that. The problem is than attacker can force the protocol to
reset
>it state. This is a no-no with stream ciphers. So instead of fixing
the
>broken, unauthenticated CPP Reset-Request, and using the different
>session keys in each direction we see this hack.
We did fix the broken CPP Reset-Request; we don't use it anymore.
Stateless mode is not a bandaid. Packets can be dropped. The receiver
doesn't have any idea of how much data got dropped, and hence how much
of the cipher stream was used up, so the protocol uses a different key
for each packet, in such a way that the reciever can figure out which
key to use for which packet. This means that all it costs at the PPTP
layer to recover from a single lost packet is a single new-key
computation.
This is totally orthogonal from the issue of using different keys in
each direction.
>
>Under this new "stateless mode" Mallory can no longer force Alice and
>Bob the resynchronize to the same RC4 state. But Mallory can still
>make their life difficult. The draft states that if a receiver gets a
>packet with a coherency count larger than what it expects
>it must change its key as many times as needed to synchronize with
the
>packet's coherency count so it can be unencrypted.
>
>Well what do you think happens if Alice expect a coherency count of
zero
>and Mallory sends her a spoofed packet from Bob with a coherency
count of
>4095? Well she is going to perform 4095 key generations. Thats 4095
>calls to the SHA hash function. Although SHA is a fast hash function
>a flood of these types of packets may drive the CPU usage noticeably
high.
>More interesting is the fact that the draft does not state what
happens
>when Bob then tries to send a real packet to Alice with a coherency
count
>much lower than that expected by Alice in stateless mode. Alice cant
go back
>to an earlier session key. She can only move forward. Are they now
>completely out of sync? I don't know. This is more someone else to
find
>out.
As you pointed out in some stuff I snipped, the attacker can also just
RST the connection. So, much easier DOS attacks than this are
available.
>
>Conclusion:
>
>PPTP may be an useful tool if you don't have the most stringent
security
>requirements, but if you do stay way from it. Although MS tried to
>build a secure protocol the are to many unauthenticated control
packets
>that can be spoofed to make this a weak protocol.
All you've shown vis-a-vis spoofing is that it can lead to DOS
attacks, when much easier ones are available.
The '98 spec makes decrypting traffic much harder. 40 bit keys are
different for each session, for example. The CPP-Reset attack that you
pointed out last summer has been fixed, so that you can't get 256
packets encrypted with the same key.
As Alan pointed out, the same key is used in each direction, so that
the Nth packet in each direction will use the same key. (Similar to
what you pointed out in the context of the CPP-reset attack.) That
means that if you can predict the contents of the Nth packet in one
direction, you can decrypt the packet going in the other direction.
That's not good, but it's better than having being able to crack the
packet if you can predict that value of any of 256 packets....
This is mitigated by the fact that the packets are compressed in such
a way that unpredicted data early in the packet ruins the ability to
predict data later in the packet.
- ---------------------
Paul J. Leach <paullemicrosoft.com>
PGP Key ID: 0x978829DD
Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8
Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com
-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5
iQCVAwUBNU/Cg8qlCdSXiCndAQHPOAQAodUS7QRdafx1SkMpSa/l6l9GN9VpSbBz
rJgPOGs+mhv0u60xSoUjZWj3uSEddQF+0C4sPQYQ8eMppQcn/TiQPu3BmxQETPtU
2ZTHERSRAGyYvIzOp6uVKiKhdKsBdYLV7uGkt9U0ykoQGNbkRNb+45O+Fzgqh6+F
9nHa5gj+KGI=
=dRfz
-----END PGP SIGNATURE-----
