Penetration Testing IPsec VPNs
by Rohyt Belani, K. K. Mookhey
As companies expand their presence globally, there arises a need for secure electronic communications between geographically dispersed locations. Virtual private networks (VPNs) provide an economically viable option to address this need. A VPN is a private network that uses the public Internet to either connect remote users to the company's internal network or establish a seamless connection between the company's physically isolated sites. Since a VPN uses the Internet it must provide security features like encryption and strong authentication to protect the confidentiality of internal company data. Thus there are inherent security concerns when implementing VPNs.
This article discusses a methodology to assess the security posture of an organization's Ipsec based VPN architecture. The first part of the article looks at the components of IPSec based VPNs, which use client software to connect to the VPN server as opposed to SSL based VPNs, which only use a browser. The second step describes a penetration test of the VPN setup, and then finally a review of the architecture and system configuration is suggested. A comprehensive VPN assessment must account for all possible attack vectors for it to be a useful gauge of security posture.
2. Components of IPSec based VPNs
VPNs can be classified into two primary types. Site-to-Site VPNs virtually extend the corporate LAN to a company's satellite offices, and this connectivity is established between VPN gateways at each participating location. Remote Access VPNs, on the other hand, are used to provide a remote user, such as a field sales person, access to the internal corporate network from various remote locations. The two primary components that comprise this user-to-LAN connection are a VPN client software that operates on the remote user's machine and a VPN gateway that is the entry point into the company's internal network from the Internet. We will look at layer-3 IPsec VPNs that require a thick VPN client, as opposed to SSL-based VPNs that require only a browser on the client machine to establish connectivity to internal resources like file and mail servers.
IPsec is based on symmetric-key encryption and consists of the following primary security components:
3. Penetration test
The main objective of this phase is to discover any vulnerabilities in the VPN implementation that an attacker may be able to exploit. This is usually considered a zero-knowledge test where only the IP address of the VPN server is known. This phase will be shown using three steps:
The purpose of this exercise is to determine the type of VPN implementation (IPsec, PPTP, or SSL), the VPN vendor information and corresponding version numbers. This is necessary to execute a focused attack against the target VPN environment.
The first step in thereconnaissance process entails port scanning the VPN server to make an educated guess on the type of VPN implementation. The following table provides a mapping of open ports to VPN type, using default ports:
Table 1. Default ports and VPN type.
It is possible that the port scan may yield false positives. This is most likely to happen if the subject of the scan is a firewall-VPN combination device. In such cases, the firewall is likely to drop packets targeted to it, resulting in false positives.
The next step is to determine what we are up against by finding out the vendor and version of the VPN server. Nmap's operating system identification functionality provides a fair idea of the above. In the case of IPsec VPNs, ike-scan can also be used to provide a reasonably accurate fingerprint of the VPN server vendor and the version number. This tool performs the fingerprinting by checking the values of specific variables in the IPsec packets being exchanged, and compares these against its signature database.
The following is a snapshot of the execution of IKE-Scan:
If the packet exchange patterns observed by ike-scan match any of those within its signature database, it provides a best guess of the VPN server platform and outputs the data as follows:
The fingerprint information allows a potential attacker the ability to execute a more focused attack against the VPN. With this knowledge, the attacker may not only attempt platform specific exploits against the system, but may also attempt a brute-force attack using the appropriate client software.
3.2 Assessment of PSK protocol mode
Another vital attack vector is the exploitation of inherent vulnerabilities in the protocols used to establish the VPN connection. For instance, the output from ike-scan above shows us that the client and server use a pre-shared key (PSK) for authentication. Thus, if the server can be forced to use Aggressive Mode, instead of Main Mode authentication, then the authentication hash based on the pre-shared key (PSK) would be sent in clear-text. From there it is then possible to use a sniffer like tcpdump to capture the hash and attempt a dictionary or brute-force attack against it to recover the PSK.
IKEProbe can be used to determine vulnerabilities in the PSK implementation of the VPN server. It tries out various combinations of ciphers, hashes and Diffie-Helman groups and attempts to force the remote server into aggressive mode.
The following is a snapshot of IKEProbe output:
The sniffed PSK can be cracked using Cain & Abel or IKECrack. Once the PSK has been cracked, software such as PGPNet can be used to connect to the vulnerable VPN server. This is explained by Micheal Thumann (author of ike-probe) in his PSK cracking paper (PDF).
An attacker may also attempt to exploit vulnerabilities in the vendor's implementation of the specific protocols. As Bruce Schneier and N. Ferguson wrote in their paper, "A Cryptographic Evaluation of IPsec," the main problem with the IPsec protocol is its inherent complexity. Therefore, there is a strong likelihood of vendors developing buggy implementations of the protocol which are vulnerable to attack.
The following is a list of well-known VPN/IKE vulnerabilities from the SecurityFocus Vulnerabilities database. There are likely others as well that have not been reported yet.
The first of these, for instance, was discovered by the author during a routine penetration test of a client's VPN server. As shown below, when connecting with the VPN client of a Nortel Contivity Server, the responses displayed for a valid username (but invalid password) is different than that for an invalid username.
The first screenshot, Figure 1, uses the valid username test and shows the following error:
View Inline Image Figure 1. Nortel VPN client with valid username.
However, if we use an account such as test123, which does not exist, the error message shown is:
View Inline Image Figure 2. Client shows username does not exist.
This vulnerability may be used by an attacker to enumerate usernames of valid VPN accounts.
3.3 Exploitation of any default user accounts
One of the common vulnerabilities in the implementation of any system is the presence of default system accounts with default passwords. VPN systems are no exception. A good source of default account names and passwords can be found through various means. Besides the usual suspects such as vendor-name, setup, vpn, client, user, contivity, fw1, netscreen, and admin, the assessor should also try the names of the cities/towns where the remote offices are located. It is not uncommon for remote office users from the London office, for example, to have the username london!
In addition to blind penetration testing (without a valid user account), assessing the VPN using a valid user account ID provides added value. This normally yields a larger number of critical vulnerabilities than the blind penetration testing phase. This can be attributed to the added VPN functionality and attack surface exposed to an authenticated user as compared to a zero-knowledge attacker. The primary focus of this phase is to ensure that the extent of access granted to VPN users is limited as per stipulated corporate policies.
4. Configuration and architecture review
To perform a thorough VPN assessment it is critical that one review the network architecture and configuration of the VPN. Some of the issues that should be evaluated are:
VPNs are commonly ignored during a vulnerability assessment, due to the myth that they are inherently secure. While VPNs do provide a means for secure communication, if they are incorrectly configured they are still vulnerable, just as any other Internet-facing system. The compromise of a VPN server may have an extremely negative impact on the organization's business as it may provide unauthorized access to internal company resources. Thus, organizations should pay special attention to the design, implementation, configuration and assessment of VPN systems, and ensure a proper penetration test has been completed.
|View Inline Image
About the authors
Rohyt Belani is a Director at Red Cliff Consulting, an information security company offering professional services targeting proactive and reactive security initiatives. K. K. Mookhey is the CTO and Founder of Network Intelligence India.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.