Author: Hawke Robinson

Overview

Initially this document covers, from a high level, various popular VPN technologies and implementations. This document then proceeds to delve into considerable depth about:

• The implementation.
• Lists several vulnerabilities in detail.
• Demonstrates in detail 5 attacks on various versions of the most common of Microsoft's PPTP products, using free, readily available tools
• Explains what each exploit is doing and how it works.
• Brief comparison of MS PPTP to other VPN options available as alternative VPN options, such as other PPTP implementations, L2F, L2TP, IPSEC, IKE, SSH, CIPE, & IPIP.
• Suggested options to decrease the vulnerabilities of using PPTP as a VPN solution.

One of the goals of this document is to attempt to bring together all the different scattered pieces of information about PPTP, MS PPTP, and the related technologies. It takes a considerable amount of time and effort to find all the pieces to understanding this technology. Hopefully, between the information listed in this document, the extensive bibliography and listings of references, most, if not all, of the related information will be at hand.

The basics of Virtual Private Networks

A Virtual Private Network, abbreviated as VPN, in it's most basic terms, is the use of various technologies to provide a private network of resources and information over any public network, including the Internet.

VPNs provide a means for organizations and individuals to connect their various resources over the Internet (a very public network), but not make the resources available to the public, instead only making them available to those that are part of the VPN.

VPNs provide a means for such users to have resources scattered all over the world, and still be connected as though they were all in the same building on the same network together, with all the ease of use and benefits of being interconnected in such a manner.

Normally, without a VPN, if such a private connection was desired, the company would have to expend considerable resources in finances, time, training, personnel, hardware and software to setup dedicated communication lines. These dedicated connections could be a variety of technologies such as 56k leased lines, dedicated ISDN, dedicated private T1/T3/etc. connections, satellite, microwave and other wireless technologies. Setting up an organization's private network over these dedicated connections tends to be very expensive.

With a VPN, the company can use their existing Internet connections and infrastructure (routers, servers, software, etc.) and basically "tunnel" or "piggy-back" their private network inside the public network traffic, and realize a considerable savings in resources and costs compared to dedicated connections.

A VPN solution is also able to provide more flexible options to remote workers instead of only dial-up speeds and choices, they can connect from anywhere in the world for just the cost of their Internet connection, at whatever speed their ISP services may provide.

There have been many VPN technologies developed in recent years, and many more on the way. They vary widely from simple, to very difficult to setup and administrate, from free to very expensive, from light security to much heavier protection, from software based to dedicated hardware solutions, and even some managed services providers (for example www.devtodev.com or www.iss.net ) now entering into the market to increase the VPN choices available.

Most VPNs operate using various forms of "tunneling" combined with many choices for encryption and authentication.

In this document "tunneling" is over IP based networks, though other technologies exist as well (such as ATM based). This document will focus on technologies that deliver VPN solutions over IP based networks, and refer to them generically as "public" or "Internet" based networks, and only delve into the specific "carrier" protocol when appropriate (IPX, ATM, and other protocols are also used, but as IP has become quite dominant, many are now focused on IP). This document will only cover IPv4 not IPv6. Use of MS PPTP over 802.11b wireless technologies will also be briefly covered.

The data of the "private network" is carried or "tunneled" inside the public network packet, this also allows other protocols, even normally "non-routable" protocols to become usable across widely dispersed locations. For example, Microsoft's legacy NetBEUI protocol can be carried inside such a tunnel, and thus a remote user is able to act as part of the remote LAN or two small LANS, in two very different locations, would actually be able to "see" each other, and work together, over many hops of routers, and still function, with a protocol that normally would not route across the Internet, although there are many consequences in trying to stretch such a protocol beyond it's intended use.

Tunneling in and of itself is not sufficient security. For example, let's use IP as the carrier public protocol, carrying IPX inside as the private protocol. Anyone sniffing the "public" network's packets could easily extract the clear text information of the IPX packets carried within the IP packets. This means that sufficient encryption of the carried IPX packets is necessary to protect their data.

These two technologies suffice to provide a basic VPN, but will be weak if a third part is missing or lax (as we will show in various examples throughout this document). This third part would be anything related to authentication, traffic control, and related technologies. If there aren't sufficient authentication technologies in place then it is quite simple for an intruder to intercept various VPN connections and "hijack" them with many "man/monkey in the middle attacks" and easily capture all data going back and forth between the VPN nodes, and eventually be able to compromise data, and potentially all networks and their resources, connected by the VPN.

This document is based on research and lab testing performed from March 1st through June 30th, 2002. The setup of the lab will also be briefly detailed to assist others who may wish to go into greater depth with this testing, and to help clarify under what circumstances the lab information was gathered.

Various VPN technologies

