('binary' encoding is not supported, stored as-is) Firewall-1 –HTTP Security Server - Proxy vulnerability Versions affected: Checkpoint FW-1 Version 4.1 and NG (confirmed by Checkpoint) Versions tested: Checkpoint FW-1 Version 4.1 (SP5 and SP6) Summary: When using an “out the box” installation of FW-1 with a rule base of: Source Destination Service Action Track AllUsers@SomeNet webserver http UserAuth Long Allow Auth HTTP Any firewall Any drop Long Stealth Rule Any Any Any drop Long CleanUp Rule Configuring the browser to proxy traffic as follows can enable a client browser to pass HTTPS and FTP traffic through the FW-1 enforcement point (even though only HTTP is allowed by the rule base): Type Proxy Address Port HTTP firewall 80 Secure firewall 80 FTP firewall 80 Detail: When using an action of UserAuth in Firewall-1 (even without using a resource), the traffic is handled by the Security Servers, in this case the HTTP Security Server (in.ahttpd). It appears that the default for the HTTP Security server is to allow any traffic that is proxied through the server (i.e. HTTP, HTTPS and FTP). If one specifically uses a URI Resource you are presented with the option to choose what Schemes (http, ftp, gopher, mailto, news, wais, Other) and Methods (GET, POST, HEAD, PUT, Other) etc you wish to allow. This option is not available for the HTTP service on its own. This same issue can be applied to an HTTPS service by following the instructions for Authenticating outbound HTTPS (See VPN-1/Firewall-1 Administration Guide page 504). This will enable an HTTP Security server on TCP:443. The client proxies are then set to Port 443 and the traffic is passed in this way. When using SP6, the behavior exhibited is slightly improved (due to the changes as outlined in the SP6 Release Notes (July 23, 2002). Under Known Limitations point 9, page 4. “The HTTP Security Server handles proxy and tunneled connection requests differently than earlier FireWall-1 versions…” With a default SP6 install, trying to access an HTTPS site via an HTTP only rule will fail, with an incorrect error message in the Log File, however FTP access still succeeds. Also, making the change (http_connection_method_tunneling (true) reverts the module to the SP5 (and earlier) behavior. Impact: Since the issue outlined above requires that a user be authenticated, the impact is likely to be small in most cases. However, certain installations may require that certain users be allowed restricted access to certain environments (such as DMZ’s etc). With the current default functionality in FW-1 the expected access restrictions are not going to apply. Solution: The only solution that comes to mind is to use Resources for ALL UserAuth rules and in this way have the ability to manually configure the required access and limit access for unwanted methods etc. When using a resource this “functionality” is disabled by default. Using the “Tunneling” “connection Method” in the resource can enable it. This requirement is enforced when running a fixed version from Checkpoint. Current Status with Vendor: Checkpoint have raised the following CR’s: CR00073948, for FireWall-1 version 4.1 SP6 CR00073595, for FireWall-1 version NG FP2 Checkpoint have developed a Hotfix to resolve this issue. The HotFix disallows client proxy connections to UserAuth rules which do not make use of resources by default. This behaviour can be overcome by manually changing options in the objects.C file. By: Mark van Gelder. Date: 18 September 2002
This archive was generated by hypermail 2b30 : Wed Sep 18 2002 - 16:21:43 PDT