Technical Note 01/07. Issued 4 January IPsec VPN Security Guide. Understanding and Preventing IPsec VPN Vulnerabilities

Transcription

1 Technical Note 01/07 Issued 4 January 2007 IPsec VPN Security Guide Understanding and Preventing IPsec VPN Vulnerabilities This paper concerns vulnerabilities in cryptographic Virtual Private Networks (VPNs) that use IP security (IPsec). It details the common VPN flaws, gives examples which demonstrate these flaws, and explains the root causes. It also outlines how to set up IPsec VPNs in a secure manner to avoid these common problems. It is NISCC s view that VPNs are commonly used in the UK CNI. It assumes a detailed knowledge of the IPsec VPN protocol suite, and is written for a technical audience. National Infrastructure Tel: Security Co-ordination Centre Fax: PO Box enquiries@niscc.gov.uk London, SW1P 1BG Web: Version 1.1

2 Disclaimer Reference to any specific commercial product, process or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NISCC. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. To the fullest extent permitted by law, NISCC accepts no liability for any loss or damage (whether direct, indirect or consequential and including, but not limited to, loss of profits or anticipated profits, loss of data, business or goodwill) incurred by any person and howsoever caused arising from or connected with any error or omission in this document or from any person acting, omitting to act or refraining from acting upon, or otherwise using, the information contained in this document or its references. You should make your own judgement as regards use of this document and seek independent professional advice on your particular circumstances. 2

3 Contents Contents... 3 Key Points... 4 Introduction... 4 VPNs are Attractive Targets... 4 Common VPN Issues... 5 VPN Fingerprinting... 5 Insecure Storage of Authentication Credentials by VPN Clients... 6 Username Enumeration Vulnerabilities... 7 Offline Password Cracking Man-in-the-Middle Attacks Lack of Account Lockout Denial of Service Attacks Poor Default Configurations Poor Guidance and Documentation Why do VPN Servers Have Vulnerabilities? Complex Software Poor Defaults Poor Documentation Lack of IPsec Understanding Setting up secure VPNs Separate Firewall and VPN functions Don t Rely on Client Settings Never use manual IPsec Disable IKE Aggressive Mode Don't use pre-shared key authentication Always use PFS Disable weak encryption and plain AH Ensure ESP is used with auth or together with AH Don't allow unrestricted VPN access Keep the VPN server patched Test the VPN server Conclusions References About the author

4 Key Points VPNs are attractive targets for many threat agents. The majority of VPN systems have significant vulnerabilities. Most vulnerabilities are not contained in the cryptographic algorithms; they are caused by poor configuration or implementation and may be mitigated by best practice. VPN servers have the same software problems as other products and VPNs should be tested to ensure their security. Introduction This paper concerns vulnerabilities in cryptographic Virtual Private Networks (VPNs) that use IP security (IPsec). It details the common VPN flaws, gives examples which demonstrate these flaws, and explains the root causes. Many of the vulnerabilities described in this paper concern Phase 1 of the Internet Key Exchange (IKE) protocol. The vulnerabilities apply equally, therefore, to the use of IPSec in transport and in tunnel mode. The paper assumes a detailed knowledge of the IPsec VPN protocol suite, and written for a knowledgeable and technical audience. It also outlines how to set up IPsec VPNs in a secure manner to avoid these common problems. It is NISCC s view that VPNs are commonly used in the UK CNI. VPNs are Attractive Targets VPNs are attractive targets for a variety of threat agents. The reasons for this include the following: 1. VPNs carry sensitive information over an insecure network. The users generally trust the VPN to keep the information secure, which is understandable because that is what the VPN is designed to do. Because of this trust, the users will transfer sensitive data without using additional encryption, and use protocols that transmit authentication credentials in the clear. 2. VPNs often allow full access to the internal network. Many organisations configure their VPNs to allow full access to the internal network for VPN users. This means that if the VPN is compromised, then the attacker gets full access to the internal network too. 3. VPN traffic is often invisible to Intrusion Detection System (IDS) monitoring. If the IDS probe is outside the VPN server, as is often the case, then the IDS cannot see the traffic within the VPN tunnel because it is encrypted. Therefore if a hacker gains access to the VPN, he can attack the internal systems without being picked up by the IDS. 4. Increasing security in other areas. 4

5 As more organisations install firewalls, move Internet servers onto the Demilitarised Zone (DMZ), automatically patch servers etc., the VPN becomes a more tempting target. Common VPN Issues VPN Fingerprinting Most VPN servers can be fingerprinted by User Datagram Protocol (UDP) backoff fingerprinting, Vendor identity (ID) fingerprinting or other fingerprinting methods. While this is not a problem by itself (and some vendors do not consider it a problem at all), it does give useful information to potential attackers. Some systems will reveal the general type of device, e.g. "Cisco PIX" or "Nortel Contivity", whereas others will show the software version details as well. Knowledge of the device type and software version allows an attacker to target any known weaknesses in that particular product. Here is an example showing both backoff fingerprinting and Vendor ID fingerprinting. The backoff pattern indicates that the system is Checkpoint Firewall-1, and the Vendor ID confirms this and also identifies the version as NGX. $ ike-scan --trans=5,2,3,2 -M --showbackoff Starting ike-scan with 1 hosts ( Main Mode Handshake returned HDR=(CKY-R=ec98b7ea767f3242) SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x ) VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f d45619c (Firewall-1 NGX) IKE Backoff Patterns: IP Address No. Recv time Delta Time Implementation guess: Firewall-1 4.1/NG/NGX More details of the backoff fingerprinting technique can be found in the UDP Backoff Pattern Fingerprinting White Paper [1], and more details of a Vendor ID fingerprinting issue are in the Firewall-1 Vendor ID Fingerprinting advisory [2] 5

6 Insecure Storage of Authentication Credentials by VPN Clients Many VPN client programs offer to store some or all of the authentication credentials (e.g. username and password), and for some clients, this is the default setting. While this makes the VPN easier to use it also introduces security risks, especially if the credentials are not well protected. The common client issues that have been seen are as follows: 1. Storing the username unencrypted in a file or the registry. Anyone with access to the client computer can obtain the username. If the VPN is using IKE Aggressive Mode, then knowledge of the username allows an offline cracking attack against the password as described later. 2. Storing the password in a scrambled form. This is often referred to as "encryption", but it is really obfuscation rather than encryption because there is no unique key needed to decrypt it. If the obfuscation algorithm becomes known, then it is a simple matter to obtain the password if you have access to the client computer. The screenshot below shows an example of both the plain-text username and also the obfuscated password stored in the registry. 3. Storing the plain-text password in memory. If storing an obfuscated version of the password in a file or registry is not bad enough, many clients decrypt this password when they start up, and store a plaintext version of the password in memory. In this case, anyone with access to the client computer can obtain the password by starting the VPN client and then dumping the process memory with a tool such as pmdump, or crashing the computer to get a dump of physical memory. The screenshot below shows an example memory dump from a VPN client with the clear-text password 6

7 W0ntGu355Th15 highlighted. Notice that the last two characters of the password are repeated in the memory dump. This is repeatable behaviour for this VPN client, and may give some insight into the obfuscation mechanism. 4. Weak registry or file permissions for stored credentials. It is a bad idea to cache credentials at all, but this is made worse if they are stored in a file or registry entry that is readable by everybody. This allows these details to be obtained from guest or anonymous network connections as well as via administrator-level access to the client system. Username Enumeration Vulnerabilities Many remote access VPNs use IKE Aggressive Mode with Pre-Shared Key (PSK) authentication as the default authentication method. The PSK authentication method is essentially the well-known username/password authentication scheme, although the terminology used can be different, for example the username is sometimes known as the id or groupname, and the password is sometimes referred to as the secret or pre-shared key. 7

