Weak IKE Security Configurations

Description

The remote VPN servers are configured with weak security settings such as the use of IKE version 1, the use of aggressive mode with a Pre-Shared Key (PSK), and the implementation of SHA1 as the hashing algorithm and 3DES as their encryption algorithm.

These security settings are considered weak. The aggressive mode of IKE does not use a key distribution algorithm like Diffie-Hellman to protect the authentication data exchange. Aggressive Mode only uses a three-way handshake versus a six-way handshake for Main Mode. In doing so, the VPN device or 'responder' sends the hashed PSK to the "initiator" unencrypted. This makes it possible for the attacker to capture the authentication data. A server that works with aggressive mode will send the authentication hash in clear text, which can be captured and cracked offline. It should be noted that a correct group ID must be specified for it to be possible to correctly crack the hash. In this case, Illumant was not able to guess the correct group IP for the VPN to be able to retrieve a legitimate hash.

Moreover, The SHA1 hashing algorithm is vulnerable to a collision attack and is considered weak. This weakness may allow an attacker to impersonate a valid service or perform a man-in-the-middle attack. IKE supports SHA2-256, SHA2-384, and SHA2-512 in many implementations, which are not vulnerable to collision attacks. Furthermore, as large-scale computing becomes faster and more accessible, weak cipher suites become increasingly vulnerable to decryption by attackers in a privileged network position. An attacker that can capture traffic could later perform a brute-force attack to recover the encryption key and decrypt the traffic. IKE supports AES-192, and AES-256 in many implementations, which are considerably more secure.

The following output from the iker tool (a port of the ike-scan tool) shows the weak security configurations on one of the sample affected VPN concentrators:

<ike-scan> and <iker> output

As shown above, even though a hash is always returned, a valid, crackable hash will only be returned when the request is made with a valid group name. Even when the VPN PSK is known, often a second factor of authentication is required (such as domain authentication) to gain VPN access. These factors reduce the likelihood that this vulnerability could be successfully exploited.

References:

• https://www.cisco.com/en/US/tech/tk583/tk372/technologies_security_notice09186a008016b57f.html

• https://www.ernw.de/download/pskattack.pdf

• https://web.archive.org/web/20131031201444/http://www.vpnc.org/ietf-ipsec/99.ipsec/msg01451.html

• https://www.securityfocus.com/bid/7423

Recommendations:

It is advised to disable aggressive mode on the device if it is not required to be in use. In addition, utilize access control lists to only allow authorized VPN peers to connect to the affected servers. If possible, do not utilize pre-shared keys for authentication. If pre-shared keys must be used, utilize strong pre-shared keys that are greater than 14 characters in length and include lowercase letters, uppercase letters, numbers, and special characters. Moreover, it is recommended to set the ISAKMP/IKE setting as per the recommended CNSSP guidelines as follows:

• Diffie-Hellman Group: 16

• Encryption: AES-256

• Hash: SHA-384

Furthermore, many vendors also support configuring multiple IPsec policies; however, these policies are normally explicitly configured for a specific VPN. It is recommended to utilize the strongest FIPS-validated cryptography suites supported by the device. Similar to ISAKMP/IKE, the recommended IPsec setting as per CNSSP is as follows:

• Encryption: AES-256

• Hash: SHA-384

• Block Cipher Mode: CBC