[NEWS] Checkpoint FW-1 VPN Security Flaw (updated)

From: support@securiteam.com
Date: 09/04/02


From: support@securiteam.com
To: list@securiteam.com
Date: Wed,  4 Sep 2002 12:15:53 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Checkpoint FW-1 VPN Security Flaw (updated)
------------------------------------------------------------------------

SUMMARY

During the course of regular testing, NTA Monitor has discovered two
serious flaws in Checkpoint Firewall-1, giving rise to both username
guessing and sniffing issues.

Both issues relate to an authentication method that is unrecommended by
CheckPoint, and users that are employing the "IKE Aggressive Mode" feature
of SecuRemote/SecureClient are urged to consider other, more secure,
alternatives.

First, affected versions permit remote users to determine if a Firewall
username is valid without having to know the associated password, enabling
hackers to guess valid usernames using a dictionary attack. In tests of
the flaw conducted by NTA Monitor, it took 2 minutes 30 seconds to check
10,000 usernames at a rate of 67 guesses per second using only 10% of a
2Mbps leased line. The guessing rate is mostly limited to by the Firewall
CPU rather than by the Internet link speed. In effect, this means that
companies using a hi-spec firewall server increase the speed at which an
attacker can guess passwords.

In addition, VPN usernames are passed in the clear without encryption,
allowing anyone who is able to sniff network traffic between VPN clients
and the Firewall to observe usernames in transit. The flaws exploit the
Internet Key Exchange (IKE) encryption scheme and affect all Checkpoint
Firewall-1 systems of 4.0 or above.

This leaves the back door to the enterprise wide open to hackers. The
biggest problem is that it is not necessary to send a password to obtain a
reply from the Firewall. Given that both users and system administrators
often chose weak passwords, it is likely that any attacker will be able to
guess at least one password and thus gain access to the VPN - and from
there most configurations easily allow full access to the company's
resources.

The correct approach would be to wait until both username and password are
supplied, and if either is incorrect, send a generic error message. We
were surprised to find this flaw when this is standard security practice
in many other authentication mechanisms, including UNIX logon.

DETAILS

Technical Summary:
1. Username Guessing: Affected versions of Checkpoint Firewall-1 permit
remote users to determine if a Firewall username is valid without having
to know the associated password. This allows a hostile user to guess valid
usernames by using a dictionary attack where a list of potential usernames
is submitted to the Firewall one by one to check if they are valid.

2. Username Sniffing: The VPN (virtual private network) usernames are
passed in the clear without encryption. Therefore, anyone who is able to
sniff network traffic between VPN clients and the Firewall can observe the
usernames in transit.

Systems Affected:
Systems running Checkpoint Firewall-1 versions 4.0, 4.1, NG, NG FP1 and NG
FP2 that use the IKE (Internet Key Exchange) [4] encryption scheme (known
as ISAKMP/Oakley in v4.0) with shared secret authentication for remote
user VPNs with SecuRemote / SecureClient.
Note: in VPN-1/FireWall-1 NG Aggressive Mode is not enabled by default.

 * Firewall-1 versions prior to 4.0 (e.g. 3.0b) are not affected because
the IKE encryption scheme was not introduced until v4.0.
 * Firewall-1 versions 4.1 SP2 [6] and NG FP1[7] have been certified to
ITsec E3 level with the VPN capability of the Firewall included in the TOE
(target of evaluation). Although version 4.0 is also certified to ITsec E3
[5], the TOE for 4.0 excludes the VPN feature and therefore the VPN
facility of * Firewall-1 v4.0 is not ITsec certified.

Issue Details:
Username Guessing
The username guessing issue involves attempting to authenticate with the
Firewall using IKE (Internet Key Exchange) [4] that is a standard protocol
that forms part of the IPSec (IP Security) architecture [1]. If a remote
user sends an appropriately constructed IKE packet to the Firewall
containing the username to be tested, the Firewall will indicate whether
that user is valid or not in, its reply packet. It is not necessary to
send a password to obtain the reply from the Firewall.
The correct approach would be to wait until both the username and the
password (shared secret) have been sent and then, if either is incorrect,
to send a generic error message indicating that authentication had failed
without detailing whether the username, password, or both were incorrect.
In this way, an attacker is not able to determine if a given username is
valid without also knowing the associated password. This technique is
standard security practice in many other authentication mechanisms
including UNIX login.

It is well known that users and system administrators often choose weak
passwords, so once valid usernames are guessed or sniffed it is likely
that the attacker will be able to guess the password to one or more of
these and thus gain access to the VPN. As many (perhaps most) VPN
configurations allow full access to the company's internal network behind
the Firewall, this could allow the attacker full access to the company
resources.