8 One of the basic security requirements of a username/password authentication scheme such as this is that the response to an incorrect login attempt should not leak information about which of the credentials (username or password) was incorrect, because this would allow an attacker to deduce whether a given username is valid or not. This requirement has been known for at least 25 years. The first known reference to this is in the November 1979 Morris Password Security paper [3] which discusses the authentication security of the Unix V7 operating system. In all: To login successfully on the UNIX system, it is necessary after dialling in to type a valid user name, and then the correct password for that user name. It is poor design to write the login command in such a way that it tells an interloper when he has typed in a invalid user name. The response to an invalid name should be identical to that for a valid name. When the slow encryption algorithm was first implemented, the encryption was done only if the user name was valid, because otherwise there was no encrypted password to compare with the supplied password. The result was that the response was delayed by about one half second if the name was valid, but was immediate if invalid. The bad guy could find out whether a particular user name was valid. The routine was modified to do the encryption in either case. Although this security requirement has been known for decades, many implementations of PSK authentication do not abide by it and give a different response for an invalid username than for a valid one. The diagram below shows the initial packet exchange for aggressive mode PSK authentication. In this exchange, the client sends an IKE packet to the VPN server, and the VPN server responds with an IKE packet. Both packets contain several Internet Security Association and Key Management Protocol (ISAKMP) payloads, but the important ones for this discussion are the Identity payload sent by the client, which contains the username, and the Hash payload sent by the server, which is an Hashed Message Authentication Code (HMAC) [4] of various things including the password (pre-shared key). The contents of the hash payload sent from the server are discussed in detail in the offline password cracking section below. In a real authentication, the client would then respond with a third packet containing an HMAC of various things including the password, but this discussion is only concerned with the first two packets. 8

9 Three common faults were found in the way that VPN servers respond to the first packet from the client: 1. some VPN servers only respond to the client if the username is valid, they do not respond at all to invalid usernames; 2. some VPN servers will respond with a notification message, e.g. no-proposalchosen, if the username is incorrect; and 3. some VPN servers respond to both valid and invalid usernames, but the hash payload for invalid usernames is calculated using a null password, and it is trivial for the client to determine this. In all three cases, the response to an invalid username is different to that for a valid username, and this allows the client to determine if a given username is valid or not. The correct way for the VPN server to respond to an invalid username is for it to respond using a random password for the hash payload, which is simple to implement, and does not allow the client to determine if a username is valid or not. An example of this issue is shown below. In this example, ike-scan is used to demonstrate that the VPN server responds to valid usernames normally, but to invalid usernames with a notify message. This shows that, for this VPN server, the username fred is valid, but the username jim is not. $ ike-scan --aggressive --id=fred Starting ike-scan 1.7 with 1 hosts ( Aggressive Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x ) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_IPV4_ADDR, Value= ) Hash(20 bytes) $ ike-scan --aggressive --id=jim Starting ike-scan 1.7 with 1 hosts ( 9

10 Notify message 14 (NO-PROPOSAL-CHOSEN) This information leakage can be of great help to an attacker. Because usernames are often based on people's names or addresses, it is easier than you would think to mount a successful dictionary attack. Once the first valid username is found in this way, the format of the usernames is known, and it is even easier to find other valid usernames. Offline Password Cracking Once a valid username is obtained using IKE Aggressive Mode, it is then possible to obtain a hash from the VPN server and use this hash to mount an offline attack to crack the associated password. As shown in the packet exchange diagram above, the packet returned from the VPN server to the client contains, among other things, a hash payload which is known as the responder hash (because the client is the initiator and the VPN server is the responder) or hash_r. The construction of hash_r is defined by RFC 2409 [5] as: hash_r = prf(skeyid,gx^r gx^i cky_r cky_i SAi_b IDir_b) and skeyid is defined as: skeyid = prf(psk, Ni_b Nr_b) where the terms used are: prf The pseudo-random HMAC function gx_r The responder (VPN Server) public Diffie-Hellman value (in the key exchange payload) gx_i The initiator (VPN client) public Diffie-Hellman value (in the key exchange payload) cky_r The responder (VPN Server) ISAKMP cookie (in the ISAKMP header) cky_i The initiator (VPN client) ISAKMP cookie (in the ISAKMP header) SAi_b The body of the initiator (VPN client) SA payload IDir_b The body of the responder (VPN Server) ID payload Ni_b The body of the initiator (VPN client) nonce payload Nr_b The body of the responder (VPN Server) nonce payload psk The Pre-Shared Key (password) All of the values above, apart from psk, are contained in the first initiator and responder IKE packets, which are not encrypted. So these values can be obtained from the packets and then the same functions used to calculate a hash using a preshared key of our choice and see if our calculated hash matches the one from the VPN server. To perform the offline dictionary attack, a list of candidate passwords is taken, and each one is run through the hash function. The resulting hash is then compared with the hash that the server sent, and if they match then the correct password has been 10

11 found. Because this is an offline attack, it does not cause any entries in the VPN server log, nor would it trigger account lockout. This attack is very fast: typically several hundreds of thousands of guesses per second. Some speed figures for the pre-shared-key cracking tool psk-crack are shown in the table below. The PSK cracking speed achievable depends mainly on the underlying hash performance: each PSK calculation consists of two HMAC calculations, and each HMAC calculation consists of two hash calculations (either MD5 or SHA1 depending on the hash algorithm used), therefore the PSK cracking speed should be approximately one quarter of the hash speed. The table below shows the maximum time required for a brute-force attack against various password complexities using a single AMD Athlon XP system. Password Complexity Number of Combinations Brute Force Time 6 characters a-z 309 Million 16 minutes 6 characters a-z, A-Z, Billion 2 days 8 characters a-z 209 Billion 8 days 8 characters a-z, A-Z, Trillion 22 years Below is an example that shows how ike-scan can be used with a valid username (in this case the username fred, which we found earlier) to obtain the PSK parameters and write them to a file (fred.psk). The example also shows how psk-crack can be used to perform a dictionary attack against these PSK parameters to obtain the password. $ ike-scan --aggressive --id=fred --pskcrack=fred.psk Starting ike-scan 1.7 with 1 hosts ( Aggressive Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x ) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_IPV4_ADDR, Value= ) Hash(20 bytes) $ psk-crack fred.psk Starting psk-crack in dictionary cracking mode key "Liverpool" matches SHA1 hash 1f074be2ce5a3128aea49a4f4fb7752f9fe33670 Ending psk-crack: iterations in seconds ( iterations /sec) Once a valid username and the associated password have been obtained, we can use this to complete IKE Phase-1 and establish an ISAKMP Security Association (SA) with the VPN Server. For some VPN servers, this is all that is required to gain access to the VPN, while others have an additional authentication step such as XAUTH [6] that must be completed after IKE Phase-1. Man-in-the-Middle Attacks If the VPN server is using IKE Aggressive Mode, and it is possible to determine a valid username and password, then an ISAKMP SA can be established to the VPN server. Even if the VPN server enforces a second level of authentication, this often relies on the security of this ISAKMP SA. In this case, if it is possible to establish an ISAKMP SA then the second level of authentication would not provide complete protection because it would be vulnerable to a man-in-the-middle attack. This risk is acknowledged in the XAUTH IETF draft: 11

