Checkpoint Firewall-1 IKE Vendor ID information leakage
[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.]
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@xxxxxxxxxxxxxxx
Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/