Everhart,Glenn From: Russ [Russ.Cooper@RC.ON.CA] Sent: Saturday, May 02, 1998 10:46 AM To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: PPTP (again) My apologies for the repost, but Aleph did not put in the correct address for NTBugtraq so I have reposted it correcting that address. The original message was also sent to NTSecurity@iss.net and secure-NT@wwa.com. If you are replying, you may want to add those addresses to your reply. Aleph's original message ------------------------ It's late and this may not make much sence. Anyway here it is. About a year ago I was involved in a discussion in the NTSecurity mailing list regarding the security of PPTP (Microsoft's Point-to-Point Tunneling Protocol). At the time I claimed that MS's badly written protocol and their choice of a stream cipher could be coerced into leaking information. Recently a few people have been asking if this is indeed the case. Strangely enough MS seems to be tight quiet about the subject and has responded to several email on the subject. Neither have I for that matter. I really haven't looked a PPTP since then and all my information was based from reading the protocol spec. Not from looking at bits in the wired. I've gotten enough inquiries (hi Vin) that I gave this thing a look again. MS has since published a new MPPE draft. Here I'll try to describe have I see as problems with PPTP. NOTICE: This is a late night hack. I am basing all my theories in the published specs for the different protocols. MS may have implemented things differently and all of this may just be a figment of my imagination. What's more the spec are rather vague and there is plenty of space for interpretation. As always if you want real answers break out the sniffer. The players: GRE - Is generic encapsulation protocol. As usual MS uses their own variant. GRE is described in RFC 1701 and 1702. PPP - A point-to-point networking protocol. PPTP - PPTP uses GRE to tunnel PPP and adds a connections setup and control protocol. For the details on the protocol check the PPTP Technical Specification at http://hooah.com/workshop/prog/prog-gen/pptp.htm. MS-CHAP - This is MS variant of CHAP. It is a challenge response authentication algorithm, it has nothing to do with encrypting the channel. Other than supplying the challenge. It also has two sub-protocols for changing passwords. The drafts are draft-ietf-pppext-mschap-00.txt. MPPE - Microsoft Point-To-Pint Encryption Protocol. This is the protocol in charge of generating a key and encrypting the session. The drafts are draft-ietf-pppext-mppe-00.txt and draft-ietf-pppext-mppe-01.txt. Top lever overview: PPTP creates a connection setup and control channel using TCP to the PPTP server. Using this connection PPTP establishes a new GRE tunnel. This GRE tunnel will carry PPP packets from the client to the server. The client will authenticate to the server via MS-CHAP and will then encrypt all PPP data packets using MPPE. Enough acronyms for you? Lets get dirty: PPTP PPTP creates a connection setup and control channel to the server via TCP. Originally this was port 5678. Later on MS changed it to 1723. This connection is not authenticated in any way. It is easy for Mallory to take over the TCP stream. She can know issue a Stop Session Request command. This will close the control channel and at the same time ALL active calls will be cleared. You may obtain the same results by RST'ing the TCP connection. YMMV. GRE PPP packets are encapsulated in GRE and tunneled via IP. GRE uses protocol number is 47. GRE packets are similar in some respects to TCP segments. They both may carry a sequence number and acknowledgement number. GRE also uses a sliding windows to avoid congestation. This has some important implications. It means that if we want to spoof PPP packets encapsulated in GRE we will desynchronize the GRE channel. A possible way around this is the use of the "S" flag in the GRE header. This flag tells the end point if this GRE packet has a sequence number. It is possible that a badly coded implementation will accept a GRE packet with data even if it does not have a sequence number. This is because in the original GRE standard the use of sequence numbers was optional. The spec does not mention how an end system should act if it receives a GRE packet with a duplicate sequence number. It may simply discard it and send another ACK. This would mean we do not need to resynchronize GRE at all! The other end will send an ACK for the the packet we spoofed and encapsulated PPP should not become desynchronized. Also it is interesting to note that the original GRE draft many options to do things like source routing that are left as implementation specific. If you open a hole in your firewall for GRE just so you can use PPTP you might be letting in more than you think. Someone with more time in their hands may want to investigate what NT does with hand crafted GRE packets. MS-CHAP MS-CHAP is a challenge response protocol. The server sends the client an 8 byte challenge. The client then computes a response by encrypting the challenge with the NT one way hash or with the LANMAN one way hash. It may compute and send both or just one. These can be easily sniffed and put through a tool like L0phtcrack. MS-CHAP has two sub-protocols for changing passwords. In version one the client encrypts the new and old hashes (NT & LANMAN) with the challenge the server sent over the wire. As you can imagine a passive attacker can simply decrypt the hashes and steal them. Version two is smarter. It encrypts the new hashes with the old hashes and encrypts the old hashes with the new hashes. Only the server which knows the old hashes will be able to decrypt the new hashes and use these to decrypt the old hashes and verify the user is who he says. Of curse all of this is vulnerable to a man in the middle attack. In a sense this is the same problem as Paul Ashton discussed with regards of Internet Explorer doing NTLM authentication with any web server. Also note that the server cant tell the client to only use the NT hashes. At best all it can do is fail to authenticate the client if it ever sends the LANMAN hashes, but at that point they will already have made it across the network. 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. 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. 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. 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. 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. For example assume that Alice and Bob has just set up the communication channel. They both have initialized they session key and expect a packet sequence of zero. Alice -> Bob Alice sends Bob a packet numbered zero encrypted the with the cipher stream generated by the RC4 cipher and increments her sent coherency count to one. Bob receives the packet, decrypts it, and increments his receive coherency count to 1. Mallory (Bob) -> Alice Mallory sends Alice a spoofed (remember this is a datagram protocol - assuming we don't desynchronize GRE) CCP Reset-Request packet. Alice Alice immediately re-initialized the RC4 tables to their original state. Alice -> Bob Alice sends another packet to Bob. This packet will be encrypted with the SAME cipher stream as the last packet. The packet will also have the FLUSHED bit set. This will make Bob re-initialize its own RC4 tables. Mallory can continue to play this game up to a total of 256 times after which the session key WILL be changed. By this point Mallory will have collected 256 packets from Alice to Bob all encrypted with the same cipher stream. Furthermore, since Alice and Bob start with the same session key in each direction Mallory can play the same game in the opposite direction, collection another 256 packets encrypted with the same cipher stream as the ones going from Alice to Bob!!! 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 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. 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. 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. 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. Implementation Bugs At least one denial of server bug has already been found in PPTP. Kevin Wormington posted a program to BugTraq in November of last year that will crash an NT server running PPTP. Who many more are just waiting to be found? http://www.geek-girl.com/bugtraq/1997_4/0386.html 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. The lesson to be learned is that you must authenticate EVERYTHING. Call setup and control, retransmission, synchronization, etc. Comments, gifts, death threats are welcome. 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