12 The protocol described in this memo strictly extends the authentication methods described in [IKE]. It does not in any way affect the authenticated nature of the phase 1 security association. In fact, this protocol heavily relies on the authenticated nature of the phase 1 SA. Without complete phase 1 authentication, this protocol does not provide any authentication at all, since it becomes easily vulnerable to Man-in-the- Middle (MitM) attacks. An example scenario showing how this could be exploited against a VPN server using XAUTH is given below. 1. Install the MitM system in the path of the VPN Client/Server traffic. Installing the system on an Ethernet link that the traffic flows over, and using ARP spoofing to re-direct the traffic could achieve this. In this position, the MitM system could sniff the usernames (which are passed in the clear) and crack the passwords using the information in the 1st and 2nd packets. Alternatively, it could be fed a list of usernames and passwords that had previously been obtained by group name enumeration and password cracking. 2. When the real client connects, allow them to establish an ISAKMP SA to the MitM system, and establish a second ISAKMP SA from the MitM system to the VPN server. The client user thinks he is connected to the VPN server, but is really connected to the MitM system. An ISAKMP SA can be established from the MitM system to the VPN server because the username and password are known. 3. The VPN server will issue an XAUTH challenge to the MitM system. The MitM system passes this on to the client. 4. The client sends the response (e.g. second username and SecurID PIN + passcode) to the MitM system, which passes it on to the VPN server. 5. Now the client is connected to the MitM system, and the MitM system is fully authenticated to the VPN server. At this point, the VPN security is breached. The MitM system has three options: 1. Intercept and log traffic between the client and VPN server; 2. Alter traffic between the client and VPN server; or 3. Drop the connection with the client and proceed to complete IKE Phase-2 with the VPN server and gain access to the internal resources. Lack of Account Lockout Most general purpose operating systems allow accounts to be locked out after a certain number of incorrect login attempts. However, many VPN implementations do not support this and allow an unlimited number of login attempts. Account lockout, like the prevention of username information leakage mentioned in the username enumeration vulnerabilities section, has been a recognised part of authentication for many years (for example, it was used on VAX/VMS systems in the 1980s), and it is often assumed when evaluating authentication strength. 12

