| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1ca1c141040616141335e7424b@mail.gmail.com>
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