shows the layers of encapsulation involved in sending a TCP packet
via PPTP. Since PPP supports encapsulating multiple protocols, so
does PPTP. It is most often used to provide virtual private
networking, tunneling IP over IP, but it can also be used to tunnel
non-IP protocols like IPX.
14.11.2. Implementation Weaknesses in PPTP
As we discussed earlier, PPTP sends authentication information in
cleartext. In many versions of Microsoft PPTP, this information can
include a LanMan hash of the user's password. As described in
Chapter 21, "Authentication and Auditing Services", it is relatively easy to use a LanMan
hash to discover a password. You can disable Lan Manager
authentication and should do so on all clients and servers you
control. This will force the authentication to use more secure
Windows NT password hashes.
icrosoft's implementation also has problems with the
encryption. Microsoft offers two levels of encryption, both using the
symmetric key encryption algorithm called RC4; one uses a 40-bit key,
and the other uses a 128-bit key. (See Appendix C, "Cryptography",
for more information on RC4 and the importance of key length.) The
40-bit RC4 algorithm is not particularly strong to begin with, and
icrosoft weakens it further by basing the key on the user's
password, so that a user will have multiple sessions with the same
key. The longer a key is used, the stronger it needs to be, and the
time between password changes may be a very long time indeed.
When 128-bit keys are in use, Microsoft bases the key on the
user's password and on a pseudo-random number so that
it's different for each connection. This is a major
improvement, although using the user's password does reduce the
number of probable keys and makes it important for PPTP users to have
good passwords.
ost PPTP implementations, including Microsoft's, are
susceptible to problems with control negotiations. As we pointed out
earlier, these negotiations take place before the client
authentication, which means that any attacker can send them.
It's therefore extremely important for servers to be able to
deal with bad negotiations, but in fact, many servers will crash if
they receive garbled negotiations, and some will crash even when sent
random garbage that bears no resemblance to a valid negotiation.
Although Microsoft offers an option to control PPTP access by source
IP address, it's enforced on the GRE tunnel, not on the
TCP-based negotiation. If you are doing PPTP from known source
addresses, you can protect the PPTP server with a packet filter in
front of it; if you are not, you have no choice but to live with
these denial of service attacks.