13 Denial of Service Attacks Two types of Denial of Service (DoS) vulnerabilities have been observed on IPsec VPN servers. 1. Malformed packet DoS This is where an IKE packet does not conform to the RFC specifications, for example if the claimed payload lengths are incorrect. In some implementations, this causes a buffer overflow condition which results in the IKE process terminating. It is possible that this could be further exploited to run arbitrary code on the VPN server, but this has not been investigated. 2. Resource Exhaustion DoS This attack sends a large number of IKE packets, which causes the VPN server to run out of negotiation slots. This means that the server is unable to process legitimate VPN connections. Because IKE uses the UDP transport, it is possible to spoof the source IP address of the DoS traffic, which makes both detecting the true source of the traffic and also blocking the DoS traffic difficult. This is a similar concept to the TCP SYN flood attack that was a problem around Poor Default Configurations All too frequently, the default "out of the box" configuration for a VPN server is geared towards usability rather than security. Typically the default authentication method for remote access VPNs is IKE Aggressive Mode with pre-shared keys, even when stronger authentication methods such as Main Mode with certificates are available. IKE Aggressive Mode with pre-shared key authentication has known issues, which have been detailed in previous sections. The end-users generally assume that the default configuration is secure because they trust the vendor to choose sensible defaults, and there is nothing to indicate to them that there is any security vulnerability unless they get tested or hacked. The default configurations also normally include support for many different ciphers and modes, so you will often see a combination of strong and weak ciphers supported, or both Encapsulating Security Payload (ESP) and Authentication Header (AH) (which does not encrypt the traffic when used alone) being supported. In these cases, someone with access to the client system (either directly, or over the network) could re-configure the client to use a weak cipher that could be easily cracked (it would not take long to crack a 40-bit export-grade cipher with modern equipment), or worse to use AH which passes the traffic in the clear. The user would almost certainly never notice the change because the VPN works just the same, and who bothers to manually check the tunnel mode and encryption ciphers after every connection? Poor Guidance and Documentation Many VPN implementations do not provide sufficient guidance and documentation to allow the end-user to make informed decisions about which configuration to use. 13

14 Some examples of areas where guidance would be helpful but is very rarely given are: 1. Use of weak ciphers such as export-grade or single DES, which can be cracked relatively easily; 2. Use of weak authentication mechanisms such as pre-shared key with IKE Aggressive Mode, which transmits the username in the clear, and is vulnerable offline password cracking if a valid username is known; and 3. Selection of the AH protocol alone, which doesn't encrypt the VPN traffic at all. Typically there are no warnings about these things in the documentation, and usually there is no warning message when these options are selected in the configuration program either. This means that users do not know what options are safe and what ones are risky. This is not a good state of affairs for such a critical part of the security perimeter. Why do VPN Servers Have Vulnerabilities? Complex Software IPsec VPN systems, especially the IKE processing part, are complex software applications. Unfortunately, current commercial software engineering practice is not able to produce complex applications that are bug free. Almost all complex software products that are routinely exposed to untrusted networks have been found to contain security bugs. IPsec VPN systems are no exception. Poor Defaults As mentioned above, many VPN servers come with poor defaults. It is well known that users tend to leave systems with the default settings, so it is common to see VPN systems using insecure default settings. Poor Documentation As previously mentioned, the vendor supplied documentation is often poor, and this often leaves users struggling. The result is often systems left at the default configuration or badly configured. Lack of IPsec Understanding Not many people have a good understanding of IPsec, and unfortunately this knowledge is often necessary to set up VPNs in a secure manner. The problem is that IPsec is a complex protocol, and most people will only meet it occasionally. Ideally, in-depth knowledge of IPsec should not be necessary, but until IPsec implementations become easier to configure and have more secure defaults it will continue to be required. 14