As the Firewall does not normally restrict who can attempt to authenticate
with it using IKE, this issue can be exploited by anyone on the Internet.
It was observed that the Firewall does not impose any limits on how many
times a given host can attempt to authenticate and that the packet
exchange required for checking a username is very quick. This means that
it is possible to use this issue to check a large username dictionary in a
relatively short time. Tests using a program written to investigate this
issue showed that over a 64Kbit/s serial connection, it took 12 minutes to
check 10,000 usernames for a rate of about 14 guesses per second; over a
2Mbit/s link, it took 2 minutes 30 seconds to check the same 10,000 user
dictionary for a rate of about 67 guesses per second.

For the rate tests, we used Firewall-1 v4.1 SP6 running on NT Server 4.0
SP6a on an AMD Duron 800MHz CPU with 128MB RAM. There was a serial link
composed of two back-to-back Cisco routers joined with a DCE/DTE cable
between the Firewall and the test system. When the serial link was running
at 64Kbit/sec, the observed serial usage was 41Kbit/sec from the test
system to the Firewall and the Firewall CPU loading was steady at 15%
during the test. This shows that for a 64Kbit/sec link, the bandwidth is
the limiting factor. With a 2Mbit/sec link, the observed usage was
210Kbit/sec and the Firewall CPU loading was steady at 95% showing that
the limiting factor for a 2M link was the Firewall CPU. A faster Firewall
CPU would allow a faster guessing rate with high-speed links.

In addition to just indicating whether a username is valid or not,
Firewall-1 versions 4.0, 4.1 and NG (but not NG FP1 or NG FP2) will send a
text string for invalid users indicating why the username is not valid for
IKE. Examples of observed strings together with their meanings are:
1. "User testuser unknown." - User does not exist
2. "User cannot use IKE" - User exists but does not use IKE. Maybe uses
FWZ or plain authentication.
3. "Login expired on 1-jan-2002.\n" - User exists but the account expired
on the date shown.
4. "IKE is not properly defined for user." - User exists but IKE is not
properly configured e.g. no shared secret.

For these versions, the issue is even worse because they leak more
information that could be useful to an attacker. For example by indicating
that a username does exist but does not use IKE, the Firewall tells the
attacker that this is a valid username that could be exploited using
another encryption scheme (such as FWZ) or plain authentication.

Username Sniffing
If shared secret authentication is used with IKE aggressive mode, the
identity is passed in the first packet that must be in the clear because
the key exchange has not completed at this point so encryption cannot be
used. SecuRemote uses the username for the identity in this first packet
and therefore the username is passed in the clear.
This ID sniffing issue is to some extent inherent in IKE aggressive mode
because the ID must be passed in the clear. The problem here is that many
users will not realize the potential issue and will therefore have a false
sense of security.
This username sniffing issue has the same potential weak password issue as
the username guessing issue mentioned above, with the same possible result
of full access to the company network via the VPN.

Additional technical details:
Username Guessing
To exploit this issue, we send an IKE Phase-1 aggressive mode packet with
the following payloads:
1. ISAKMP Header
2. SA - Containing one proposal with four transforms:
A) 3DES encryption, SHA1 hash, Shared Secret Auth, DH group 2, Lifetime
86400 seconds.
B) 3DES encryption, MD5 hash, Shared Secret Auth, DH group 2, Lifetime
86400 seconds.
C) DES encryption, SHA1 hash, Shared Secret Auth, DH group 2, Lifetime
86400 seconds.
D) DES encryption, MD5 hash, Shared Secret Auth, DH group 2, Lifetime
86400 seconds.
3. Key Exchange - DH Group 2 (MODP 1024)
4. Nonce
5. Identification - Type ID_USER_FQDN, Value is SecuRemote username as
text string
The four transforms were selected to ensure that there would be an
acceptable combination of encryption and hash algorithms for the Firewall.
It would be possible to use just one transform if it were known which
encryption and hash algorithms the Firewall supported.

Diffie Hellman group 2 was chosen because this is the default group and is
supported by all known Firewall-1 versions. See RFC 2409 [4] section 6
"Oakley Groups" for the definition of these groups.
The Firewall will then either send back an IKE notification message
indicating that the user is not valid for IKE, or it will respond with an
aggressive mode packet indicating that the user exists and is valid. It is
trivial to determine if the user is valid or not by analyzing this
returned packet.

In the event that the username is not valid, the IKE notification message
returned by the Firewall either contains one of the standard notify
message types defined in RFC 2408 [3] section 3.14.1 (e.g. 14 =
NO-PROPOSAL-CHOSEN) or the Checkpoint-specific message type 9101 together
with a text string explaining the reason why the username is not valid
(e.g. "Login expired on 1-jan-2002.\n"). Only Firewall-1 versions 4.0, 4.1
and NG appear to use message type 9101 with the associated text string; NG
FP1 and NG FP2 use only the RFC standard notify message types.

Username Sniffing
The SecuRemote username appears in the clear in the identification payload
of the first IKE packet from the SecuRemote client to the Firewall. It is
trivial to sniff these packets and to extract the usernames.

