Microsoft pptp vpn vulnerabilities Exploits in Action

© SANS Institute 2000 - 200
                                                5
, Author retains full rights.
 
 
 
 
 
 
 
 
 
 
 
 
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 
 
© SANS Institute 2000 - 200
5                                                                                                                 
Author retains full rights.
14
every packet and to ignore all this CCP Reset-Request and flushed bit business.  
This option was introduced to improve PPTP's performance.  Although re-keying
after each packet cuts the cipher performance by almost half, now PPTP no
longer has to wait a whole round trip time to resynchronize.  This, in effect
improves the performance of PPTP and at the same time made the attack I
describe above useless.”
Since the NCP PPP packets are not encrypted, only protocol numbers 0x21 
through 0xFA (just the data usually) would then be encrypted, this means all the 
other PPP traffic (for example LCP) would not, and is available as public 
information to any attacker’s attempt to “sniff” such information. This can reveal 
a lot of useful information about the user, the user’s network, etc.
Not verifying that the server is authentic means that an attacker can easily 
pretend to be the VPN server (commonly referred to as “spoofing”) to the client, 
and send various requests and responses to manipulate the client into sending 
important information to the attacker's system.
For various reasons, the supposed 40 bit and 128 bit encryption options are 
not considered truly 40 bit and 128 bit strong. Key parts causing this are:
No true randomization “salt” to make the keys more unique
•
Key length is dependent upon password length
•
Entropy is based on password
•
MS-CHAP v1 uses the following procedure for authentication:
Client sends a request for a login challenge from the VPN server 
•
Server returns 8 byte “random” challenge
•
Client system, using the LANMAN hash of it's password (as discussed 
•
earlier in this document) to create three DES keys.
The 3 DES keys are used to encrypt the challenge into three 8 byte 
•
encrypted strings
The 3 strings are concatenated together into a 24 byte string
•
This 24 byte string is sent as a challenge reply to the server 
•
The server uses it's hashed record of the user's password to decrypt 
•
these replies sent by the client
If decryption matches, then success message sent back to client
•
MS-CHAP version 1 using the LANMAN hash has the weaknesses as 
described earlier in this document and more specifically applied to PPTP has 
the additional risks:
The LANMAN hash is easily vulnerable to fast dictionary attacks
•
A change password request dialogue can be initiated by an attacker to 
•
the client
There are a number of easily available tools such as L0phtcrack or Crack 
v5.0 and others that make it very simple to capture and crack the LANMAN 
hashed information very quickly.
0

---