Everhart,Glenn From: Aleph One [aleph1@NATIONWIDE.NET] Sent: Wednesday, May 06, 1998 12:01 AM To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: PPTP (again) On Tue, 5 May 1998, Paul Leach wrote: > 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. We are in agreement. You may want to flesh out for the benefit of the people on the list which version of PPTP implement which version of the draft. > >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. And the answer is? Why do you hash the the hash? > >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. Good to know. > >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. Thanks for confirming it. > >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. That is what I said. As I stated I was discussing the older draft first and then the newer one. > >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. You are making several assumptions. First the headers each each packet do not have to be of the same size. Headers of packets of the same session TCP session will most likely be the same size as TCP negotiates options at the beginning and sticks with them. But you can run multiple session over PPTP. Not all of them will have the same header size. Some will be IP/UDP. Some will be IP/TCP. Hell some may be NetBEUI or IPX. The point is that the headers will not always align, and the part that does not align may be used to guess that data section in another packet. Furthermore, if you leave the session alone and don't spoof the Reset Requests even if the headers are all the same size the packets will probably not be. This means that some of the header of packets in one direction will overlap with sections of data of packets in the other direction encrypted with the same cipher stream. For example: H = Header bytes D = Data bytes One direction: HHHDDDDHHHDDDDDDDDHHHDDDDDHHHDDD The other way: HHHDDDDDDHHHDDDDDDDDDHHHDDDHHHDDDDD As you wan see the headers will not always align cancelling each other. Indeed if the data to header ratio is high the probability that they will not align in high. The bigger the payload the bigger the change it may attacked. > >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. I assumed as much. > >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. Except for the deprecated LANMAN sessions. > >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. Fair enough. > 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. The old draft could recover as well from lost packets, albeit not as fast as the latest draft. There is still an issue of the coherency count wrapping since its such as small number (4095) . If there is a bad network blackout a wrap around is possible and the connection will most likely become desynchronized as the coherency count of the sender will the lower that what the receiver expect. You may use a sliding window to the the test. This will save if only less than 4095 packets have been lost Any more packets and you are hosed. Of curse if the the network gets that bad you might as well shut down the connection and restart it later. > This is totally orthogonal from the issue of using different keys in > each direction. Correct. It is not orthogonal from the issue of obtaining another 255 packets encrypted with the same cipher stream in stateful mode though. > >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. True, but had you used a better protocol for connection set up and control this would not be the case now would it? > >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. What I've shown is that PPTP ws nit designed as the most secure protocol. Sure you have fixed some of the vulnerabilities. Does it make it better than the old protocol? Yes. Does it make it better than the alternatives? No. > 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. None of this changes my conclusion. Never did I say that PPTP could be cracked compleatly. PPTP is probably OK for most people. But it _CAN_ be made to leak bits of information, and you _CAN_ attack the c/r exchange. It is also _VULNERABLE_ to man in the middle attacks. So if you require top notch security the are better options out there right now. Agreed? > Paul J. Leach > PGP Key ID: 0x978829DD > Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8 > Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01