If Firewall-1 used IKE main mode rather than aggressive mode (see RFC 2408
[3] and RFC 2409 [4] for details on main mode and aggressive mode), then
the username sniffing would not be an issue because main mode provides
identity protection which means that the ID (username in this case) would
not be passed in the clear. However, if shared secret authentication is
used and the identity is not known in advance (which it is not for remote
user VPNs), then main mode cannot be used and aggressive mode is the only
option.

Solutions:
If certificates rather than shared secrets are used for IKE
authentication, then neither of these problems occurs. However, NTA
Monitor have found that in practice the majority of users use shared
secret authentication rather than certificates because they are easier to
configure and better understood by both sysadmins and users.

For the username guessing issue, it would be better for Checkpoint's IKE
implementation not to send Notify messages if the username is incorrect
before the secret has been exchanged. The RFC does not require this
behavior. It is suggested that the implementation should wait until it has
both the username (ID) and password (shared secret) and then give a
generic "either username or password is incorrect" message to prevent
password guessing.

For the username sniffing issue, NTA Monitor suggests that users should at
least be aware that the SecuRemote username is passed in the clear if IKE
is used with shared secrets so that they can understand the risks. If
users know the risks inherent in shared secret IKE, then they may be more
likely to choose certificate authentication.

Examples:
Username guessing against Firewall-1 v4.0 SP7
rsh@radon% fw1-ike-userguess --file=testusers40.txt 172.16.2.3
testuser Notify message 9101 (User testuser unknown.)
test Notify message 9101 (Login expired on 31-may-2002.)
skeytest Notify message 9101 (User cannot use ISAKMP/OAKLEY)
hybrid Notify message 9101 (No pre-shared secret defined for user.)

In this example, and in the v4.1 SP6 example below, the Firewall responds
to invalid usernames with the Checkpoint-specific notify message type 9101
and an associated text string describing the reason why the username is
not valid.

Note how Firewall-1 v4.0 refers to the key exchange protocol as
"ISAKMP/OAKLEY" rather than "IKE". This difference in terminology can help
to distinguish between v4.0 and v4.1 that is in itself information that
could be useful to an attacker because there might be known
vulnerabilities in Firewall-1 v4.0 that could be targeted.

Username guessing against Firewall-1 4.1 SP6
rsh@radon% fw1-ike-userguess --file=testusers.txt 172.16.2.2
testuser Notify message 9101 (User testuser unknown.)
test-ike-3des USER EXISTS
testing123 Notify message 9101 (User testing123 unknown.)
test-ike-des USER EXISTS
guest Notify message 9101 (User guest unknown.)
test-fwz-des Notify message 9101 (User cannot use IKE)
test-ike-cast40 USER EXISTS
test-ike-ah USER EXISTS
test-ike-hybrid Notify message 9101 (IKE is not properly defined for
user.)
test-expired Notify message 9101 (Login expired on 1-jan-2002.)
Username guessing against Firewall-1 NG FP2
rsh@radon% fw1-ike-userguess --file=testusers.txt 192.168.124.150
testuser Notify message 14 (NO-PROPOSAL-CHOSEN)
test-ike-3des USER EXISTS
testing123 Notify message 14 (NO-PROPOSAL-CHOSEN)
test-ike-des USER EXISTS
guest Notify message 14 (NO-PROPOSAL-CHOSEN)
test-fwz-des Notify message 14 (NO-PROPOSAL-CHOSEN)
test-ike-cast40 Notify message 14 (NO-PROPOSAL-CHOSEN)
test-ike-ah Notify message 14 (NO-PROPOSAL-CHOSEN)
test-ike-hybrid Notify message 14 (NO-PROPOSAL-CHOSEN)
test-expired Notify message 14 (NO-PROPOSAL-CHOSEN)

In this example, the Firewall responds to invalid usernames with the
notify message code 14 which is defined in RFC 2408 as
"NO-PROPOSAL-CHOSEN". The program decodes this and other RFC's standard
notification message types for convenience.

Vendor Response:
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).

ADDITIONAL INFORMATION

References:

[1] RFC 2401 Security Architecture for the Internet Protocol

[2] RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP

[3] RFC 2408 Internet Security Association and Key Management Protocol
(ISAKMP)

[4] RFC 2409 The Internet Key Exchange (IKE)

[5] ITsec report for v4.0
<http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/crp107.pdf> http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/crp107.pdf

[6] ITsec report for v4.1 SP2
<http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/CRP149.pdf> http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/CRP149.pdf

[7] ITsec report for NG FP1
<http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/crp166.pdf> http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/crp166.pdf

The original advisory can be viewed by going to:
 <http://www.nta-monitor.co.uk/news/checkpoint.htm>
http://www.nta-monitor.co.uk/news/checkpoint.htm

CheckPoint's vendor response is available at:
<http://www.checkpoint.com/techsupport/alerts/>
http://www.checkpoint.com/techsupport/alerts/.

The information has been provided by NTA Monitor.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages