RE: SecuRemote usernames can be guessed or sniffed using IKE exchange

["Scott Walker Register" <scott.register () us checkpoint com>]

Check Point Statement on use of IKE Aggressive Mode:

A document has recently been published alleging vulnerabilities in the Check
Point VPN-1/FireWall-1 product, involving the use of SecuRemote/SecureClient
and IKE Aggressive mode.  Check Point does not recommend the use of IKE
Aggressive Mode, because of many well-known limitations in the protocol, and
the Check Point products offer much more secure alternatives.

In the vulnerability claim document, two issues were presented:
  1) usernames are passed in cleartext using IKE Aggressive Mode
  2) usernames are susceptible to brute-force guessing when using IKE
Aggressive Mode

The first item is merely an accurate description of the IKE protocol. Check
Point has no bug or vulnerability, but has correctly implemented the IKE
standard for Aggressive Mode.  The passing of usernames in cleartext is
common to any vendors of IKE products who support Aggressive Mode.  The
claim of a vulnerability is incorrect.

Because of such well-known weaknesses in the IKE Aggressive Mode standard,
Check Point authored and published an extension called Hybrid Mode which
allows the secure use of all supported authentication schemes (e.g., RADIUS
or TACACS) without sending usernames in cleartext.  This extension has been
incorporated in the product since the 4.1 SP1 release (February 2000), with
hybrid mode recommended over Aggressive Mode for enhanced security.

The second item exists only in VPN-1/FireWall-1 v4.1 modules which are still
configured to support SecuRemote/SecureClient connections using IKE
Aggressive Mode, despite the availability of more secure options in the
product.  Note, again, that the guessable usernames in this scenario are, by
design of the IKE protocol, sent in cleartext.  By default, Aggressive Mode
is not enabled in NG.  In 4.1, the recommended configuration is to disable
Aggressive Mode and use Hybrid Mode instead (which involves no change to the
user experience).

This information, and any subsequent updates, will be posted to
www.checkpoint.com/techsupport/alerts .

-SwR

Scott Walker Register
FireWall-1 Product Manager
Check Point Software Technologies, Inc.
ph: 561.989.5418  fax: 561.997.9392


> -----Original Message-----
> From: Roy Hills [mailto:Roy.Hills () nta-monitor com]
> Sent: Tuesday, September 03, 2002 7:09 AM
> To: bugtraq () securityfocus com
> Subject: SecuRemote usernames can be guessed or sniffed using IKE
> exchange
>
>
> 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/