PPTP (again)

From: Aleph One (aleph1at_private)
Date: Sat May 02 1998 - 03:50:54 PDT

  • Next message: HSKarim: "RST's and ACK's and stealth scans"

    It's late and this probably makes little sense. Here it is anyway.
    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
    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
    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 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.
    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 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 
    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.
    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 
    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
    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
    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?
    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 / aleph1at_private
    KeyID 1024/948FD6B5 
    Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 

    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:58:17 PDT