NTA Monitor

Latest News

Will IE6 be the next NT4?

1st October 2009 All penetration testers will remember the long tail of Windows NT 4.0, and how this operating system continued to be used long past the point when security updates stopped at the end of 2004. For many years the presence of an unpatchable NT4 server was a common issue in a penetration test report, and it is only now, almost five years after security support ended, that finding an NT4 system on a network is becoming a rare event. Read More

One in four web applications susceptible to high risk security flaws

7th September 2009 NTA Monitor has reported a 10% increase in the total number of web applications found to have at least one high-risk security issue... Read More

Organisations facing a changing threat landscape

20th July 2009 According to NTA Monitor's 2009 Annual Security Report, the average number of Internet security vulnerabilities is on the rise... Read More

The Return of the Insider Threat

1st July 2009 When NTA started security testing twelve years ago, the main focus was on the insider threat. There were many reports with statistics showing that most security breaches were due to insiders. By contrast there was very little focus on the external threat via Internet and third-party network links. Back then many companies did not even have a firewall. Read More

Firewall-1 Vendor ID Fingerprinting

Introduction

It is possible to identify a Checkpoint Firewall-1 system that supports IPsec VPN by using IKE Vendor ID fingerprinting. This fingerprinting technique identifies the specific version of Firewall-1 that is being run on the system being scanned as well as the fact that it is a Checkpoint Firewall-1 system.

This technique works with Firewall-1 versions 4.1, NG and NGX. Version 4.0 does not return any vendor ID payload, and versions 3.0 and earlier don't support IKE. In practice, essentially all Firewall-1 systems are running either 4.1, NG or NGX; I've not come across anyone still running 4.0, let alone 3.0.

The technique works with both IKE Main Mode and Aggressive Mode. Version 4.1 often uses Aggressive Mode, while NG and NGX generally use Main Mode.

Method

The fingerprinting technique uses the fact that Firewall-1 includes a Vendor ID payload in the first IKE packet that it sends. For 4.1 and NG, this Vendor ID payload is only sent if the correct Vendor ID payload is sent in the initial IKE request, whereas for NGX the Vendor ID payload is always sent.

In the initial IKE packet exchange, the client sends the 1st IKE packet to the server. To identify Firewall-1, this first packet should include a Vendor ID payload containing the 20 bytes of data represented in hex as:

f4ed19e0c114eb516faaac0ee37daf2807b4381f

This 20 byte VendorID payload is the Checkpoint VendorID. Because it is 20 bytes long and appears random I suspect that it is an SHA1 hash of some data.

The Firewall then responds with the 2nd packet which will contain a Vendor ID payload ("VendorID"). For Firewall-1, this response Vendor ID will contain 40 bytes of data. The first 20 bytes of the payload will be the same Checkpoint Vendor ID that was sent in the 1st packet, which identifies the system as Checkpoint Firewall-1. The second 20 bytes contain, amongst other things, an encoded representation of the Firewall version.

Firewall-1 VendorID Payload Format

An example of a returned VendorID payload is:

f4ed19e0c114eb516faaac0ee37daf2807b4381f
000000010000138a000000000000000018800000

This returned VendorID payload data contains the following structure:

Byte PositionExample DataMeaning
1 to 20f4ed19e0c114eb516faaac0ee37daf2807b4381fCheckpoint Vendor ID
21 to 2400000001Product (1=Firewall, 2=client)
25 to 280000138aEncoded version (see below)
29 to 3200000000Timestamp (NGX only)
33 to 3600000000Reserved (always zero)
37 to 4018800000Features

The 2nd 20 bytes (bytes 21 to 40) of the Vendor ID payload consist of five 4-byte integers in network (big endian) byte order. The 4-byte integer at byte positions 25 to 28 inclusive contains the Firewall-1 version number.

Firewall-1 NGX R60 returns non-zero data in the "timestamp" field, whereas this is always zero for 4.1 and NG. This allows us to distinguish NGX from NG. This timestamp shows the current time on the target firewall in seconds since Jan 1st 1970.

By testing all versions of Firewall-1 from 4.0 to NGX R60 inclusive, we have determined the following version number encoding for this version number field in the VendorID payload:

