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

SecurityTracker
Archives


 


Category:   Application (VPN)  >   FireWall-1/VPN-1 Vendors:   Check Point
(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
SecurityTracker Alert ID:  1005175
SecurityTracker URL:  http://securitytracker.com/id/1005175
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Sep 4 2002
Impact:   Disclosure of system information
Fix Available:  Yes  Vendor Confirmed:  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:   Check Point has issued a response, noting that the disclosure of usernames during an IKE aggressive mode exchange is part of the IKE aggressive mode protocol, not a flaw in Check Point's implementation.

The vendor also notes that the guessability of passwords does not apply to systems in Hybrid Mode (which is reportedly the recommended configuration).

The full response is available at:

http://www.checkpoint.com/techsupport/alerts/ike.html

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 is a follow-up to the message listed below.
Sep 3 2002 Check Point FireWall-1 Internet Key Exchange (IKE) Implementation Bugs Disclose Whether a SecuRemote Username is Valid or Not to Remote Users



 Source Message Contents

Subject:  Check Point response


Check Point has issued a response to a recent report regarding potential
flaws in Check Point's IKE implementation.  

The vendor notes that the disclosure of usernames during an IKE
aggressive mode exchange is part of the IKE aggressive mode protocol,
not a flaw in Check Point's implementation.  

The vendor also notes that the guessability of passwords does not apply
to systems in Hybrid Mode (which is reportedly the recommended
configuration).

The full response is available at:

http://www.checkpoint.com/techsupport/alerts/ike.html


[Start Quote]

IKE Aggressive Mode

September 3 , 2002

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 VPN-1
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 VPN-1 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).

[End Quote]


 
 


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