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:BUGTRAQat_private]On Behalf Of > Hugo.van.der.Kooijat_private > Sent: Wednesday, September 29, 1999 11:58 PM > To: BUGTRAQat_private > 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 > hvdkooijat_private 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! >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:23 PDT