Exploit the possiblities


Posted Sep 5, 2002
Authored by Roy Hills | Site nta-monitor.com

Checkpoint Firewall-1 SecuRemote IKE usernames can be guessed or sniffed using IKE exchange and can be guessed separately from the password. 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.

MD5 | 6b2ca1b67b3b84ed7635d156869d2cab


Change Mirror Download
SecuRemote usernames can be guessed or sniffed using IKE exchange


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:


Issue summary:

Firewall-1 versions 4.0 SP 7, 4.1 SP2, 4.1 SP6, NG Base, NG FP1 and NG FP2
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.


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
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.


--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
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

Example 2: This example shows Firewall-1 NG FP2:

rsh@radon [502]% fw1-ike-userguess --file=testusers.txt --sport=0
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


There is no simple "one click" solution or workaround.

However, using certificates rather than usernames and passwords for VPN
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/


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?

Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

January 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jan 1st
    2 Files
  • 2
    Jan 2nd
    13 Files
  • 3
    Jan 3rd
    16 Files
  • 4
    Jan 4th
    39 Files
  • 5
    Jan 5th
    26 Files
  • 6
    Jan 6th
    40 Files
  • 7
    Jan 7th
    2 Files
  • 8
    Jan 8th
    16 Files
  • 9
    Jan 9th
    25 Files
  • 10
    Jan 10th
    28 Files
  • 11
    Jan 11th
    44 Files
  • 12
    Jan 12th
    32 Files
  • 13
    Jan 13th
    2 Files
  • 14
    Jan 14th
    4 Files
  • 15
    Jan 15th
    31 Files
  • 16
    Jan 16th
    15 Files
  • 17
    Jan 17th
    16 Files
  • 18
    Jan 18th
    24 Files
  • 19
    Jan 19th
    7 Files
  • 20
    Jan 20th
    0 Files
  • 21
    Jan 21st
    0 Files
  • 22
    Jan 22nd
    0 Files
  • 23
    Jan 23rd
    0 Files
  • 24
    Jan 24th
    0 Files
  • 25
    Jan 25th
    0 Files
  • 26
    Jan 26th
    0 Files
  • 27
    Jan 27th
    0 Files
  • 28
    Jan 28th
    0 Files
  • 29
    Jan 29th
    0 Files
  • 30
    Jan 30th
    0 Files
  • 31
    Jan 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2018 Packet Storm. All rights reserved.

Security Services
Hosting By