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
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 / aleph1at_private
http://underground.org/
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