RE: IRM 007: The IP addresses of Check Point Firewall-1 internal interfaces may be enumerated using SecuRemote
Ack... in case anyone cares, the URL provided in the post below is out of date,
the new URL is:
http://www.becher.net/users/jim/web/getints.c
-----Original Message-----
From: Becher, Jim (STL)
Sent: Tuesday, September 02, 2003 1:33 PM
To: 'advisories@xxxxxxxxxx'; bugtraq@xxxxxxxxxxxxxxxxx
Subject: RE: IRM 007: The IP addresses of Check Point Firewall-1
internal interfaces may be enumerated using SecuRemote
Long-time lurker, first time poster... please be gentle.
I believe this is a very old (and known) issue:
http://www.securityfocus.com/archive/82/197560
-----Original Message-----
From: IRM Advisories [mailto:advisories@xxxxxxxxxx]
Sent: Tuesday, September 02, 2003 5:26 AM
To: bugtraq@xxxxxxxxxxxxxxxxx
Subject: IRM 007: The IP addresses of Check Point Firewall-1 internal
interfaces may be enumerated using SecuRemote
----------------------------------------------------------------------------
---------------------
IRM Security Advisory No. 007
The IP addresses of Check Point Firewall-1 internal interfaces may be
enumerated using SecuRemote
Vulnerability Type / Importance: Information Leakage / High
Problem discovered: July 25th 2003
Vendor contacted: July 25th 2003
Advisory published: August 22nd 2003
----------------------------------------------------------------------------
---------------------
Abstract:
Check Point FireWall-1 versions 4.0 and 4.1 (prior to SP5) were shipped with
a product called SecuRemote which allows mobile users to connect to an
internal network using an encrypted and authenticated session. During the
initial unencrypted phase of communication between SecuRemote and Firewall-1
a packet is sent containing the all the IP addresses of the firewall,
including those associated with the internal interfaces.
Description:
During various recent penetration tests IRM have established that internal
IP addresses configured on Check Point Firewall-1 devices appear to leak
from TCP ports 256 and 264.
N.B. This is a completely separate issue from the "unauthenticated topology
download" problem that has been previously discussed.
If a telnet connection is established with TCP port 256 on Firewall-1
Version 4.0 and 4.1 and the following sequence of characters is typed:
aa<CR>
aa<CR>
(where <CR> is a carriage return)
The firewall IP addresses are returned (in binary form)
In addition, when using SecuRemote to connect to a firewall on TCP port 264,
if a packet sniffer is used to capture the data transferred, the IP
addresses can also be viewed as shown below:
15:45:44.029883 192.168.1.1.264 > 10.0.0.1.1038: P 5:21(16) ack 17 win 8744
(DF)
0x0000 4500 0038 a250 4000 6e06 5b5a ca4d b102 E..8.P@.n.[Z.M..
0x0010 5102 42c3 0108 040e 1769 fb25 cdc0 8a36 Q.B......i.%...6
0x0020 5018 2228 fa32 0000 0000 000c
c0a8 0101 P."(.2.......M..
0x0030 c0a8 0a01 c0a8 0e01 ........
c0a8 0101 = 192.168.1.1
c0a8 0a01 = 192.168.10.1
c0a8 0e01 = 192.168.14.1
Check Point were contacted and confirmed that it was a known issue that was
fixed in version 4.1 service pack 5, however the details about this
information leakage are not present in the service pack documentation. As
IRM identified this issue during a live penetration test, it was decided
that the information should be publicised so that firewall administrators
could be made aware of it, and the resolution to the problem. A tool
(fwenum) was then produced to demonstrate the technique (available on the
IRM website - http://www.irmplc.com/advisories.htm)
Tested Versions:
Firewall-1/VPN-1 4.0 - vulnerable
Firewall-1/VPN-1 4.1 - vulnerable pre sp5
Firewall-1/VPN-1 NG - not vulnerable
Tested Operating Systems:
Microsoft Windows NT4
Microsoft Windows 2000
Vendor & Patch Information:
Check Point were contacted on July 25th and promptly responded explaining
that the issue had been resolved in version 4.1 service pack 5, which was
released on September 13th 2001. Check Point recommends customers to stay
current with the latest service packs and versions, as they contain security
enhancements to both publicised and to other issues.
Workarounds:
TCP Ports 256 and 264 can be filtered if the SecuRemote service is not
required.
Credits:
Research & Advisory: Andy Davis
Disclaimer:
All information in this advisory is provided on an 'as is'
basis in the hope that it will be useful. Information Risk Management
Plc is not responsible for any risks or occurrences caused
by the application of this information.
----------------------------------------------------------------------------
Information Risk Management Plc.
22 Buckingham Gate
London
SW1E 6LB
+44 (0)207 808 6420
******* Confidentiality Notice *******
This email, its electronic document attachments, and the contents of its
website linkages may contain confidential health information. This information
is intended solely for use by the individual or entity to whom it is addressed.
If you have received this information in error, please notify the sender
immediately and arrange for the prompt destruction of the material and any
accompanying attachments.