There are many VPN options and technology components available, this document will primarily focus on MS PPTP (Microsoft's implementation of Point to Point Tunneling Protocol). Other technologies will be mentioned based on two major premises: popularity and availability. Many factors go into determining availability including: market proliferation, pricing, ease of use, security, stability, flexibility, performance, reputation, etc.

The VPN protocols mentioned include:
PPTP (Point to Point Tunneling Protocol)
MS PPTP (Microsoft's PPTP)
CHAP (Challenge Handshake Authentication Protocol)
MSCHAP (Microsoft's CHAP)
MPPE (Microsoft Point to Point Encryption protocol)
IPSEC (Internet Protocol Security)
IKE (Internet Key Exchange)
L2TP (Layer 2 Tunneling Protocol)
CIPE (Crypto IP Encapsulation)
L2F (Layer 2 Forwarding protocol)
IPIP (Internet Protocol over Internet Protocol)
SSH (Secure Shell)

Various topology scenarios

Many of these VPN technologies can be affected by the layout and needed resources of the users. Some technologies don't handle roaming users as well as others. Some have trouble with NAT (Network Address Translation), still others run into problems with old routers or restrictive firewalls not even supporting their protocols and refusing to route them correctly.

There are many ways one could adjust the VPN topologies listed in this document, however a few will be listed to give some clarification of the challenges.

Including a more robust "security in depth" approach in sufficient detail, such as backup technologies, IDS (Intrusion Detection Systems) and monitoring technologies, is beyond the scope of this document.

Detailing the various strengths and weaknesses of each topology is also beyond the current scope of this document, however some more immediately obvious points will be noted for each.

Topology 1

VPN Server (and/or client) directly connected to the Internet and internal LAN, server may or may not have it's own firewall software running locally.

This is an all to common setup. It is inexpensive and easy to setup and administrate. Many inexperienced administrators and users may use this setup, not being aware of how vulnerable a situation this is.

Advantages: Easy to setup and administrate, very low cost.
Disadvantages: Little to no protection, very vulnerable to many attacks, information "leakage" and more.

Topology 2

VPN server behind a firewall but listening service ports still directly accessible for the ports that are allowed to be open by the firewall

This is another common setup. Inexpensive and still very easy to setup and administrate. This is an improvement over topology number 1. Unfortunately there are still many weaknesses easily exploited, and typically those who use this configuration rely too heavily upon the firewall to be their sole means of protection rather than "security in depth" and layering of defenses.

Advantages: Easy setup and administration, and low cost
Disadvantages: Still quite open and vulnerable to wide array of attacks.

Topology 3

VPN Server behind a firewall and only accessible to certain ports via port forwarding from the firewall.

This setup is an improvement over the previous two because of tighter restrictions on what traffic and services are allowed access and from where.

Advantages: Improved security "stance" still fairly easy to setup and administrate.
Disadvantages: Not quite as simple to setup as first two options, still not as many layers for a "security in depth" approach as there could be.

Topology 4

VPN server in a DMZ with the connected VPN user then allowed inside LAN through LAN firewall.

This is a much more ideal configuration. Multiple layers of checking and protection. Unfortunately either budget, time, resources, or administrator skill level tend to not be available for such an ideal setup. This can be improved upon even more with additional layers of firewalls and other "tricks of the trade".

Advantages: Much more secure stance, security in layers.
Disadvantages: High complexity to setup and administrate, added cost, more advanced skill sets required.

Topology 5

VPN server in a DMZ but as another gateway (aka hole) into LAN, usually the VPN server acts as yet another firewall as well (unfortunately not always though), and doesn't allow any traffic in except those actually connected to it via the VPN.

This is not as ideal a setup as Topology 4, but one that is not uncommon. It is a mix between option 3 and option 4, but NOT as secure as option 4 since there isn't a second firewall performing additional checking before allowing access to the LAN.

Advantages: Slightly easier setup and administration than option 4.
Disadvantages: Security level is only about equivalent to option 3.

Topology 6

Wireless (such as the popular 802.11b technologies) usage of VPN, usually one of the previous 5 topologies and possibly a firewall (recommended).

Unfortunately most companies are NOT implementing firewalls or VPNs to separate and protect their wireless LAN users, despite repeated press releases and proof of the simplicity of compromise. However, for those that do heed such warnings, this is one option, of several to choose from, that many implement. It's fairly easy to setup. It's much along the lines of Topology 1, because most companies assume that there are far fewer attacks via their local wireless LAN than the Internet just because of the sheer numbers of nodes, unfortunately such assumptions tend to be perilous. Others opt to have a firewall in front of the VPN server as well as the LAN, but this does not yet appear to be a common practice.

Advantages: More secure wireless setup, fairly easy to setup and administrate
Disadvantages: VPN server still wide open to many attacks and information leakage to wireless LAN users. Every attack described in this document is very effective on such a network. Even if the attacker can't gain VPN access into the LAN, they can still possibly easily abuse the bandwidth on the wireless segment, and easily attack the server and users on this segment.

Targeted Service: Microsoft's PPTP VPN Services

The services that are most detailed and targeted for exploit in this document are Microsoft's various implementations of PPTP and related technologies. This actually means covering several technologies including PPTP, CHAP, MSCHAP, IP, GRE, MPPE, LANMAN and NT Encryption, as well as multiple versions of some of these technologies.

Overview of Protocol: PPTP (Point to Point Tunneling Protocol)

There are three key parts to the PPTP protocol.

1. The Control Connection over TCP (destination port is 1723, source port can be any available port). THIS IS NOT AUTHENTICATED IN ANY WAY.
2. The IP tunnel used to transport GRE encapsulated packets (protocol 47 (note, this is not TCP or UDP PORT 47, but a specific, unique protocol).
3. The PPP packets that are encapsulated inside of the GRE tunnel carried by IP. Note that only the DATA packets are encrypted (when encryption is actually used, which is left open to the implementer and not actually part of the PPTP RFC, 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 be encrypted.

A tunnel must be established between each pair of systems (client and server) and a key that is included in the GRE packet header signifies which tunnel session a PPP packet is a member of.

The GRE header also contains:

• Acknowledgment information
• Sequencing information

The Control Connection (TCP port 1723) actually determines the data rate and traffic congestion actions based on information from the GRE headers. The PPTP RFC does not itself specify which algorithms or technologies to use for congestion-control and flow-control (though some are suggested), that is left open to the implementer to determine, but using the information from the GRE headers as the data to act against for adjustments.

Each PPTP Control Connection message starts with an 8 octet fixed header with the following information contained within:

• Total message length
• Message type (either Control Message or Management Message)
• "Magic Cookie" (a constant string of: "0x1A2B3C4D")

Any loss of synchronization is supposed to result in closing the connection immediately.

Microsoft's implementation of PPTP includes the following technologies:

• IP
• PPTP
• TCP 1723 (Control Connection)
• GRE (Tunnel)
• PPP
• MSCHAP (Authentication)
• MPPC (Compression)
• MPPE (Encryption)
• LANMAN Hash (Authentication)

Microsoft offers several authentication options:

• Clear text password
• LANMAN hashed password
• NT Encryption hashed password
• Challenge/Response MSCHAP version 1
• Challenge/Response MSCHAP version 2

The LAN Manager hash is created using the following:

Convert the user's password to 14 byte string

Truncate longer passwords or pad shorter passwords with nulls

Convert all characters to uppercase

Divide this 14 character string in half to create two 7 character strings

Use each 7 character string as a DES key

Encrypt a fixed constant with each key (no random salt provided, entropy is based on the password)

This creates two 8 byte encrypted strings

These two 8 byte strings are merged (concatenated) together to form a single 16 byte hashed string.

Compare this to when using the Windows NT hash:

• The password is by default a maximum of 14 characters, though it is easy enough to change this default to allow up to 128 characters for the password, unfortunately most administrators do not do so.
• Password is case sensitive and converted to Unicode
• Password hashed using MD4
• Produces a 16 byte hash

There are many well-known and well-documented weaknesses in version 1 of Microsoft's implementation of PPTP.

MPPE (Microsoft Point to Point Encryption protocol) has the following flaws:

Vulnerable to bit flipping attacks

The MS-CHAP version 1 when using the 40 bit LANMAN hash uses the same key for both client and server for the connection, able to trivially crack this key using a cryptanalytic XORing attack.

Vulnerable to "Reset-Request" attack

Does not encrypt NCP (Network Control Protocol) PPP packets

Does not verify that the server is authentic

Encryption is not truly 40 or 128 bit

The vulnerability to "bit-flipping" attacks is caused by the use of RC4.

Because of the use of a stream cipher (in this case RC4), the data can be changed at the bit level, and since the checksum method is weak for this standard, the message could be modified by an attacker, and the checksum data kept to appear valid, so that the recipient ends up with a slightly or completely different message than was sent and the recipient is none the wiser that data was changed. It is trivial for the attacker to cycle through "flipping a bit" and comparing data, to compromise RC4 "protected" information.

Because of the use of RC4 and the use of the same key on both sides of the connection (server and client) if an attacker can capture two (or more) "ciphertexts" and compare them, if the attacker knows the basic structure of the data, it is trivial for the attacker to then obtain the clear text information.

XOR, an exclusive OR (whereas OR is considered an "inclusive" OR), is a Boolean method to determine true or false results. It is true only if just one of it's operands is true. Whereas an inclusive OR is true if either or both of it's operands are true.

Based on information from pages 13 through 15 of Applied Cryptography 2nd Edition by Bruce Schneier, an XOR attack is carried out as follows:

1. Discover the length of the key (trivial since this is well published information)
2. Shift the ciphertext (encrypted information) by that length and XOR it with itself. This will remove the key and reveal the plain text information.

The vulnerability to "Reset-Request" is a weakness in the MPPE protocol that allows an attacker to keep sending reset requests to the client or server so that the encryption key doesn't change. This happens because the attack interferes with the normal incrementing of packet counts. The following excerpt is an excellent description of such an attack, from the Phrack Volume 8, Issue 53, article "The Crumbling Tunnel - A Menagerie of PPTP Vulnerabilities" by Aleph1 describing the MPPE Reset-Request weakness and attack: "... MPPE being a sub-protocol of PPP, a datagram protocol, does not expect a reliable link. Instead it maintains a 12-bit coherency count that is increased for each packet to keep the encryption tables synchronized. Each time the low order byte of the coherency count equals 0xFF (every 256 packets) the session key is regenerated based on the original session key and the current session key.

If MPPE ever sees a packet with a coherency that it is not expecting it sends a CCP Reset-Request packet to the other end. The other end, upon seeing this packet, will re-initialize the RC4 tables using the current session key. The next packet it sends will have the flushed bit set. This bit will indicate to the other end that it should re-initialize its own tables. In this way they become resynchronized. This mode of operation is called "stateful mode" in the new MPPE draft.

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 0xFF. For example assume Alice and Bob have just set up the communication channel. They both have initialized their session keys and expect a packet with a coherency count of zero.

Alice -> Bob

Alice sends Bob a packet numbered zero encrypted 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 datagram protocol - assuming we don't desynchronize GRE) CCP Reset-Request packet. Alice immediately re-initializes her RC4 tables to their original state. Alice -> Bob

Alice sends another packet to Bob. This packet will be encrypted with the same cipherstream 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 collecting another 256 packets encrypted with the same cipher stream as the ones going from Alice to Bob.

The Apr[il] 1998 version of the draft adds a "stateless mode" option (otherwise known as "historyless mode" in some Microsoft literature) to the negotiation packets. This option tells MPPE to change the session key after 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.

• 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:

3. Client sends a request for a login challenge from the VPN server
4. Server returns 8 byte "random" challenge
5. Client system, using the LANMAN hash of it's password (as discussed earlier in this document) to create three DES keys.
6. The 3 DES keys are used to encrypt the challenge into three 8 byte encrypted strings
7. The 3 strings are concatenated together into a 24 byte string
8. This 24 byte string is sent as a challenge reply to the server
9. The server uses it's hashed record of the user's password to decrypt these replies sent by the client
10. 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.

A change password request can be sent by the attacker, spoofing as the VPN server, tricking the client's system into presenting a change password dialog box and sending this information when entered and submitted by the user, to the attacker's machine.

MS-CHAP using even the NT hash is still easily vulnerable to dictionary attacks, though not quite as easily as the LANMAN hash, this problem is exacerbated considerably if users use common passwords, the best defense is a strong password policy that is enforced, if it is absolutely necessary to use MS PPTP.

Some of these vulnerabilities have been addressed in later versions of PPTP and various hot fixes, service packs, "performance updates", and manual registry changes.

The MS PPTP "Performance Update for Windows NT 4.0" and MS PPTP Version 2 (including MS-CHAP version 2) provides the following improvements to address a few of the many issues listed:

• Enable the server to only accept the NT password hash for authentication, and reject any client trying to use the LANMAN password hash for authentication
• Enable the NT client to not use the LANMAN password hash for authentication, but only if the client is configured for the supposed "128 bit" encryption.
• Addition of a "stateless mode" in MPPE, this eliminates the Reset-Request attack vulnerability
• Server authentication method added to decrease risk of attacker "spoofing" as server
• MPPE keys unique in each direction, this reduces the risk from a cryptanalytic XORing attack

MS CHAP v2 has a different challenge response process than version 1.

Compare the description of version one to version 2 as follows:

• Client requests login challenge from server (same as v1)
• The server sends the client a 16 byte random challenge (differs from v1)
• Client generates PAC (Peer Authenticator Challenge) as a random 16 byte number (differs from v1)
• Client concatenates the PAC and the 16 byte response from the server's challenge, and the client's username. (differs from v1)
• Client then hashes this result using SHA-1 (instead of MD4 in v1)
• Client sends the first 8 bytes of this hashed challenge to server (differs from v1)
• Server uses hashed password in server record for the user to decrypt and compare response from client, if matches, client is authenticated
• Server then uses the client's PAC and user's hashed password to send 20 byte AR (Authenticator Response) and sends it to the client
• The client also calculates what the AR should be on it's side, and compares the server's AR to the client's AR, if they match, then server is authenticated to client
• MPPE keys are now based on the MS-CHAP v2 information with a unique key for the server and a unique one for the client (compared to the same key for each in v1)

See the Counterpane Labs document "Cryptanalysis of Microsoft's MS CHAP v2" for even more detailed information on these steps.

Unfortunately the following well published weakness were not addressed:

• MS-CHAP NT hash is still easily vulnerable to cracking common passwords using basic dictionary attacks
• MPPE still does not provide true 40 bit or 128 bit encryption
• MPPE still does not encrypt the NCP PPP packets
• MPPE is still vulnerable to bit-flipping attacks
• And by default (requires editing the registry to prevent this attack) the client and server can be susceptible to version rollback attacks to make them use MS-CHAP v1 instead of v2, making the LANMAN hash available to the attacker once again

Typical PPTP traffic captured using ethereal on Linux:


Notice how the following information and "information leakage" is easily gleaned from this most basic and brief session of captured information:

• The IP of the DNS server the client is querying
• The DNS name of the VPN Server: vpn.virtucorp.com
• The PPTP port (TCP port 1723)
• The PPTP handshake process
• The PPP LCP handshake process
• The PPP CHAP Challenge
• The PPP CHAP Response

MS PPTP Vulnerabilities Overview

This document will cover in considerable detail 5 exploits of vulnerabilities in the Microsoft implementation of PPTP and real lab based demonstrations of the exploits in action.

The vulnerabilities are summarized as:

• DoS (Denial of Service): Can cause system to crash by attacking TCP/IP port 1723 on the listening server.
• DoS: Can cause system to crash by attacking GRE (protocol 47) listening port on server
• DoS: Can cause system crash by attacking GRE (protocol 47) listening port on server (another variation).
• Information Compromise: Retrieve and quickly crack LANMAN hash from MSCHAP version 1 clients.
• Information Compromise: Retrieve and quickly crack NT hash from MSCHAP version 2 clients.
• Information Compromise: Spoof VPN server to intercept VPN traffic log enough to retrieve client has information.

Some of these vulnerabilities are fixed in later implementations, but others still remain even in the latest versions of Windows NT, 2000, & XP fully patched and updated as of June 30th 2002. There are a number of registry hacks and not so easily found hot-fixes that can reduce some of these risks, but these tests were done under the common practice that most administrators follow of just performing the quickly and easily implemented updates, and not the laborious manual manipulations that are required for some, but not necessarily all of these issues to be resolved.

Incidents Chart

The following chart from www.incidents.org based on data from www.dshield.org is month snapshot of reported scans/attacks against the PPTP Connection Control TCP port 1723. Though it does not appear that PPTP related services have been in the top 10 list, this only lists reports that were actually submitted/tracked/reported to/from their site, and is only a small fraction of the total real incidents occurring every day. Attempts were made to try to get a yearly report on this service, but apparently the process for creating such reports is backlogged about 45 days, and was not available in time to include in this revision of this document unfortunately. A snapshot of a months worth of reports for July and August is included below.



CVE Numbers

CVE (Common Vulnerabilities and Exposures) is a means of assigning identification numbers and a database tracking common weaknesses. The website www.cve.mitre.org keeps a comprehensive and constantly updated list.

The following CVE and CVE candidates were found related to the protocols covered in this document including PPTP, MS PPTP, GRE, CHAP, MS CHAP, MPPC, MPPE:

• CVE-2001-0017 Memory leak in PPTP server in Windows NT 4.0 allows remote attackers to cause a denial of service via a malformed data packet, aka the "Malformed PPTP Packet Stream" vulnerability.
• CVE-2001-0204 Memory leak in PPTP server in Windows NT 4.0 allows remote attackers to cause a denial of service via a malformed data packet, aka the "Malformed PPTP Packet Stream" vulnerability.
• CVE-2001-1183 PPTP implementation in Cisco IOS 12.1 and 12.2 allows remote attackers to cause a denial of service (crash) via a malformed packet.
• CAN-1999-0140 ** CANDIDATE (under review) ** Denial of service in RAS/PPTP on NT systems.
• CAN-2002-0602 ** CANDIDATE (under review) ** Snapgear Lite+ firewall 1.5.4 and 1.5.3 allows remote attackers to cause a denial of service (crash) via a large number of connections to (1) the HTTP web management port, or (2) the PPTP port.
• CVE-1999-0160 Some classic Cisco IOS devices have a vulnerability in the PPP CHAP authentication to establish unauthorized PPP connections.

Surprisingly there were no CVE or CAN numbers found via the sites search, listed for GRE, MPPC, MPPE, MS CHAP, and other related vulnerabilities, even though various exploits, tools, and vulnerabilities were found during the research for this document on PPTP.

Specific MS PPTP Exploits

This section will cover in detail the lab configuration used for testing, the tools used, and the steps of the exploits, and their results.

A lot more information was gathered than is included in this release of this document. Many other operating systems and software configurations were tested during this time period, however much of this extended information has been left out to keep the focus of this document on the Microsoft implementation of PPTP, and keep the size of this document down to a manageable length for this assignment.

The actual lab notes are included in a later section in this document for those who are interested in the more specific details of these tests.

Lab Setup

Lab consisted of over 20 systems used to perform a wide range of tests on different levels of hardware, network topology and software combinations. All operating systems were tested (at least) with default out of the box installs (except for those that required a few updates to have any capability to even use PPTP such as Windows 95.

Time Period

Fully updated systems using "Windows Update" and downloaded "service packs" to make systems current by installing ALL relevant updates available between March 1st 2002 through June 30th 2002. Note however this does not include the many scores of hot fixes and registry manipulations that are scattered throughout the various Microsoft Technet and Windows related websites. These were only the easy to access and install updates, as the majority of overworked administrators are likely to use.

The same approach was used for Linux, Solaris and various BSD installs (FreeBSD & OpenBSD) using their various package update options.

Systems Used

Operating systems tested included:
Windows 95b (with minimum updates for VPN MSDUN 1.3)
Windows 98se (default)
Windows 98se (all updates)
Windows Me (all updates)
Windows NT 4.0 Workstation SP1
Windows NT 4.0 Workstation SP6a
Windows NT 4.0 Enterprise Server SP3 (default install)
Windows NT 4.0 Enterprise Server SP6a (no additional hot-fixes)
Windows 2000 Professional (default install)
Windows 2000 Professional (all updates)
Windows 2000 Server (default install)
Windows 2000 Server (all updates)
Windows 2000 Advanced Server (default install)
Windows 2000 Advanced Server (all updates)
Windows XP Home (default)
Windows XP Home (all updates)
Windows XP Professional (default)
Windows XP Professional (all updates)
Red Hat 6.2 (Linux) (default) plus PPTP
Red Hat 6.2 (Linux) (all updates) plus PPTP
Red Hat 7.3 (Linux) (default) plus PPTP
Red Hat 7.3 (Linux) (all updates) plus PPTP
VA Linux 6.2 (default)
OpenBSD 3.1 (all updates) plus various PPTP options
FreeBSD 4.5 (all updates) plus various PPTP options
Solaris 7 Sparc (default) plus PPTP options
Solaris 7 Sparc (all updates) plus PPTP options
Solaris 8 Sparc (default) plus PPTP options
Solaris 8 Sparc (all updates) plus PPTP options
Solaris 9 Sparc (default) plus PPTP options
Mac OS 8.1 (default) plus various PPTP products
Mac OS 9.1 (default) plus various PPTP products
Mac OS X (default) plus various PPTP products
MAC OS X (all updates) plus various PPTP products

The "attacker" system had several operating systems installed to allow for the widest range of tools, some accessed by multi boot partitions, and others from inside VMware running on Linux as the "host" operating system:
Red Hat 7.3 (all updates)
Windows 2000 Advanced Server (all updates) plus W2k Resource Kit
Solaris 7 x86 (all updates)
FreeBSD 4.5 (all updates)
OpenBSD 3.1 (all updates)

System equipment varied greatly from very low end:
Pentium 100 Mhz, 48 MB ram, 800 MB HD, 10 Mbps NIC

Low to mid range:
Pentium 233 Mhz, 128-385 MB ram, 2 to 8 GB HD, 10/100 NICs
Ultra 10 300 Mhz, 640 MB Ram, 3x 10/100 NICs, 9 GB HDs
Ultra 10 333 Mhz, 1,024 MB Ram, 1x 10/100 NIC + 1 Quad 10/100 NIC, 9GB SCSI HDs.

Higher end systems:
Athlon 750 Mhz, 512 to 640 MB ram, 30 to 100 GB HD, 100 Mbps NICs

Attacker system (laptop):
Pentium III 1,000 Mhz (mobile), 512 MB Ram, 20 GB HD, 10/100 NIC, Orinoco Wavelan "Gold" 128 bit 802.11b PCMCIA card, Sierra Wireless AirCard 300 CDPD PCMCIA card, Merlin Ricochet wireless card, 56 Kbps analog modem, VMware 3.1.1 build 1790

Network Description

Network was in several segments.
The Internal "corporate" LAN was 100 Mbps hub-based network.
The "Internet" was 10 Mbps switched and routed network.
The "Cable ISP" was hub-based 10 Mbps network.
The Wireless network was 802.11b network using WEP (Wireless Equivalency Protocol) and 128/104 bit encryption, running at peak of 11 Mbps.

Network Equipment:
Cisco Catalyst Switch 1900 Series 24 port switch
Netgear 8 port 10/100 hub model DS108
Bay Networks Model 28200 Switch
Bay Networks Baystack Model 303 Switch
3Com AirConnect 802.11b Access Point
Netscreen 5 brouter/firewall/vpn

Diagram summary overview (this diagram does not fully detail and list every system) of Lab setup:


Firewall Rules & Filters

To make the illustration of the PPTP vulnerabilities easier to perform, no firewall was placed in front of the PPTP server for the initial tests. Basically Network Topology #1 was used for the first array of lab work. Many other tests were performed later on with improved network topographies including DMZs, multiple firewalls, etc. For the sake of keeping this already extensive document size down, the other configurations are not included in detail for the attack examples. The configuration used for these examples includes a VPN server acting as it's own limited packet filtering firewall to the internal corporate LAN, PPTP server, and router for the internal LAN to access the Internet.

The firewall rules on the PPTP server were as follows:
Default DENY all protocols and services.
ALLOW the following protocols:
ICMP Echo (PING) both directions
PPTP TCP both directions: tcp 1723
GRE protocol 47 both directions
DNS both directions: tcp/udp 53
HTTP outbound from LAN: tcp/udp 80
HTTPS/SSL outbound: tcp/udp 443
SMTP outbound: tcp/udp 25
SMTPS outbound: tcp 465
POP outbound: tcp/udp 110
POP3S outbound: tcp/udp 995
SSH outbound: tcp/udp 22
None of the routers nor other parts of any of the other network segments had any filtering rules implemented for the first parts of the lab testing. All advanced and improved filtering and network topography changes were made later, that information is not detailed in this document as it is quite vast and beyond the scope of this revision of this document.

Monitoring & IDS

Most of the network monitoring in the simple tests illustrated in this document, was performed from the "attacker" machine, though occasionally another system would be put into the same network segment to gather additional network traffic information. Later experiments involved more advanced monitoring and logging and additional systems performing these functions, these tests are beyond the scope of this revision of this document.

Logging was increased to maximum on the PPTP and internal LAN's Domain PDC server, and when applicable on the PPTP client(s).

IDS was not implemented in the early experiments, although later experiments showed that most IDS systems (Snort and Tripwire were used the most in this lab, among other products that were sampled) easily detected the signatures of the packets from the active DoS attacks. Only if IDS was setup in the "ISP" network was it possible to detect the password/hash "sniffing" attacks, IDS at the PPTP server network were of course not able to detect such attacks since it is passive and the IDS software is not able to detect the attackers network interface being in promiscuous mode since it was several routers and switches away from the IDS systems. If the attacker was on the same subnet however (non-switched) the IDS products typically quickly detected the attackers network interface "sniffing" attempts.

Tools used

Anger.c
Ntpptp.c
Ipsend
Apsend
Netcat
L0pht plus NT extensions
John the Ripper
Crack plus NT extensions
Ethereal
Ngrep
Sniffit
Snort plus many add-ons
Sniff
Libnet
Dsniff
Libnids
Libpcap
Siphon
Nmap
Tripwire


Exploit #1 Details

Name: PPTP Attack 1 - Netcat DoS attack
Type: DoS (Denial of Service)
Wariants: Supposedly affects some hardware types and not others. Only supposed to work against NT systems below Service Pack 6.
Operating System(s): Windows NT Server (Any version below SP6)
Protocol(s)/Service(s): MS PPTP TCP/IP port 1723 Brief Description: Causes denial of PPTP services to clients and causes system instability and crash to blue screen
Description of Variants: Undetermined what the common variable in hardware that causes some systems to crash easier than others.
Protocol Description: PPTP Provides VPN services to remote users. (See detailed PPTP description earlier in this document)
How the Exploit Works:

By sending a stream of packets using Netcat targeting port 1723, the attacker is able to cause the server to blue screen within a few seconds of initiating the attack. This is caused by the NT PPTP Server having a flaw in it's code, causing it to be unable to handle certain types of data packets. These malformed packets will cause the system to generate memory leaks in the kernel. This attack sends malformed packets to the listening TCP/IP port 1723. This is not a flaw in the protocol itself, it is actually a flaw in the implementation of the protocol by the vendor (Microsoft).



Summary of Lab Testing

Verified that the attack worked, though not as quickly as some articles described.

CPU utilization increases up to +15% during attack but returns to normal when attack ends.

Server doesn't crash instantly from the attack, but any attempts to run any programs, or shutdown the server (control panel, service, manager, command, etc.) will cause the system to blue screen with the message: "KMODE_EXCEPTION_NOT_HANDLED"

Surprisingly, if a client is already connected to server when the attack begins, it appears to "protect" the server from this attack. This is even true if the server has multiple VPN/RAS interfaces available to connect to, as long as one client is connected, it appears to defeat the attack.

The attack causes a DoS condition to the server even if the attack is only run for 5 seconds. Clients will not be able to complete three-way handshake necessary for connection after the attack has been initiated.

Connected client maintains VPN connection if attack starts after client is already connected, but cannot communicate with any services on the server's side of the VPN (ping, file shares, network neighborhood, etc.), however all connections are available again as soon as the attack stops.

How to use the exploit

Simply send malformed packets at the victim server (if providing PPTP services) on TCP/IP port 1723. There are any number of methods of doing so, the effective one tried here is using netcat.

Signature of the attack:

• Temporary increase of CPU utilization
• PPTP Client's unable to connect
• PPTP Client's unable to connect to any services inside VPN server's side of network intermittently (during attacks)
• System crashes to blue screen when trying to perform any application function with message "KMODE_EXCEPTION_NOT_HANDLED"
• System crashes to blue screen when trying to perform system shutdown, with message "KMODE_EXCEPTION_NOT_HANDLED"

How to protect against it:

Download MS patch from http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-009.asp or install service Pack 6a or migrate to Windows 2000.

Another possible work around is to try to filter GRE packets by their source address at your perimeter, only allowing traffic from known addresses. However, since GRE is a connectionless protocol, source address spoofing is trivial. There are a number of tools and sites describing how to abuse any networks that allow any kind of GRE traffic. If an attacker can guess what source addresses are allowed, the attacker can simply send packets with the allowed source IP forged and bypass the filtering.

Exploit 2 Details

Name: PPTP ATTACK #2 ipsend based DoS attack
Type: DoS (Denial of Service)
Vulnerability Variants: Another variant of the "Malformed PPTP Packet Stream" vulnerability
Operating Systems: NT Server (supposedly affect all service packs)
Protocols/Services: PPTP GRE protocol 47
Brief Description: System will quickly blue screen shortly after the attack begins, this usually only requires about 50 packets to crash the PPTP server.
Description of any exploit Variants: See PPTP ATTACK numbers 1 and 3 which are also DoS related vulnerabilities related to the system not being able to handle malformed packets and consuming resources.
Protocol Description: PPTP GRE is the vulnerable protocol, please see the detailed description of this protocol in the earlier and later sections of this document under GRE.
How the Exploit Works

By using ipsend to send a number of malformed GRE packets to the target system, the PPTP server is unable to properly handle these packets and causes the system to become unresponsive.

Summary of lab testing:

Supposedly this attack is supposed to work against ALL NT 4.0 service packs. In lab testing however, it actually didn't do anything noticeable to the Service Pack 3 (default) Enterprise Server 4.0 installation. However, once SP6a was installed, the system would crash and blue screen within less than five seconds from when attack began. This was consistently repeatable on multiple installations on different machines.

How to use the exploit:

This attack requires ipsend, also available as part of the ipfilter firewall product. I was not able to get ipsend to compile on Linux, but it compiled and functioned fine on Solaris 8 and FreeBSD.

Simply point the attack script to the victim IP, and the system will blue screen within 5 seconds (depending on system and connection speeds of course).

Signature of the attack:

Very sudden blue screen with message: "IRQL_NOT_LESS_OR_EQUAL" within five seconds of receiving malformed packets using the GRE protocol (47).

No useful information in the Event Logs.

Typical traffic you would see during such an attempted attack (in this case against an up to date NT 4.0 SP6a system that is no longer vulnerable) is:

How to protect against it:

Download MS patch from http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-009.asp or install service Pack 6a or migrate to Windows 2000.

Another possible work around is to try to filter GRE packets by their source address at your perimeter, only allowing traffic from known addresses. However, since GRE is a connectionless protocol, source address spoofing is trivial. There are a number of tools and sites describing how to abuse any networks that allow any kind of GRE traffic. If an attacker can guess what source addresses are allowed, the attacker can simply send packets with the allowed source IP forged and bypass the filtering.

Exploit 3 Details

Name: PPTP attack #3 using apsend to send malformed packets to GRE protocol, causing system resources to become consumed and server unusable.
Variants: Another variation on the "Malformed PPTP Packet Stream" vulnerability
Operating Systems: All versions of NT, all service packs.
Protocols/Services: PPTP GRE protocol 47
Brief Description: Malformed packets are sent to the service listening for Protocol 47 (GRE) on the server. This is a bit longer attack than #1. This attack is cumulative. It can be paused and then continued later, and still eventually accumulates to the same effect, the system becomes unusable.
Description of Variants: Another Malformed packet DoS attack. It is unknown if there are any other variations on this specific attack.
Protocol Description: This attack targets GRE (protocol 47) sending a large quantity of malformed packets that the MS implementation is unable to handle correctly.
How the Exploit Works:

The attacker sends the stream of malformed packets. Initially the CPU utilization will slowly increase and as more packets hit the server's listening port, utilization will rise more quickly. The system's ram utilization will climb as fast as 1 MB per second (depending on system hardware). If the attack is stopped/paused, the CPU will settle back down to normal, but the ram will remain "consumed", though it will stop climbing. However, the attack is cumulative, unless the server is rebooted to clear the queue, so if the attacker later picks up the attack or performs it slowly over time, the system will keep consuming more memory, and CPU resources. Eventually, around 50% of available physical ram, the CPU utilization will suddenly jump up to 100%. The system is now unresponsive to most services, and cannot run any applications or be properly shutdown or rebooted.

Summary of lab testing:

System may "blue screen" very quickly, or later on when attempting to shutdown, reboot, or run applications, or system may just become completely unsuable. Ironically Service Pack 3 of NT appears to be invulnerable to this attack, but once SP 6a was installed, the system quickly succumbed.

The attack takes more time than the previous two exploits. It appears that once the ram consumption reaches 50%, the CPU will suddenly jump to 100% utilization, and then the system becomes unusable. Any attempts to run applications, dos commands, or even shutdown the system, are met with error messages and failure.

How to use the exploit: Signature of the attack:

Applications and command line commands won't function and give unusual errors.

PPTP and other services unresponsive.

Below is a typical Ethereal sniffing session screenshot (on Linux) during this attack (you may want to increase the magnification of this document to see screenshot more clearly):

How to protect against it:

Control what GRE packets are allowed through at the firewall. Unfortunately, GRE packets are easily spoofed. Another option is to upgrade to Windows 2000. Windows NT Service Pack 6a will not prevent this attack. It is possible there is a registry hack, or some hot-fix that was missed that may be available to fix this exploit, however I was not able to find such a fix that actually worked. Several were related, but after applying them, the systems were still vulnerable to this attack.

Exploit 4 Details

Name: PPTP Attack #4 using Anger.c against MS-CHAP Version 1
Variants: ntpptp.c, deceit.c, L0phtcrack or Crack with appropriate extensions
Operating Systems: All PPTP clients and servers that use MS-CHAP version 1
Protocols/Services: PPTP, MS-CHAPv1, LANMAN
Brief Description: Attacker is easily able to "sniff" much of the PPTP client and server handshake information as well as the actual LANMAN hashes. Attack script can quickly parses out the relevant information to make it easy to dump into L0phtcrack or other comparable password cracking tools.
Description of Variants: Anger is based partially on some of the contributions made by it's predecessors deceit.c & ntpptp.c, and is very simple to use.
Protocol Description: Due to weaknesses in the MS PPTP & MSCHAP version 1 technologies, theses scripts can quickly crack the user's login information.


How the Exploit Works:

Anger.c has several attack modes.

The most basic passive mode simply "sniffs" the traffic from a PPTP challenge-response event, it parses out the MS-CHAP portion and outputs the information to any file in a format compatible with the L0phtcrack password cracking tool.

Anger.c can also initiate an active attack manipulating the MS-CHAP version 1 protocol. It is able to initiate a "change password" request to the PPTP client attempting to logon to the PPTP VPN server. The user will then see a password change request dialog box appear on the screen. The user will then fill it out and submit the information, then the attacker will easily acquire this information. These hashes will then be formatted and output to a L0phtcrack compatible file for cracking. The attacker could also just use these raw hashes using a modified version of a PPTP client to logon directly to the VPN server.

Summary of lab testing:

Though these experiment were performed mostly on hubs using Ethereal, I did perform some tests using dsniff on the switch and was able to grab similar information. So it is certainly possible to perform this same attack on switched networks.

It was a trivial effort to capture and parse and break the LANMAN hashes, with enough modifying of the scripts and tying them together, it could possibly be performed in seconds instead of minutes. This was effective in getting any LANMAN hash from any version of any OS that used the MS-CHAP version 1 for authentication.Signature of the attack:

Any users (MS-CHAP version 1) complaining of password reset requests could also be a warning sign.

How to protect against it:

Do not use any client or server that use MS-CHAP version 1.

Be sure to update all clients and servers and follow MS recommendations.

Unfortunately, according to several resources (Counterpane Labs MS PPTP Version 2 article Section 5.1 "Version Rollback Attacks" http://www.counterpane.com/pptpv2-paper.html ) even following the MS recommendations, the server and clients can still be fooled into downgrading to MS-CHAP version 1.

Exploit 5 Details

Name: PPTP Attack #5 using Anger.c against MS-CHAP Version 1 & 2
Variants: ntpptp.c, deceit.c, L0phtcrack with appropriate extensions
Operating Systems: All PPTP clients and servers that use MS-CHAP version 2
Protocols/Services: PPTP, MS-CHAPv2, LANMAN, NT Encryption
Brief Description: Attacker is easily able to "sniff" much of the PPTP client and server handshake information as well as the actual LANMAN & NT hashes, the script then quickly parses out the relevant information and can separate the LANMAN and NT hashes and dump them into two separate files to make cracking with L0phtcrack and similar tools easier and much faster.
Description of Variants: Anger is based partially on some of the contributions made by it's predecessors deceit.c & ntpptp.c, and is very simple to use.
Protocol Description: Due to weaknesses in the MS PPTP & MSCHAP version technologies, theses scripts can quickly crack the user's login information.


How the Exploit Works:

The basic modes of Anger.c are the same in both Exploit #4 and #5.

But #5 included the additional option to attack MS-CHAP version 2 and NT Encryption based hashes in addition to the LANMAN based hashes.

Anger.c has several attack modes.

The most basic passive mode simply "sniffs" the traffic from a PPTP challenge-response event, it parses out the MS-CHAP portion and outputs the information to any file in a format compatible with the L0phtcrack password cracking tool.

Anger.c can also initiate an active attack manipulating the MS-CHAP version 1 protocol. It is able to initiate a "change password" request to the PPTP client attempting to logon to the PPTP VPN server. The user will then see a password change request dialog box appear on the screen. The user will then fill it out and submit the information, then the attacker will easily acquire this information. These hashes will then be formatted and output to a L0phtcrack compatible file for cracking. The attacker could also just use these raw hashes using a modified version of a PPTP client to logon directly to the VPN server.

MSCHAP version 2 client's are NOT vulnerable to the aforementioned password change attack. However, the new encryption methods used do not provide any significant security improvement in preventing the easily sniffed NT Encryption hashed challenge-response information from being almost as easily parsed, and broken quickly with L0phtcrack and similar tools.

Summary of lab testing:

Though these experiment were performed mostly on hubs using Ethereal, I did perform some tests using dsniff on the switch and was able to grab similar information. So it is certainly possible to perform this same attack on switched networks.

It was a trivial effort to capture and parse and break the LANMAN hashes, with enough modifying of the scripts and tying them together, it could possibly be performed in seconds instead of minutes. This was effective in getting any LANMAN hash from any version of any OS that used the MS-CHAP version 1 or version 2 for authentication.

It was a little slower in cracking the MS-CHAP version 2 NT Encryption based hashes, but not significantly.

Signature of the attack:

The same as Attack #4, a NIC in promiscuous mode could be a warning sign. Of course, any users (MS-CHAP version 1) complaining of password reset requests could also be a warning sign.

How to protect against it:

Though the improved versions of MS-CHAP and PPTP make compromising the hashes slightly more difficult when using Version 2 instead of 1, it is still far too simple to compromise this information. Strong passwords that are not dictionary based will be much more resistant to such attacks, if even one user password is dictionary based, then it is likely an attacker will crack it in time, and possibly fast enough to compromise the infrastructure.

Also, according to several resources (Counterpane Labs MS PPTP Version 2 article Section 5.1 "Version Rollback Attacks" http://www.counterpane.com/pptpv2-paper.html ) even following the MS recommendations, the server and clients can still be fooled into downgrading to MS-CHAP version 1.

One option, if using PPTP, is not to use any MS product for the PPTP client or server. The Linux and other *Nix & *BSD variants allow more control of the PPTP client and server, and can be kept from doing version rollbacks from MS Chap V2 to V1, this combined with very strong passwords appears to be a more robust solution, though most companies that are "Windows shops" are not likely to take this approach.

The best option would be to migrate away from PPTP to one of the other protocols such as IPSec.

Brief summary description of protocols

In this section we will go into non-implementation specific descriptions of the protocols covered in this document. Implementation specific versions of these protocols will be covered later.

IP (Internet Protocol)

RFC 791 http://www.ietf.org/rfc/rfc791.txt details this well known protocol.

PPTP (Point to Point Tunneling Protocol)

RFC 2637 (http://asg.web.cmu.edu/rfc/rfc2637.html ) describes the PPTP protocol in detail, but a (very) brief summary of the RFC is listed below:

There are three key parts to the PPTP protocol.

1. The Control Connection over TCP (destination port is 1723, source port can be any available port). THIS IS NOT AUTHENTICATED IN ANY WAY.
2. The IP tunnel used to transport GRE encapsulated packets (protocol 47 (note, this is not PORT 47, but a specific PROTOCOL).
3. The PPP packets that are encapsulated inside of the GRE tunnel riding on top of IP. Note that only the DATA packets are encrypted (when encryption is actually used, which is left open to the implementer and not actually part of the PPTP RFC, 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.

A tunnel must be established between each pair and a key that is included in the GRE packet header lists which tunnel session a PPP packet is a memoryber of.

The GRE header also contains:

• Acknowledgement information
• Sequencing information

The Control Connection actually determines the rate and traffic congestion actions based on information from these GRE headers.

PPTP does not itself specify which algorithms or technologies to use for congestion-control and flow-control (though some are suggested), rather that is left open to the implementer to determine, but again, using the information from the GRE headers as the data to act against for adjustments.

Each PPTP Control Connection message starts with an 8 octet fixed header with the following information contained within:

• Total message length
• Message type (either Control Message or Management Message)
• "Magic Cookie" (a constant string of: " 0x1A2B3C4D "
• Any loss of synchronization is supposed to result in closing the connection immediately.

PPP (Point to Point Protocol)

RFC 1661 http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1661.html describes PPP in detail. A (very) brief summary follows:

"The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links" (RFC 1661 Abstract).

The 3 key parts of PPP are:

• Encapsulation method for multi-protocol datagrams
• Extensible LCP (Link Control Protocol) for creation, configuring and maintaining the connection
• NCP (Network Control Protocols) for creating and configuring different network layer protocols

CHAP (Challenge Handshake Authentication Protocol)

RFC 1994 http://www.ietf.org/rfc/rfc1994.txt describes CHAP in detail. A (very) brief summary follows:

RFC Abstract "The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link…"

[a method which] "…uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key."

After PPP establishes a LCP link PPP makes available the OPTION (not required) to use an authentication method before going to the next phase, NCP.

CHAP is used during the initial connection and might be repeated occasionally throughout the session to verify identity.

A three-way "handshake" is used during these events.

The three steps (possibly repeated regularly) are:

Authenticator sends a "Challenge" message request to the peer.

The peer responds using a "one-way hashed" result.

GRE (Generic Routing Encapsulation Protocol)

RFC 1701 http://www.ietf.org/rfc/rfc1701.txt describes GRE in detail. A (very) brief summary follows:

RFC Abstract: "This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol."

The three key parts of GRE transport are:

• Delivery Header
• GRE header (describes the GRE packet and protocol carried within it), encapsulated inside another protocol (like IP) to be carried to it's destination at the other end of the VPN connection where it will then be disassembled at that remote network and the information from it's payload packet as well
• Payload packet (the entire packet in whatever protocol - IP, IPX, NetBEUI, etc. - with it's data and possibly it's route) encapsulated inside the GRE packet.

IPSEC (IP Security)

RFC 2401 http://www.ietf.org/rfc/rfc2401.txt describes the suite of protocols in detail. A (very) brief summary of this complex mix of technologies is listed below:

RFC 2401 part 3.1 "What IPsec does" states:

"… provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.)"

The many parts of the IPsec specification include:

• Access control
• connectionless integrity
• data origin authentication
• rejection of "replay" packets
• encryption
• traffic flow
• Compression

This service is provided at the IP layer, allowing use by "higher level" protocols such as TCP, UDP, ICMP, BGP, etc.

Traffic security is provided by:

• IP AH (Authentication Header) provides connectionless integrity, data origin authentication, and an optional anti-replay service.
• ESP (Encapsulating Security Payload) protocol provides encryption, traffic control and optionally may provide connectionless integrity, data origin auth, and anti-replay.
Ipsec is designed to support both Ipv4 & Ipv6.

IPsec suggests using IKE (public key) for key distribution but other implementations may be used, other examples cited include Kerberos and SKIP.

IKE (Internet Key Exchange)

RFC 2409 http://www.ietf.org/rfc/rfc2409.txt describes IKE in detail. A (very) brief summary follows:
RFC 2409 [IKE] "…a hybrid protocol." "…to negotiate, and provide authenticated keying material for, security associations in a protected manner."
In summary, IKE uses pieces of other technologies, those are:

• ISAKMP for auth and key exchange
• Oakley for different key exchange modes
• SKEME for "anonymity, repudiability, and quick key refreshment".

L2TP (Layer 2 Tunneling Protocol)

RFC 2661 http://www.ietf.org/rfc/rfc2661.txt describes L2TP in detail. A (very) brief summary follows:
RFC 2661 Abstract "…L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications."
Two key components of L2TP are:

• Control Messages - establish, maintain and clear tunnels and calls, also providing guaranteed delivery.
• Data Messages - encapsulate PPP frames being carried over the tunnel, data packets are NOT retransmitted when packet loss occurs.

IPIP (IP Encapsulation within IP)

RFC 2003 http://www.ietf.org/rfc/rfc2003.txt?number=2003 describes IPIP in detail. A (very) brief summary follows:
RFC 2003 Introduction states: "…IP datagram may be encapsulated (carried as payload) within an IP datagram." "…the encapsulated datagram arrives at this intermediate destination node, it is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original Destination Address field."

VPND (Virtual Private Network Daemon)

VPND description http://sunsite.dk/VPNd/
Overview states: "The virtual private network daemon VPNd is a daemon which connects two networks on network level either via TCP/IP or a (virtual) leased line attached to a serial interface. All data transfered between the two networks are encrypted using the unpatented free Blowfish encryption algorithm."


L2F (Cisco Layer 2 Forwarding protocol)

RFC 2341 http://www.faqs.org/rfcs/rfc2341.html
RFC 2341 Abstract states: "Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. " "…Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connectionis terminated and access to the network provided."


CIPE (Cryptographic IP Encapsulation)

Creator's protocol description at http://sites.inka.de/~bigred/devel/CIPE-Protocol.txt. A (very) brief summary follows:
CIPE is an "…ultra lightweight" IP encryption protocol to provide protected chanels of communication that are safe from eavesdropping & prevent man/monkey in the middle attacks. "Not designed to be interoperable with any other protocols or standards such as IPsec. Designed for two fixed peers (not dynamic mobile users for example).

SSH (Secure Shell) Remote Login Protocol

SSH Internet Draft by Network Working Group http://www.cise.ufl.edu/help/ssh/RFC
A protocol that provides a secure means of logging into, executing commands, and transferring files to and from a remote host.
Key features include:

• Multiple authentication options (RSA and others)
• Broad range of choices for encryption and keys technologies
• All communication encrypted
• X11 forwarding connections securely
• Flexible TCP/IP ports redirection in both directions
• Client/server based, connections initiated by client to listening server

Basically SSH is meant to be a secure replacement for the very insecure clear text tools like Telnet and FTP. It is excellent for remote administration. It is also able to perform port redirection and tunneling so that ANY service or protocol can be inside the SSH encrypted connection, providing security to services that would otherwise be wide open to clear text information sniffing.

SKIP

A technology from Sun Microsystems, RFC 2356 http://www.faqs.org/rfcs/rfc2356.html describes SKIP in detail. A (very) brief summary follows:
RFC 2356 Abstract states "…Mobile IP specification makes no provisions for securing data traffic…" [SKIP] "…allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network." "…our mechanisms…" [also] "…allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space."
Key parts of SKIP are:

• Encryption
• Authentication
• Sessionless IP security
• Mobile, dynamic users may connect (compared to other technologies that require static peers)

ENSkip

Enskip User's Guide: http://www.tik.ee.ethz.ch/~skip/ details Enskip. A (very) brief description follows:
An extension of Sun's SKIP (RFC 2356) to include strong encryption.
It is under GNU license.
Consider very "Alpha" in code development stage.

References

Source Code

< Previous Question | Back to Malware FAQ Home | Next Question >

top^