Many VPN implementations do not provide sufficient guidance and documenta-tion to allow the end-user to make informed decisions about which configuradocumenta-tion to use. Some examples of areas where guidance would be helpful but is very rarely given are:
• Use of weak ciphers such as export-grade or single DES, which can be cracked relatively easily;
• Use of weak authentication mechanisms such as pre-shared key with IKE Aggressive Mode, which transmits the username in the clear, and is
vulner-• Selection of the AH protocol, which doesn’t encrypt the VPN traffic at all.
Typically there are no warnings about these things in the documentation, and usu-ally there is no warning message when these options are selected in the configu-ration 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. Vendors should not assume that the end-user will understand the details and security characteristics of IPsec and IKE.
4 Conclusions
VPN systems are not the invulnerable systems that they are often believed to be.
The vast majority of remote access VPN systems that have been tested by NTA Monitor (about 90%) have had significant security issues, and it has been possi-ble to demonstrate a full compromise on a large proportion of these vulnerapossi-ble 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:
• The real-world VPN security issues are rarely in the cryptographic algo-rithms.
A lot of attention is focused on the cryptography, but in practice, the se-curity 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:
– People frequently associate the security of the cryptographic algo-rithms with the security of the VPN system as a whole and therefore assume that the VPN is unbreakable “because it uses 3DES which would take billions of years to crack”; and
– People spend too much time worrying about the cryptographic algo-rithms (e.g. “should we use 3DES or AES?”) when they should be worrying about other areas.
• 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 decades, so why do so many VPN imple-mentations not bother?
• Default configurations are often chosen for ease-of-use rather than security.
For example many remote access VPNs use IKE Aggressive Mode with pre-shared key authentication as the default configuration, although they may also support the stronger Main Mode with certificates. This is worry-ing because users will tend to use the default configurations, and they will understandably expect these defaults to be sensible and secure. It could be argued that vendors are failing their customers by choosing insecure default configurations.
• 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 in-secure. 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. See this bugtraq post for an example of this lack of documentation:
http://www.securityfocus.com/archive/1/291340/2002-09-01/2002-09-07/2 [7]
• VPN servers have the same software problems as other complex software products.
Although this paper has not talked in detail about buffer overflows and simi-lar issues, some instances of software bugs which could have security impli-cations have been found during VPN security testing. This should not come as a surprise to anyone, but it is worth pointing out that it should not be as-sumed that VPN implementations are somehow exempt from the software bugs that plague other complex products.
• VPNs should be tested to ensure that they are secure.
In the three years that NTA Monitor have been performing VPN testing, about 90% of the sites with remote access IPsec VPNs that were tested had significant vulnerabilities. These were mainly large organisations including financial institutions who had their own in-house security teams. Given this situation, do not blindly trust that your VPN is secure.
You can useike-scanto help you test the VPN but, like many testing tools, you should be aware that it is quite a complex tool that needs to be fully understood in order for it to be used effectively.
References
[1] R. Hills, “NTA Monitor UDP Backoff Pattern Fingerprinting White Paper”, http://www.nta-monitor.com/ike-scan/whitepaper.pdf, January 2003.
[2] R. Hills, “Firewall-1 Vendor ID Fingerprinting”, http://www.nta-monitor.com/news/checkpoint2004/index.htm, May 2004.
[3] R. Morris and K. Thompson, “Password Security: A Case History”, Commu-nications of the ACM, Vol.22, No.11, November, 1979, pp.594-597.
[4] H. Krawczyk, M Bellare and R. Canetti, RFC 2104 “HMAC: Keyed-Hashing for Message Authentication”, February 1997.
[5] D. Harkins and D. Carrel, RFC 2409 “The Internet Key Exchange (IKE)”, November 1998.
[6] R. Pereira and S. Beaulieu, Extended Authentication within ISAKMP/Oakley (XAUTH), December 1999.
[7] R. Hills, “SecuRemote usernames can be guessed or sniffed using IKE ex-change”, Bugtraq Mailing List, September 2002.