Hex Version Decimal VersionFirewall-1 VersionNotes
N/AN/A4.0Firewall-1 v4.0 doesn't return any VendorID
000224.1This is 4.1 base install (no service pack)
000334.1 SP1
0fa240024.1 SP2 to SP64.1 SP2 to SP6 inclusive return the same version
13885000NGThis is NG base install (no service pack)
13895001NG FP1
138a5002NG FP2
138b5003NG FP3
138c5004NG AI R54
138d5005NG AI R55
138e5006NG AI R56SecureClient only
00000NGX R60NGX has non-zero timestamp

SecuRemote clients also send their version number in the VendorID payload of the 1st IKE packet that they send to the Firewall. This SecuRemote VendorID payload is structured in the same way as the Firewall-1 payload, but with the value 2 instead of 1 in byte positions 21 to 24 inclusive.

Using ike-scan to Fingerprint Firewall-1

The IKE Scanning utility ike-scan 1.6 and later can be used to send IKE packets to the Firewall and decode the response packets. The VendorID fingerprint patterns file supplied with ike-scan contains patterns for the Firewall-1 versions shown in the table above (as well as other known Vendor ID patterns), which allows ike-scan to decode the Firewall version. ike-scan is available from http://www.nta-monitor.com/tools/ike-scan/.

is also possible to use ike-scan to identify Firewall-1 and other VPN server systems using UDP Backoff Fingerprinting as detailed in http://www.nta-monitor.com/posts/2003/01/udp-backoff.html. However, this article only discusses Vendor ID fingerprinting.

To use ike-scan to perform VendorID fingerprinting for Firewall-1, you will need to specify SA parameters that are acceptable to the Firewall in order for the Firewall to respond. If the SA parameters are not acceptable, the Firewall will respond with the IKE notify message "NO-PROPOSAL-CHOSEN".

For Firewall-1 NG and NGX (the most common case), you will normally need to specify either RSA authentication with "--auth=3" or Hybrid authentication with "--auth=64221". For Firewall-1 4.1, you may need to use aggressive mode (--aggressive or -A) and specify a valid username with the --id or -n option.

In all cases, you should specify the Checkpoint vendor id with "--vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f". You may also want to specify --multiline or -M to split the packet decode across multiple lines because this makes the output easier to read.

Note that all options to ike-scan can be specified either as short options such as "-h" or the corresponding long option such as "--help".

ike-scan Examples

Identifying NG AI R54 using Main Mode with RSA Authentication

The ike-scan options used are:
--vendor=f4ed ... 381fSpecify Checkpoint VendorID payload for outgoing packet
--auth=3Specify RSA Authentication (RFC 2409 specifies these numbers)
-MSplit packet decode across multiple lines (same as --multiline)
$ 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=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018800000 (Firewall-1 NG AI R54)

Identifying NG AI R54 using Main Mode with Hybrid Authentication This is the same as the RSA authentication example above, except that we specify hybrid authentication by specifying "--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)

Identifying NG AI R54 using Aggressive Mode with PSK Authentication This example uses Aggressive Mode. We don't specify any --auth option, so the default value of 1 (Pre-Shared Key) is used. For aggressive mode, we need to specify a valid identification payload (ID) with "-n 74657374" that gives the ID as hex value 74657374, which is "test" in ASCII. We don't specify the identification type with the --idtype option, so the default of ID_USER_FQDN is used, which is acceptable to Firewall-1.

$ ike-scan -A -n 74657374 -M --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f 172.16.2.2
Starting ike-scan 1.5.3 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.2	Aggressive Mode Handshake returned
	SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
	KeyExchange(128 bytes)
	Nonce(20 bytes)
	ID(Type=ID_IPV4_ADDR, Value=172.16.2.2)
	VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018800000 (Firewall-1 NG AI R54)
	Hash(20 bytes)
Identifying NG FP2 using Main Mode with RSA Authentication 
$ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=3 -M 172.16.2.3
Starting ike-scan 1.6 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.3	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)

References

X-Force: fw1-vendorid-info-disclosure (16434)

SecurityFocus: Check Point Firewall-1 Internet Key Exchange Information Disclosure Vulnerability

For a glossary of terms used in this document, please click here

For more information, please contact us on +44(0)1634 721855 or via email at info@nta-monitor.com

This advisory was first released on 30th January 2004.