From: synfinatic at gmail.com (ADT)
Subject: Checkpoint Firewall-1 IKE Vendor ID information leakage

So basically, the "issue" is that Checkpoint is following RFC 2408 (ISAKMP)?

Specifically section 3.16:

"The Vendor ID Payload contains a vendor defined constant.  The
 constant is used by vendors to identify and recognize remote
 instances of their implementations.  This mechanism allows a vendor
 to experiment with new features while maintaining backwards
 compatibility. "

While perhaps this is unfortunate, it is clearly documented and  I
know that Brett Eldridge gave a talk on this specific issue at DefCon
X.

-Aaron

On Wed, 16 Jun 2004 15:45:29 +0100, Roy Hills <roy.hills@...-monitor.com> wrote:
> 
> 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@...on [537]$
> rsh@...on [537]$
> rsh@...on [537]$
> rsh@...on [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@...-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
> 


-- 
-- 
http://synfin.net/

Powered by blists - more mailing lists