[12095] in bugtraq
Re: FireWall-1 weakness
daemon@ATHENA.MIT.EDU (David Grimes)
Fri Oct 1 16:44:27 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <000c01bf0b89$5d238fe0$9e542bcf@cartman.ts.checkpoint.com>
Date: Thu, 30 Sep 1999 15:18:38 -0600
Reply-To: David Grimes <dgrimes@TS.CHECKPOINT.COM>
From: David Grimes <dgrimes@TS.CHECKPOINT.COM>
X-To: Hugo.van.der.Kooij@CAIW.NL, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.10.9909300738360.31066-100000@bastion.nl3155vj16.vanderkooij.org>
Hugo,
Remember me? You should provide BugTraq the same detail I provided you. I
wouldn't call this a weakness in FW-1 I would say it's a weakness in the
winframe server, better yet in the TCP architecture itself. Winframe is just
as vulernable through a firewall as an SMTP or FTP server, they all allow
arbitrary connections. So with that said I'd like to point out two things
first.
1. Your fear of a DoS could be averted by using SynDefender, which would
protect from a syn flood type of attack.
2. Without inserting WinFrame specific data with in the packet there is no
chance of a vulnerability.
In the event you were able to successfully "high jack" into a Win Frame
connection... well what could FW-1 do then anyway? It looks like a legit
connection. (Just like telneting to port 110 on a pop server and using raw
pop commands).
To detail and clarify what exactly is happening here, let me explain how
the firewall is treating this connection. When the connection comes in it is
accepted by the firewall based on it's src. dest. and service (port), the
real magic comes in to play when statefull inspection is applied to the
connection there after. If you reference the base.def and the winframe
description there, you'll notice that it's looking for a particular
signature that is unique to WinFrame connections. Since this is not present
in any other packet type the firewall then drops the packet as a violation
of a WinFrame connection.
The ideal thing to do here is to modify the inspect script in the base.def
to log this behavior and file it appropriately. You should also take
responsibility for allowing winframe connections in the first place. It's
allways a risk to provide a service to the world. None the less good eye :)
David Grimes
Check Point Software Technologies, Inc.
Sr. Technical Engineer
http://www.checkpoint.com <http://www.checkpoint.com/>
Worldwide leader in enterprise security.
"I don't care what the software does, you're not protected unless YOU
protect YOURSELF." -me
Opinions, conclusions and other information expressed in this message are
not given
or endorsed by my firm or employer unless otherwise indicated by an
authorized representative independent of this message.
> -----Original Message-----
> From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of
> Hugo.van.der.Kooij@CAIW.NL
> Sent: Wednesday, September 29, 1999 11:58 PM
> To: BUGTRAQ@SECURITYFOCUS.COM
> Subject: FireWall-1 weakness
>
>
> Hi,
>
> At present CheckPoint has not seen any reason to see the following issue
> as a weakness in their product. So I now report this here:
>
> If one takes CheckPoint FireWall-1 v4.0 SP4 (latest version) and build the
> following rule:
>
> Source: Destination: Protocol: Action:
> Any citrix-server winframe accept
>
> Where citrix-server is a simple network object and winframe the definition
> as created by CheckPoint.
>
> This rules allows winframe sessions to pass but should stop other traffic
> as it does some more packet analyses.
>
> A customer tried to run FTP through it and saw an accept in the log. But
> due to the lack of a server on the other side could not establish wether
> or not there was a leak.
>
> Recreating this in the lab with telnet showed the same. However putting a
> working telnetd on port 1494 at the specific server did still not allow
> anyone to enter the system. After initial TCP connection setup it seems
> the firewall drops connections.
>
> But this will lead to two weaknesses:
> 1. Any server defended by FireWall-1 could be subject to a DoS attack if
> the server should accept TCP sessions at port 1494. The server allows
> the initial setup and then stops forwarding.
>
> (That's two dependencies but we are the people that allways assume the
> worst as we are the ones that try to do the worst in such case ;-)
>
> 2. The log only shows a succesfull start of the session but down not
> indicate any filtering. This leaves the operator of the firewall in
> the dark wether or not a session was cut off due to the missing
> winframe signature. So there is no indication off foul play and
> everyone will be assuming things are just fine.
>
> (We all know that if a firewall is supposed to show dropped packets
> that plenty of people will never look for trouble in the sessions that
> are allowed.)
>
> I hope that this document will help people understand a oversight in the
> logging/alerting facilities that they have to deal with in FireWall-1.
>
> I did not test for other types of services that have additional checks in
> them. They may suffer the same lack of logging/alerting in case incorrect
> sessions are blocked.
>
> Regards,
> Hugo.
>
> --
> Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ Maasland
> hvdkooij@caiw.nl http://home.kabelfoon.nl/~hvdkooij/
> --------------------------------------------------------------
> Use of any of my email addresses for unsollicited (commercial)
> email is a clear intrusion of my privacy and illegal!
>
