SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (VPN)  >   FireWall-1/VPN-1 Vendors:   Check Point
Check Point FireWall-1 Internet Key Exchange (IKE) Implementation Bugs Disclose Whether a SecuRemote Username is Valid or Not to Remote Users
SecurityTracker Alert ID:  1005173
SecurityTracker URL:  http://securitytracker.com/id/1005173
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Sep 3 2002
Impact:   Disclosure of system information
Exploit Included:  Yes  
Version(s): 4.0, 4.1, NG
Description:   Two vulnerabilities were reported in FireWall-1 in the IPSec Internet Key Exchange (IKE) implementation. A remote user can query the system to determine valid usernames. Also, a remote user with the ability to sniff the network may be able to capture usernames during IKE transactions.

NTA Monitor reported that SecuRemote usernames can be guessed or sniffed due to weaknesses in Check Point's IKE protocol implementation.

A remote user can query the firewall to determine if a particular username is valid or not. NTA Monitor reports that they were able to check 10,000 usernames within 2 minutes and 30 seconds at a rate of 67 guesses per second using 10% of a 2 Mbps leased line. Apparently, the maximum guessing rate is primarily limited by the firewall's CPU resources, rather than by the Internet link speed.

To exploit the flaw, a remote user can 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

This will cause the Firewall to send back an IKE notification message indicating that the username is not valid (for several possible reasons) or to send back an aggressive mode packet indicating that the username is valid.

It is also reported that a remote user with the ability to sniff the firewall's IKE network transactions can view VPN usernames. According to the report, VPN usernames are passed in the clear without encryption.

Technical details of both flaws are available at from NTA Monitor at:

http://www.nta-monitor.com/news/checkpoint.htm

The vendor has reportedly been notified.

Impact:   A remote user can determine valid usernames on the firewall. A remote user with the ability to sniff the network can obtain valid usernames.
Solution:   No solution was available at the time of this entry.
Vendor URL:  www.checkpoint.com/ (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  Linux (Any), UNIX (AIX), UNIX (HP/UX), UNIX (Solaris - SunOS), Windows (NT), Windows (2000)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Vendor Disputes Claim and Provides a Response) Re: Check Point FireWall-1 Internet Key Exchange (IKE) Implementation Bugs Disclose Whether a SecuRemote Username is Valid or Not to Remote Users
Check Point indicates that one of the claims is not a vulnerability but is an inherent property of the IKE protocol. Other details are provided.



 Source Message Contents

Subject:  SecuRemote usernames can be guessed or sniffed using IKE


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/


 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC