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

SecurityTracker
Archives


 


Category:   Application (Firewall)  >   FireWall-1/VPN-1 Vendors:   Check Point
Check Point FireWall-1 IPSec IKE Packets Disclose Identifying Vendor and Version Information to Remote Users
SecurityTracker Alert ID:  1010507
SecurityTracker URL:  http://securitytracker.com/id/1010507
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jun 16 2004
Impact:   Disclosure of system information
Exploit Included:  Yes  
Version(s): 4.1 and later
Description:   An information disclosure vulnerability was reported in Check Point FireWall-1 when using IPsec. A remote user can identify the target firewall as a Check Point firewall.

Roy Hills of NTA reported that a remote user can send an IKE packet with a specific Vendor ID payload to cause the firewall to return an IKE Vendor ID payload that identifies the system as Check Point FireWall-1. The returned packet also identifies the version and service-pack or feature-pack revision number, the report said.

Versions 4.1 (no service pack) through NG AI R55 are affected. FireWall-1 version 4.0 is reportedly not vulnerable because it does not return any Vendor ID
payload. FireWall-1 versions 3.0b and prior versions do not support IPsec VPNs and, therefore, are not vulnerable.

An IKE Phase-1 packet with a Vendor ID payload containing the following data can reportedly trigger the flaw:

"f4ed19e0c114eb516faaac0ee37daf2807b4381f"

The returned Vendor ID payload will contain the same 20-byte sequence followed by 20-bytes of data that contain the encoded version number and some other details, the report said.

The issue was discovered using the ike-scan tool, available at:

http://www.nta-monitor.com/ike-scan/

The original advisory is available at:

http://www.nta-monitor.com/news/checkpoint2004/index.htm

Impact:   A remote user can determine that the target firewall is a particular version of the FireWall-1 firewall.
Solution:   No solution was available at the time of this entry.
Vendor URL:  www.checkpoint.com/ (Links to External Site)
Cause:   Access control error
Underlying OS:  Linux (Any), UNIX (AIX), UNIX (HP/UX), UNIX (Solaris - SunOS), Windows (NT), Windows (2000)

Message History:   None.


 Source Message Contents

Subject:  [Full-Disclosure] Checkpoint Firewall-1 IKE Vendor ID information leakage


Checkpoint Firewall-1 IKE Vendor ID information leakage

Introduction:

Checkpoint Firewall-1 version 4.1 and later with IPsec VPN enabled will
return an IKE Vendor ID payload when it receives an IKE packet with
a specific Vendor ID payload.  The Vendor ID payload that is returned
identifies the system as Checkpoint Firewall-1 and also determines the
Firewall-1 version and service-pack or feature-pack revision number.
This is an information leakage issue which can be used to fingerprint
the Firewall-1 system.

This information leakage issue has been verified for Checkpoint Firewall-1
versions from 4.1 (no service pack) to NG AI R55 inclusive.  Firewall-1
version 4.0 is not vulnerable because it does not return any Vendor ID
payload, and Firewall-1 versions 3.0b and earlier are not vulnerable
because they do not support IPsec VPN.  However, most people are running
either NG or 4.1 and therefore this issue will apply to most Firewall-1
installations that have IPsec VPN enabled.