15 Setting up secure VPNs Separate Firewall and VPN functions Although most firewall products also contain IPsec VPN functionality, given the vulnerabilities that have been found in many VPN implementations you should be wary of using your firewall as the VPN server. Buffer overflow vulnerabilities have been discovered in VPN products, for example the malformed packet DoS in Nortel s Contivity product, and these vulnerabilities could either bring the firewall down, or in a worst case scenario allow arbitrary code to be run on the firewall. IPsec implementations are complex pieces of software, and history has shown that exposing complex software applications to untrusted networks is risky. You can reduce the risk by separating the firewall and VPN functions. Typically, you would place the VPN server on a DMZ network, which allows the firewall to control the VPN tunnelled traffic between the untrusted network and the VPN server, and also to control the user traffic between the VPN server and the internal network. By doing this, you limit the scope of any attack, and can maintain control over the VPN traffic at all times. There is also the added benefit of offloading the VPN work from the firewall. Don t Rely on Client Settings Your VPN server should not depend on correct client settings to operate securely, because it is possible that an attacker may pose as a client, or the client may be compromised. You should ensure that the server only supports secure settings for those attributes that are negotiated with the client, such as encryption algorithm, hash algorithm, Diffie-Hellman group and SA lifetime. These settings are covered in more detail later. Never use manual IPsec Many implementations support manual IPsec, where static security associations (SAs) are established without requiring the use of IKE. You should never use manual IPsec mode, as it does not provide any support for rekeying the VPN. This makes manual IPsec VPNs much more susceptible to cipherbased attacks. Manual IPsec was included in the IPsec specifications because IKE was new and untested at the time. All modern implementations now include IKE, so there is no longer any need to use manual IPsec. Disable IKE Aggressive Mode Some of the biggest problems come from the use of IKE Aggressive Mode for Phase- 1. Aggressive Mode has several known limitations, including passing the identity (which is often the username) in the clear, and many implementations have bugs in the Aggressive Mode implementation which allows username enumeration and 15

16 subsequent offline password cracking. Disabling Aggressive Mode support avoids these problems. Note that Aggressive Mode is required for remote access VPNs using pre-shared key (username/password) authentication, because of the way the keying material is generated. In order to disable Aggressive Mode, any remote access VPNs will need to use certificate authentication rather than pre-shared key. In general, this is a good thing, as certificate authentication is stronger than pre-shared key; however, it requires more work to set up the necessary infrastructure. Don't use pre-shared key authentication Pre-shared key authentication (username/password) is a relatively weak authentication mechanism. You should use certificate authentication instead. Certificate authentication can be more difficult to setup, but it is more secure, and permits the use of IKE Main Mode for remote access connections. Always use Perfect Forward Secrecy Most VPN implementations support the use of Perfect Forward Secrecy (PFS) in IKE Phase-2. This option is often disabled by default. You should always use this option, as it ensures that the IPsec SAs that are negotiated by Phase-2 use fresh keying material rather than being derived from the ISAKMP SA keying material. This provides an extra layer of security, which prevents the IPsec keys being discovered even if the ISAKMP SA is compromised. Disable weak encryption and plain AH You should ensure that the server does not support weak encryption algorithms or Diffie-Hellman groups, and does not support the use of AH alone as this does not encrypt the VPN data. By disabling weak or no encryption, you prevent any possibility of a VPN client using weak encryption. Even though clients will normally negotiate strong encryption, it is possible that a compromised client might be altered to deliberately negotiate weak encryption which an attacker would be able to crack. You should ensure that Single DES encryption and Diffie-Hellman group 1 are disabled, as they are both considered weak. You should also disable the use of AH alone, as this does not provide any encryption unless it is used together with ESP. Ensure ESP is used with auth or together with AH It is important that the IPsec SA includes both encryption and authentication. Some implementations allow the use of ESP without any authentication, and this must be avoided because it allows a malicious third party to alter the data without being detected. You should ensure that the IPsec SA that is negotiated in IKE Phase-2 includes authentication (typically an MD5 or SHA1 based HMAC), or that both ESP and AH are used. 16

17 Don't allow unrestricted VPN access You should not allow unrestricted access to your internal network via the VPN. By limiting access to only those systems and services that are required, you can minimise the damage done if the VPN is compromised. This restriction is best applied using a firewall behind the VPN server, as is the case when the VPN server is located on a DMZ segment. It is also possible to restrict the traffic using the VPN server itself, and this sometimes allows a finer granularity of control (e.g. allowing different access depending on user group); however, it should be remembered that VPN server based restriction could be bypassed if the VPN server is compromised. Keep the VPN server patched As the VPN server allows access to a complex software application from an untrusted network, it should be kept patched up to date in the same way that any other internet-visible server would be. Unfortunately, most VPN servers don t have automatic update services like most general purpose operating systems do, so you will need to have a procedure for regularly checking for and applying updates. The usual caveats for updates apply: you should test them in a development environment first in case they affect VPN functionality. Test the VPN server It is important to test the VPN server after it has been configured to ensure that it behaves as intended. Testing is important because the configuration is complex, the documentation is sometimes misleading, and some VPN servers have been observed not to obey the configuration settings. Conclusions VPN systems are not the invulnerable systems that they are often believed to be. The majority of remote access VPN systems that have been tested had significant security issues, and it has been possible to demonstrate a full compromise on a large proportion of these vulnerable systems. Some of the common issues that have been found are detailed in the earlier sections, but the root causes of these can be summarised as follows. 1. The real-world VPN security issues are rarely in the cryptographic algorithms. A lot of attention is focused on the cryptography, but in practice, the security problems are not normally in the cryptographic algorithms that are used; the vulnerabilities are generally caused by poor configuration or bad implementation rather than the cryptography. This focus on cryptography is a problem for two reasons: a) people frequently associate the security of the cryptographic algorithms with the security of the VPN system as a whole and therefore assume that 17

18 the VPN is unbreakable "because it uses 3DES which would take billions of years to crack"; and b) people spend too much time worrying about the cryptographic algorithms (e.g. "should we use 3DES or AES?") when they should be worrying about other areas. 2. Well accepted security practices are not always used by VPN vendors. Things like not leaking information about valid usernames and locking out accounts after a number of failed attempts have been practiced by operating system login authentication for many years, but these are not yet routinely included in VPN products. 3. Default configurations are often chosen for ease-of-use rather than security. For example many remote access VPNs use IKE Aggressive Mode with preshared key authentication as the default configuration, although they may also support the stronger Main Mode with certificates. This is worrying because users will tend to use the default configurations, and they will understandably expect these defaults to be sensible and secure. 4. Customers do not always understand the configuration options. The configuration options are often difficult to understand by the end-user, and there is often no guidance as to what configurations are potentially insecure. For example, if you choose pre-shared key authentication with IKE Aggressive Mode, most implementations will not warn you of the known problems that are inherent in this method. There is also often little guidance in the documentation. 5. VPN servers have the same software problems as other complex software products. Although this paper has not talked in detail about buffer overflows and similar issues, such bugs have been found during VPN testing. This should not come as a surprise to anyone, but it is worth pointing out that it should not be assumed that VPN implementations are somehow exempt from the software bugs that plague other complex products. 6. VPNs should be tested to ensure that they are secure. In view of the vulnerabilities and configuration pitfalls in IPsec VPN systems, it makes sense to test the implementation in the same way that you would with other systems that were exposed to untrusted networks. However, good configuration together with sound network design can eliminate many of the issues and alleviate those that remain. References [1] R. Hills, "NTA Monitor UDP Backoff Pattern Fingerprinting White Paper", January [2] R. Hills, "Firewall-1 Vendor ID Fingerprinting", January

19 [3] R. Morris and K. Thompson, "Password Security: A Case History", Communications of the ACM, Vol.22, No.11, November, 1979, pp [4] H. Krawczyk, M Bellare and R. Canetti, RFC 2104 "HMAC: Keyed-Hashing for Message Authentication", February [5] D. Harkins and D. Carrel, RFC 2409 "The Internet Key Exchange (IKE)", November [6] R. Pereira and S. Beaulieu, Extended Authentication within ISAKMP/Oakley (XAUTH), December About the author This paper was written by Roy Hills of NTA Monitor ( NTA Monitor provides IT security testing and consultancy services and was a founder member of the CESG CHECK scheme. NTA is one of the few companies that uses and develops its own penetration testing tools, some of which are released as open source under the GPL licence. The company's services include penetration testing, application testing, VPN security testing, wireless testing and onsite auditing. NTA regularly finds new vulnerabilities through its test projects and research and development programmes. 19