Vincent J. Ohm
April 5, 2004
CS265 Section 2
Project - Report

	The Vulnerabilities of Network Firewalls

	The “guard”, the “secretary” and the “bouncer”, these are a sample of the analogies of the trusted network security component, the firewall.  A firewall is a program designed to filter inter-network communications.  Their task may be simple in concept, but it is complex evidently by the existence and number of reported firewall vulnerabilities.  These vulnerabilities are due to either the overall design of the various firewall types, flaws in their implementation, or weaknesses from programs and protocols from other OSI Stack layers.

	There are a number of different types of firewalls, each designed for a specific purpose.  The Packet Filter scans the network layer data of a packet.  The Stateful Packet Filter is an extended implementation of a Packet Filter.  Which is capable of monitoring the state of active connections.  For example, an incoming FTP connection would not appear suspect if the firewall has a record of a client sending an FTP request to the same server.  An Application Proxy is designed to filter out potentially malicious application-specific data.  Finally, there are Personal Firewalls, which are a combination of the previously mentioned types and is home user oriented.

	The Packet Filter scans the network layer data of a packet.  This data includes the IP addresses and ports of both the source and destination of the packet.  This type of firewall can filter out packets coming from or going to specified IP addresses or port numbers.  The Stateful Packet Filter can perform the same tasks the Packet Filter can on both UDP and TCP traffic.  Since both types have similar filtering functions, then they have similar design-based vulnerabilities.  These firewall types are not designed to block certain packets based on their payload.  Attacks exploiting application flaws through permitted ports and addresses would not be blocked.  An Application Proxy scans through the data segment of the packet.  The proxy scans the data for potentially malicious content harmful to the application it is intended for.  This datastream includes spreadsheets, documents and program commands.  Proxies can be designed to search for malicious viruses and scripts inside files and block users from using certain program commands.  Application proxies are capable of blocking most, if not all, known exploits of known application vulnerabilities.  They are, however, vulnerable to unknown, or unreported, application vulnerabilities and vulnerabilities in the firewall implementation itself.

	There exist network vulnerabilities that can go unchecked despite the presence of a firewall.  Networks are constructed according to an abstract layering model known as the O.S.I. Stack.  Successful communication through the network is dependent upon the intercommunication between every mechanism and protocol from the Physical Layer to the Application Layer.  Secure networks also depend on the security efforts of each layer.  For example, MAC address at the Data Link Layer and IP addresses at the Network Layer both lack any form of authentication.  Thus these addresses can be spoofed.  IP Spoofing, together with MAC Spoofing if necessary, can be used to engage in a spoof at the Transport Layer - TCP Spoofing.  At this layer, a randomly selected initial sequence number assists in enforcing an exclusive connection to a host.  IP address spoofing combined with a correct selected sequence number grants the attacker the same credentials, the IP address and sequence number, as the user (the victim) in order to use the connection.  The only difference between them is that they are different clients, usually.  Hence, a firewall can defend against this attack by applying a type of security protocol that can differentiate between the two - user-to-firewall encryption.  Encryption secures the integrity of the connection by forcing the attacker to acquire the encryption key before attempting the TCP spoof attack.

	Application vulnerabilities can be weaknesses in a network's security that do not originate from the firewalls themselves.  Firewalls may not be the vulnerable component, but they may be able to cover the security hole.  For example, an early incarnation of the program "sendmail" had an exploitable backdoor command.  This command 'WIZ' was intended to be used for debugging.  The command allows a client machine running sendmail to gain root shell access to the remote sendmail server.  If they allow access to the sendmail service, neither one of the packet filters would disallow this use of this command since they are not designed to scan the data stream.  An application proxy would block this command as long as it is programmed to block packets invoking it.  Application vulnerabilities are not flaws in the firewall implementation itself.  However, these vulnerabilities can impact the configuration of firewalls, until the vulnerability is resolved by a patch, halting the use of the application, etc.

	There are weaknesses in a network's security in which the firewall itself is at fault.  These vulnerabilites originate from the implementation flaws of the firewall itself.  These weakness are naturally implementation-dependent.  Hence, there is no general "catch all" practice of protecting against them, except for contacting the vendor for a software patch or advice on workarounds.  As a note to the reader, the following vulnerabilities to be discussed are subjects of publicly accessible security advisories and each corresponding vendor has since released a software fix.

	An earlier version of the Symantec Firewall/VPN appliance may leak the Administration Authentication Password for the appliance itself.  When the administrator changes the password from an insecure machine (ie. terminals which do not require user authentication) the new password would be stored in cleartext within the local, insecure machine's browser cache.  Clearing the browser cache or changing the password from a secured terminal are manual methods for protecting against this vulnerability.  Symantec fixed this vulnerability by ensuring the password data is stripped from the HTML response.
	A version of the Pyramid BenHur Firewall has an active FTP vulnerability.  The firewall does not protect any host port the firewall itself, despite its configuration, when it receives a connection request with its source port set to 20 - the FTP data port.  This configuration would permit active FTP sessions from inside the network to hosts on the outside.  The Kerio Personal Firewall has a similar type of vulnerability.  In this case, however, the Kerio firewall's filtering rules could be bypassed if a received UDP packet has its source port set to 53 - the DNS port.  The default ruleset for this firewall allows any UDP traffic originating from port 53.  In this case, the default configuration intends to allow DNS responses to reach a client within the network.  However, this rule is too broad since it allows DNS responses and potential attacks using UDP.
	Cisco's PIX Firewall, a stateful packet filter, contains two vulnerabilities which can be exploited to cause Denial of Service attacks.  The first weakness can result with a crash and reboot of the firewall.  The crash occurs while it processes a SNMPv3 (Simple Network Management Protocol) message when the firewall is configured to be an SNMP host, even though the Cicso PIX Firewall does not support SNMPv3.  The firewall does not have a secure failure recourse when it receives a message from the unsupported protocol.  Hence, the unit reacts by crashing and automatically reloading.  The second vulnerability is present when the firewall is configured as a VPN Client.  It enters an unstable state when an IPsec client establishes a VPNC IPSec tunnel connection.  When another IPSec client attempts to initiate another IPsec connection to the VPN Client, the firewall may drop the other user's established IPsec connection.  Under certain conditions, the Cisco PIX Firewall is unable to support two IPsec connections as a VPN Client.
	Two firewalls, Check Point Firewall-1 and DeleGate's application proxy, both have a similar vulnerability, the overflow vulnerability.  Firewall-1's flaw is triggered when it receives an invalid HTTP request.  While the firewall generates an error message, a portion of the invalid URL is included a format string which is used in a call to sprintf().  This vulnerability can be exploited to either execute commands on the firewall, or exploited as a heap overflow and allow the execution of arbitrary code.  DeleGate's application proxy, when being used as a POP proxy, uses an array of fixed size to contain the username and password.  The bounds of the arrays are not checked and the firewall become exploitable when the arrays are the subject of a call to strcpy().  A specially crafted username or password can exploit this vulnerability and cause a buffer overflow which can lead to arbitrary code execution.
	The overall goal of this report is to dispel any myths about firewalls being invulnerable security enforcers.  Networks with deployed firewalls may still be susceptible to attacks that the firewalls are not designed to stop.  These networks may be exploitable by certain data that their firewalls are configured to let through.  Finally, implementation flaws with the firewalls themselves may pose a security threat.  Firewalls can be a network administrator's best friend, but a knowledgeable administrator should be aware of the weaknesses of firewalls along with the weaknesses of other security policy enforcers.

References
Kaufman, Charlie, & Perlman, Radia, & Speciner, Mike. (2002).
	Network Security: Private Communication in a Public World.

stateful packet filter: http://www.itsecurity.com/dictionary/dympack.htm
general firewalls: http://www.firetower.com/forum/applicationproxy.html

Kerio Personal Firewall
	http://www.securityspace.com/smysecure/catid.html?id=11580
	http://www.securityfocus.com/bid/7436
	http://secunia.com/advisories/8663/
Pyramid BenHur
	http://www.securiteam.com/securitynews/5WP0M0K7PS.html
DeleGate Application Proxy
	http://www.globalintersec.com/adv/delegate-2002012101.txt 
Cisco PIX
	http://www.cisco.com/warp/public/707/cisco-sa-20031215-pix.shtml
	http://www.cscic.state.ny.us/advisories/dec03/12_17.htm

Symantec Firewall/VPN Appliance
	http://www.symantec.com/avcenter/security/Content/2004.03.03a.html

Check Point Firewall-1
	http://www.us-cert.gov/cas/techalerts/TA04-036A.html