I used ike-scan v1.6 (http://www.nta-monitor.com/ike-scan/) to discover
and demonstrate this issue.

Full details are available at:
http://www.nta-monitor.com/news/checkpoint2004/index.htm

Details:

If an IKE Phase-1 packet with a Vendor ID payload containing the data
"f4ed19e0c114eb516faaac0ee37daf2807b4381f" (20 bytes of binary data
encoded as hex) is sent to a Firewall-1 system running Firewall-1 v4.1
or higher which supports IKE, the Firewall will respond with a Vendor ID
payload containing data which identifies it as a Checkpoint Firewall-1
system, provides details about the version of the Firewall software,
and contains some additional information.

The data that is returned in the Vendor ID payload from the
Firewall consists of the same 20-byte sequence that was sent
(f4ed19e0c114eb516faaac0ee37daf2807b4381f) followed by another 20-bytes
of data that contains the encoded version number and some other details
that appear to contain details of the Firewall's capabilities.

I presume that the 20-byte "magic string" is an SHA1 hash of something.
I'd be interested to find out what source string hashes to this value.

Looking at all versions of Firewall-1 from 4.1 base (no service pack) to
NG AI R55 (latest current version), I have found the following returned
Vendor ID payloads.  In the payloads below, a dot (".") represents an
arbitary hex digit:

Firewall-1 4.1 Base (no service pack)
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000....0000

Firewall-1 4.1 SP1
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000....0000

Firewall-1 4.1 SP2-SP6 (SP2, 3, 4, 5, and 6 return the same Vendor ID)
f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000....0000

rsh@radon [537]$
rsh@radon [537]$
rsh@radon [537]$
rsh@radon [537]$ cat ,,
[Note to moderator: I notified Checkpoint of this issue on 13th April
2004, but have not received any response apart from a "We've received
your Email" auto-reply.]

Introduction:

Checkpoint Firewall-1 version 4.1 and later with IPsec VPN enabled will
return an IKE Vendor ID payload when it receives an IKE packet with
a specific Vendor ID payload.  The Vendor ID payload that is returned
identifies the system as Checkpoint Firewall-1 and also determines the
Firewall-1 version and service-pack or feature-pack revision number.
This is an information leakage issue which can be used to fingerprint
the Firewall-1 system.

This information leakage issue has been verified for Checkpoint Firewall-1
versions from 4.1 (no service pack) to NG AI R55 inclusive.  Firewall-1
version 4.0 is not vulnerable because it does not return any Vendor ID
payload, and Firewall-1 versions 3.0b and earlier are not vulnerable
because they do not support IPsec VPN.  However, most people are running
either NG or 4.1 and therefore this issue will apply to most Firewall-1
installations that have IPsec VPN enabled.

I used ike-scan v1.6 (http://www.nta-monitor.com/ike-scan/) to discover
and demonstrate this issue.

Full details are available at:
http://www.nta-monitor.com/news/checkpoint2004/index.htm

Details:

If an IKE Phase-1 packet with a Vendor ID payload containing the data
"f4ed19e0c114eb516faaac0ee37daf2807b4381f" (20 bytes of binary data
encoded as hex) is sent to a Firewall-1 system running Firewall-1 v4.1
or higher which supports IKE, the Firewall will respond with a Vendor ID
payload containing data which identifies it as a Checkpoint Firewall-1
system, provides details about the version of the Firewall software,
and contains some additional information.

The data that is returned in the Vendor ID payload from the
Firewall consists of the same 20-byte sequence that was sent
(f4ed19e0c114eb516faaac0ee37daf2807b4381f) followed by another 20-bytes
of data that contains the encoded version number and some other details
that appear to contain details of the Firewall's capabilities.

I presume that the 20-byte "magic string" is an SHA1 hash of something.
I'd be interested to find out what source string hashes to this value.

Looking at all versions of Firewall-1 from 4.1 base (no service pack) to
NG AI R55 (latest current version), I have found the following returned
Vendor ID payloads.  In the payloads below, a dot (".") represents an
arbitary hex digit:

Firewall-1 4.1 Base (no service pack)
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000....0000

Firewall-1 4.1 SP1
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000....0000

Firewall-1 4.1 SP2-SP6 (SP2, 3, 4, 5, and 6 return the same Vendor ID)
f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000....0000

Firewall-1 NG Base
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013880000000000000000....0000

Firewall-1 NG FP1
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013890000000000000000....0000

Firewall-1 NG FP2
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a0000000000000000....0000

Firewall-1 NG FP3
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138b0000000000000000....0000

Firewall-1 NG AI R54
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c0000000000000000....0000

Firewall-1 NG AI R55
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d0000000000000000....0000

The version part is given in character positions 53 - 56 inclusive.
E.g. "138d" (decimal 5005) for NG AI R55.

Here's an example using ike-scan v1.6 with an NG FP2 Firewall.  Here,
we are specifying RSA authentication with --auth=3 to get the Firewall
to handshake as well as providing the Firewall-1 Vendor ID:

$ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=3 -M 
172.16.2.2
Starting ike-scan 1.6 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.2      Main Mode Handshake returned
         SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 
LifeType=Seconds LifeDuration(4)=0x00007080)
         VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a000000000000000018800000 
(Firewall-1 NG FP2)

Ending ike-scan 1.6: 1 hosts scanned in 0.009 seconds (108.96 hosts/sec).
1 returned handshake; 0 returned notify

Here is a second example fingerprinting an NG AI R54 Firewall using
hybrid authentication (--auth=64221):

$ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=64221 
-M 172.16.2.2
Starting ike-scan 1.5.3 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.2      Main Mode Handshake returned
         SA=(Enc=3DES Hash=SHA1 Auth=64221 Group=2:modp1024
         LifeType=Seconds LifeDuration(4)=0x00007080)
         VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018800000 
(Firewall-1 NG AI R54)

References:

http://www.nta-monitor.com/news/checkpoint2004/index.htm        Issue details
http://www.nta-monitor.com/ike-scan/    ike-scan tool
--
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/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

 
 


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