SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Firewall)  >   FireWall-1/VPN-1 Vendors:   Check Point
Check Point FireWall-1 HTTP Proxy Bug Lets Remote Users Bypass Some Access Controls and Connect to Arbitrary Ports on Internal/Protected Hosts
SecurityTracker Alert ID:  1003600
SecurityTracker URL:  http://securitytracker.com/id/1003600
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Feb 19 2002
Impact:   Host/resource access via network
Exploit Included:  Yes  
Version(s): 4.1 SP5 (plus hotfixes)
Description:   An access control vulnerability was reported in Check Point's FireWall-1. A remote user can bypass access controls and connect to arbitrary ports on servers located behind the firewall via the HTTP Proxy.

A remote user can reportedly initiate a connection to an IP addresses and web port located behind the firewall. A common rule to allow this is:

"Any / WebServer / http->ressource"

Then, the remote user can apparenly apply the CONNECT method to connect to another server, different from the IP address originally specified in the connection. The remote user can reportedly connect to any port on that server, except for port 80.

For example, a remote user can use "telnet [webserver_address] 80" to attempt to connect to a protected webserver. The web server apparently does not need to actually exist, as long as a rule exists on the firewall to permit the type of connection. At the HTTP proxy menu, the remote user can reportedly enter the following to connect to a different protected server that the user is not authorized to connect to:

CONNECT [mail_server]:[arbitrary_port] / HTTP/1.0

This reportedly works if the rules are set to allow "Any Webserver http->ressource" and the following conditions are met:

1) The firewall module is allowed access (i.e. via policy/properties, specific rules or "Any (dst) (svc)..." rules
2) "CONNECT" is allowed. This is reportedly enabled if you allowed the "Tunneling" (General tab) connection method or did not delete the "*" in "Other" Methods (Match tab)

The author of the report credits Ryan Snyder for announcing this.

Impact:   A remote user can bypass access controls and access arbitrary ports on protected servers that the user is not authorized to connect to.
Solution:   No vendor solution was available at the time of this entry.

The author of the report has provided the following workarounds:

- Change your ressource settings to filter out CONNECT commands, i.e.
* disable HTTP tunneling
* check that "Other" method is specified NOT to match CONNECT (i.e. remove the default wildcard)
- disallow access from the firewall module (->Properties)
- replace in all your rules containing the service HTTP+Resource this part with plain HTTP. Yes, you lose some content security but at least you don't compromise your other servers

Vendor URL:  www.checkpoint.com/ (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  Linux (Red Hat Linux), UNIX (Solaris - SunOS), Windows (NT), Windows (2000)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Vendor Indicates That This is a Configuration Error, Not a Bug) Re: Check Point FireWall-1 HTTP Proxy Bug Lets Remote Users Bypass Some Access Controls and Connect to Arbitrary Ports on Internal/Protected Hosts
This is a follow-up message.



 Source Message Contents

Subject:  CheckPoint FW1 HTTP Security Hole


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings!

A quite known proxy vulnerability was found for FW1 V4.1 SP5 (plus
hotfixes) - thanks to Ryan Snyder for announcing the first bits on
Firewall-1 mailing list.

If you connect to a server you are allowed to connect to via HTTP
proxy (e.g. a common rule is "Any / WebServer / http->ressource").
Then use the CONNECT method to connect to a different server, e.g.
an internal mailserver.

Example:
	you = 6.6.6.666
	Webserver = 1.1.1.1
	Internal Mailserver = 2.2.2.2

	Rule allows:  Any  Webserver http->ressource

	connect with "telnet 1.1.1.1 80" to the webserver and enter
	CONNECT 2.2.2.2:25 / HTTP/1.0

	response: mail server banner - and running SMTP session e.g.
	to send SPAM from.

You can connect to any TCP port on any machine the firewall
can connect to. Telnet, SMTP, POP, etc.

Restrictions found:
	- connects are only possible if the firewall module
	  is allowed access (i.e. via policy/properties,
	  specific rules or "Any  (dst) (svc)..." rules
	- you have to allow "CONNECT" - is enabled if you allowed
	  "Tunneling" (General tab) connection method or did not
	  delete the "*" in "Other" Methods (Match tab)

Fast workarounds:
	- Change your ressource settings to filter out CONNECT
	  commands, i.e.
		* disable HTTP tunneling
		* check that "Other" method is specified NOT to
		  match CONNECT (i.e. remove the default wildcard)
	- disallow access from the firewall module (->Properties)
	- replace in all your rules containing the service
	  HTTP+Resource this part with plain HTTP. Yes, you loose

	  some content security but at least you don't compromise

	  your other servers


The thing that really concerns me is, that this general problem has
been known to be an issue with plain HTTP proxies like the Squid since
ages (see e.g. http://www.squid-cache.org/Doc/FAQ/FAQ-10.html#ss10.14).
And why didn't Checkpoint prevent or at least document this?

Puzzled
	Volker

- --

- -------------------------------------------------------------------
volker.tanger@discon.de                                 discon GmbH
IT-Security Consulting                           Wrangelstrasse 100
http://www.discon.de/                         10997 Berlin, Germany
- -------------------------------------------------------------------
PGP-Fingerprint: 5323 a4f7 a7c2 b8ef 4653 05ce d2ea 2b74  b94c c68e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32) - WinPT v0.0.3 (WINNT)
Comment: This is the WinPT config test

iEYEARECAAYFAjxyaZgACgkQ0uordLlMxo6yhQCeIzM/tWK3HCEVM/V816WSFpgh
YhMAoJX/uDKzPE1NKO9XKzizs3sxZWiW
=XumZ
-----END PGP SIGNATURE-----


 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC