[12120] in bugtraq
FireWall-1 weakness?
daemon@ATHENA.MIT.EDU (Rosner, D)
Tue Oct 5 14:14:28 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <003201bf0e99$612cbbd0$7303010a@kinderhook.com>
Date: Mon, 4 Oct 1999 14:50:51 -0400
Reply-To: BUGTRAQ@ROZZ.COM
From: "Rosner, D" <BUGTRAQ@ROZZ.COM>
X-To: Hugo.van.der.Kooij@CAIW.NL
To: BUGTRAQ@SECURITYFOCUS.COM
FYI - I was reading about the JavaScript protection in the FireWall-1
product. I assume that the same malicious attack indicated in the Hotmail
thread would pass through the FireWall-1. Do not have the facilities to
check this from my location. I would suspect that
"javasCript:alert('JavaScript is executed')" could pass through.
Thanks.
> -----Original Message-----
> From: Hugo.van.der.Kooij@CAIW.NL [mailto:Hugo.van.der.Kooij@CAIW.NL]
> Sent: Thursday, September 30, 1999 1:58 AM
> 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!
>
