A Stateful Inspection of FireWall-1



		    Thomas Lopatic, John McDonald

			TUV data protect GmbH

		       {tl,jm}@dataprotect.com



			       Dug Song

	    Center for Information Technology Integration

			University of Michigan

			  dugsong@monkey.org





1 Introduction

--------------



At the Black Hat Briefings 2000, we presented an analysis of Check

Point FireWall-1 vulnerabilities resulting from protocol design flaws,

problems in stateful inspection, common or default misconfigurations,

and minor implementation errors discovered over the past few months in

the lab, and verified in real-world penetration tests.



In this advisory, we summarize our findings and provide some

recommendations for safe configuration. It is intended to complement

our presentation slides and source code, available at:



	http://www.dataprotect.com/bh2000/



Our research was conducted against a Nokia IP440 running FireWall-1

version 4.0 Service Pack 5. Check Point later provided us with version

4.1 Service Pack 1, which was still vulnerable to most of the attacks

described here but came with a much safer default configuration.

Check Point has since released service packs for all supported

versions of FireWall-1 to specifically address the vulnerabilities

documented here.



2 Authentication

----------------



In the examination of any security product, the administrative control

channels are often the weakest link -- and the most security critical.

Indeed, we found that FireWall-1, in a typical distributed deployment,

was susceptible to several trivial attacks against its inter-module

authentication protocols.



Our attacks assume that the attacker has access to port 256/tcp on

the filter module, and knows the IP address of either a management

module or any peer for which a shared authentication secret has been

configured using ``fw putkey.'' In version 4.0, this port is exposed

to the world by default, as it is also used by SecuRemote clients.

In version 4.1, however, SecuRemote clients use port 264/tcp, with

access to 256/tcp restricted.



While only the management console is able to issue unload commands,

the binary load (bload) command is enabled by default for any IP address

that the filter module knows an authentication secret for. We were

able to verify this under version 4.0 by using binary load to upload

an ``allow all'' policy. Our attacks bypass authentication to issue

an unload command, which is easier to implement, and more portable

between versions.



2.1 IP Address Verification

---------------------------



In the inter-module authentication protocol, a filter module does not

verify the source IP address of an authenticating management module

by checking the peer address of a connection -- it examines a list

of IP addresses handed to it. A common misconfiguration is to put



	127.0.0.1: */none



in the control.map file, to ease local administration. An attacker

only needs to send 127.0.0.1 as her IP address to bypass authentication

completely, as demonstrated by our ``fw1none'' program.



After exchanging version and IP address information, the filter module

replies with the authentication it wants to be performed. Upon successful

authentication, the management module transmits the arguments for

the command to be executed. Finally the filter module returns a status

code to indicate whether or not command execution was successful.



The protocol is in general not strictly synchronous. In particular,

the exchange of IP addresses happens asynchronously, i.e. the management

module does not have to send its IP addresses first. It could just

wait for the filter module to send all IP addresses and then transmit

its own. In this way, an attacker acting as a management module may

learn all IP addresses of the firewall without actually authenticating.

This is useful for the encapsulation attacks discussed later, or in

discovery of a management module's IP address.



If we present an IP address to the filter module that does not correspond

to a management module -- or more generally speaking, an IP address

that it does not have an authentication secret for -- it will simply

refuse to authenticate. Hence we can scan for the correct IP address

of the management module by connecting repeatedly, giving a different

IP address (or list of IP addresses) each time.



2.2 S/Key

---------



S/Key authentication is used when communicating with embedded

FireWall-1 devices. It is also the fallback for version 4.0 filter

modules that do not have an encryption license and thus do not support

FWA1.



The problem with Check Point's S/Key implementation is that after a

shared secret has been used for 99 iterations, the management module

generates a new authentication secret using time(). The time() function

has a resolution of seconds. Therefore, there are only 24 * 3600 =

86400 different possibilities for secrets generated on a single day.

Even worse, if the status of the filter module is polled periodically

every 10 seconds, 99 authentications will be performed in a maximum

990 seconds. Working back from current time, we just have to try each

of the 990 possible values in the period from now to 990 seconds ago,

because we can be sure that a new shared secret has been generated

at least once during this period.



With our S/Key brute forcing program ``fw1bf,'' we are able to perform

about 50 guesses per second against FireWall-1 4.0 by using parallel

connections, covering a whole day of possible authentication secrets

in less than half an hour. Version 4.1 does not support as many parallel

connections, reducing our effective rate by an order of magnitude.



The S/Key authentication secret, once recovered, may be used with our

``fw1skey'' tool to issue an unload command to the filter module.



There is no encryption with S/Key authentication. Neither are there

any provisions for data integrity. Internal threats like TCP connection

hijacking apply.



2.3 FWN1

--------



FWN1 is an alternative to S/Key, sometimes used at sites lacking an

encryption license for version 4.0 filter modules. It is the default

authentication method for OPSEC in version 4.0 and version 4.1.



Authentication is based on a shared secret K. This secret is needed

to sign data using a keyed hash. K is appended to the data and the

result is fed to a cryptographically secure hash function. The resulting

digest is used as a signature. The peer, who also knows K, is able

to verify the signature by calculating the same keyed hash.



The original value for K is set using ``fw putkey.'' However, after

the first authentication, a Diffie-Hellman key exchange is initiated,

resulting in a new shared 1024 bit secret K for authentication.



The FWN1 protocol works as follows:



1. The filter module generates a random number R1.



2. The filter module signs R1. The signature S1 = Hash(R1 + K), where

   '+' denotes concatenation.



3. R1 and S1 are sent to the management module.



4. The management module verifies S1.



5. The management module generates a random number R2.



6. The management module calculates the corresponding signature S2 =

   Hash(R1 + K), where '+' is concatenation again.



7. R2 and S2 are sent to the filter module.



8. The filter module verifies S2.



This protocol is trivially defeated by a simple replay attack. Instead

of generating our own R2, we can just reuse the value R1 sent by the

filter module. Then, we can also reuse the signature S1, instead of

having to generate our own S2.



Our ``fw1fwn'' utility implements the unload command with FWN1 authentication.



There is no encryption with FWN1 authentication. Neither are there

any provisions for data integrity. Internal threats like TCP connection

hijacking apply.



2.4 FWA1

--------



FWA1 is similar to FWN1, with the addition of encryption to the

communication between the modules. This is the default mechanism used

in version 4.1, and for most commands in version 4.0 when an

encryption license is present.



Again, there is a shared secret K, initially set using ``fw putkey.''

After the first successful authentication, it is replaced by a 1024

bit value resulting from a Diffie-Hellman key exchange.



The FWA1 protocol works as follows:



1. The filter module generates a random number R1.



2. The filter module signs R1. The signature S1 = Hash(R1 + K), where

   '+' denotes concatenation.



3. R1 and S1 are sent to the management module.



4. The management module verifies S1.



5. The management module generates a random number R2.



6. The management module calculates R3 = R1 ^ R2, where '^' denotes

   XOR.



7. The management module calculates the corresponding signature S2 =

   Hash(R3 + K), where '+' is concatenation again.



8. R2 and S2 are sent to the filter module.



9. The filter module verifies S2.



Hence, the only change from FWN1 authentication is that instead of

signing R2, the management module signs R3 = R1 ^ R2. Again, this

protocol is trivially defeated with a simple replay attack. We just

choose R2 to be zero. In this way R3 = R1 ^ R2 will yield R3 = R1

and we can again reuse the filter module's signature.



The ``fw1fwa'' utility implements FWA1 authentication. However, the

unload command cannot be issued, as encryption is used to protect

the communication channel.



We have simplified our presentation of the FWN1 and FWA1 authentication

algorithms a bit for the sake of clarity. In practice, only 64 of

the 128 bits of the signature are transmitted. In FWA1 the remaining

64 bits of S1 and S2 are concatenated to form the 128 bit encryption

key. Since S1 = S2 in our attack, we would have to guess the 64 bit

encryption key to successfully issue an unload command. There may

still be a more sophisticated and practical way which has yet to be

investigated.



If the shared 1024 bit secret generated by the Diffie-Hellman key exchange

turned out to be guessable by a practical brute force attack because

of a lack of entropy, we would perhaps be able to find a relatively

small set of candidate values for K by brute forcing based on R1 and

S1. Then we could try all candidate values for K to find the real

K. To identify the real K, we could use the known plaintext of the

``authentication successful'' reply that we receive, which is already

encrypted.



To date, we have not come up with a practical attack on the complete

FWA1 protocol, including encryption. Still, the authentication mechanism

is seriously broken.



FWA1 uses the proprietary stream cipher FWZ1, recently posted anonymously

to the Usenet sci.crypt newsgroup. Unfortunately, even a simple command

like unload needs at least 18 bytes of arguments. Moreover, a different

key is used in either direction, confounding any known plaintext attacks

against the ``authentication successful'' reply.



There are no provisions for data integrity in FWA1. Internal attackers

are able to flip bits in a connection between two modules by simply

XORing the ciphertext C with a corresponding bit mask X, since the

decrypted plaintext P = C ^ K, where K is the key stream and '^' denotes

XOR. Decryption of C ^ X would thus yield (C ^ X) ^ K = (C ^ K) ^

X = P ^ X.



3 Packet Filtering

------------------



Static packet filtering is perhaps the simplest mechanism for network

access control, but also deceptively hard to implement correctly. We

found FireWall-1 to be susceptible to a number of attacks based on

incomplete input verification, including some that allowed for attacks

against stateful inspection as well.



3.1 TCP Fastmode

----------------



FireWall-1 provides a mechanism known as ``fastmode'' to allow an

administrator to designate certain services as being performance

critical. The FireWall-1 kernel module simply passes packets that have

a source or destination port of a fastmode service without any

additional connection or rule base checking.



Additionally, in fastmode, only SYN packets are verified. This allows

an attacker to pass non-SYN TCP packets through the firewall to map

the network by setting the source port of her packets to that of the

fastmode service. We demonstrated mapping a network using the -g and

-sF options in nmap.



3.2 FWZ Encapsulation

---------------------



FireWall-1's simple tunneling protocol for SecuRemote connections

proves extremely useful in bootstrapping insertion attacks against

stateful inspection. This protocol (FWZ tunnelling via IP protocol 94)

is decapsulated at the very beginning of pre-inspection, before any

real analysis is performed. The decapsulated packet is then fed

through the inspection process. It is not necessary to authenticate or

encrypt packets in order to use this encapsulation protocol.

Furthermore, we could find no way to disable this functionality,

short of filtering IP protocol 94 with another device.



An ordinary IP packet is FWZ encapsulated as follows: the original

destination IP address and protocol are appended as a trailer to the

end of the packet, and replaced in the original header by the target

IP address (one of the firewall's interfaces) and IP protocol 94.

The trailer, five bytes in length, is obfuscated via XOR with a keyed

hash on the IP ID. While we didn't recover the key used in the hash,

our tools cheat by fixing the IP ID to one and XORing against a static

hash.



In this manner, FWZ encapsulation may be used to send packets through

the firewall that would otherwise be unroutable, such as packets from

the DMZ or intranet to the Internet, packets destined for a multicast

address, or packets to addresses behind NAT or on RFC 1918 private

networks.



3.3 IP Spoofing Protection

--------------------------



IP spoofing protection on FireWall-1 is configured per network object

at the interface level. Several options are possible, but the typical

configuration looks something like this:



1. DMZ and intranet interfaces set to ``This Net'' or perhaps ``This

   Net +'', restricting valid source IP addresses on the interface

   to those directly on its network, or routable to its network.



2. External interface set to ``Others'', disallowing packets purporting

   to originate from any of the DMZ or intranet networks.



While this configuration seems simple enough, it leaves out spoofing

protection for one important IP address -- the external interface of

the firewall. Denial of spoofed packets coming from firewall

interfaces is apparently enabled by default in all versions of

FireWall-1 other than version 4.1 Service Pack 1. Coupled with the

default rule to allow ISAKMP packets, this hole allows an attacker to

send any UDP datagram to the external firewall interface.



Another possibility for evading IP spoofing protection is to use the

all-hosts multicast address (224.0.0.1) as a mechanism for delivering

packets to the underlying operating system of the firewall. For our

demonstration, we used FWZ encapsulation to spoof a packet from the

multicast address to our attack host, allowing us to respond with a

packet sent to the multicast address, passed on to the firewall

itself. This attack can also be performed with broadcast addresses.



4 Stateful Inspection

---------------------



Stateful inspection firewalls try to enforce certain semantics in the

traffic they relay. The mechanisms used to accomplish this, however,

are often incomplete or subject to simple insertion or evasion, bearing

some similarity to the problems encountered in passive network monitoring.



FireWall-1's stateful inspection is vulnerable in a number of ways

related to layering violations in inspection, and ambiguity in end-to-end

semantics. Many of these attacks rely on misconfiguration of IP spoofing

protection, or leveraging other mechanisms, such as FWZ encapsulation,

for insertion.



4.1 FTP Data Connections

------------------------



4.1.1 FTP PORT

--------------



FireWall-1's FTP processing tries to restrict the destination of FTP

data connections to the FTP client associated with the control connection,

preventing the classic FTP bounce attack. In previous versions of

FireWall-1, this was trivially bypassed by splitting up the PORT command

over multiple packets, or even by spelling ``PoRT'' in mixed case

for version 3.0. However, with the latest checks imposed by FireWall-1

to restrict one FTP command to a packet, bypassing this becomes a

little more difficult.



In our presentation, we demonstrated an ambiguity in the parsing of

the PORT command that allows us to bypass this restriction. FireWall-1

takes each octet of the presented IP address as a long integer, shifts

it the appropriate number of bits and then adds it to its notion of

the IP address. However, the FTP server we targeted on Solaris 2.6

interprets each octet of the IP address modulo 256. This difference

allows us to trick the firewall into believing the connection is destined

for the correct client IP, while the FTP server believes the connection

is destined for itself.



The attack we demonstrated was against the ToolTalk RPC daemon. We

uploaded two files to the FTP server in a publicly writable directory,

and then instructed the FTP daemon to upload those files to its own

ToolTalk daemon port with a carefully crafted PORT command. The first

file was necessary to kill the daemon, and the second file was the

buffer overflow, as generated by the ToolTalk exploit by apk.



We also demonstrated utilizing FWZ encapsulation to spoof a FTP control

connection packet from our victim machine to our attacking computer.

The payload of this packet was a PORT command, which the firewall's FTP

stateful inspection module interpreted as a legitimate data connection

that needed to be passed through the firewall.



4.1.2 FTP PASV

--------------



We originally intended to disclose this attack at our presentation,

but it was independently discovered and published by Mikael Olsson

to VULN-DEV. This vulnerability can be referenced under CVE-2000-0150.



FireWall-1 violates a basic layering abstraction in its inspection of

TCP application data within discrete IP packets, allowing for a simple

insertion attack. We can leverage the quoting of client input in an

FTP server's error messages and the client-side configuration of TCP

connection parameters to trick the firewall into allowing arbitrary

data connections for PASV replies we generate ourselves.



To demonstrate, we used our ``ftp-ozone'' tool to open up a direct

connection to the ToolTalk daemon on the FTP server, allowing us to

execute a buffer overflow attack.



4.2 Simplex TCP Connections

---------------------------



A connection in FireWall-1's connection table may be flagged to

restrict data flow to one direction (One-Way versus Either-Way). The

first packet containing TCP data establishes the direction of the

connection, and any data travelling in the other direction will cause

the connection to be dropped from the connections table. In versions

of FireWall-1 prior to 4.1, the check for data only considered the

first fragment in a series of fragmented packets. Thus, it was

possible to bypass this restriction by sending a TCP data packet in

two IP fragments -- the first containing the TCP header, the second

containing data (a variation on the tiny fragment attack against

static packet filters).



Check Point corrected this in the latest version, but there is still

another way to bypass it. It is important to note that the firewall

does not attempt to tear down the connection; it only removes its

entry in the connection table and drops any subsequent packets. As

FireWall-1 doesn't verify TCP sequence numbers, it is possible to

re-establish the connection with the same source and destination

parameters, allowing for retransmission of the previously dropped TCP

data to set a new direction for the connection, passing the data back

through the firewall. To exploit this, a small program running in an

infinite loop that constantly re-opens the FTP data connection can be

used to leak the return data through, although somewhat inefficiently.



4.3 RSH stderr

--------------



RSH is another protocol that permits an insertion attack to allow

back-connections through the firewall, in the same manner as the

previous FTP PORT exploit. This requires a legitimate RSH client

inside the firewall, with the firewall configured to allow RSH/REXEC

stderr connections (a simple policy box check, without any rules

required for RSH in the rulebase).



RSH stderr connection handling also presents a problem in its

management of connection state. Although we are unable to exploit this

vulnerability in versions 4.1 and later, we decided to leave the

discussion of it in our presentation as it nicely illustrates some of

the state-tracking mechanisms FireWall-1 uses internally.



When FireWall-1 sees the first SYN of an RSH or REXEC connection, it

records the source address, source port, destination address, a magic

number, and the TCP sequence number + 1 into the pending table. It

records this information so that it can recognize the first packet of

the connection that contains data. When the first data packet of the

RSH connection is passed by the firewall, its entry in the pending

table is replaced with a new one, containing the source IP address,

the error port (extracted from the TCP payload), the destination IP

address, the same magic number, and the IP protocol. Upon intercepting

the first SYN for an error connection, the firewall checks its

parameters against the entry in the pending table, and adds the

connection to the connections table.



An exploitable collision exists in the use of the pending table. If

we provide an initial sequence number of five, it is incremented to

six in the pending table -- identical to the entry created by the

first-packet handling code. Thus, by spoofing a SYN from an intranet

or DMZ machine with an ISN of five, with the source port of the host

that we wish to access, the destination IP address of our attacking

machine, and the destination port of the RSH service, an entry is

added to the connections table allowing us to connect from our machine

to the ``RSH client'' on whatever port we specify.



In version 4.1, the problem is not exploitable due to the fact that

the initial SYN packet is not passed, as certain additional flags

are missing from our manufactured pending table entry.



4.4 UDP Replies

---------------



A default installation of FireWall-1 4.0 allows DNS traffic between

all hosts. When combined with lax IP spoofing protection, this rule

allows us to spoof UDP datagrams from the DMZ or intranet to our attacking

machine. If UDP responses are allowed, we can reply to those packets

-- in effect allowing us to talk to any UDP service behind the firewall.



Our demonstration consisted of an attack against the SNMP daemon on

the target Solaris 2.6 machine. Using the ``tun'' tool, we sent an

FWZ encapsulated datagram to the external interface of the firewall,

which upon decapsulation, appeared to originate from the SNMP service

on the internal victim, destined for our attacking host's port 53/udp.



This allowed us to respond to our ``DNS request'' with arbitrary packets

destined for the target's port 161/udp. It would follow that our source

port should be 53/udp, but this isn't actually necessary because of

the way UDP replies are implemented.



5 Recommendations

-----------------



5.1 Non-reliance on NAT

-----------------------



As mentioned above, FWZ encapsulation can be used to send packets through

the firewall that would otherwise be unroutable. This includes packets

destined to addresses behind NAT or on RFC 1918 private networks.

For instance, in FireWall-1's default configuration, an attacker can

access DNS servers in the intranet or DMZ directly, due to the ``allow

all port 53'' rule. If the ICMP ``allow all'' rule is enabled, an

attacker can map any intranet or DMZ subnets.



NAT and non-routable addresses do not necessarily provide any inherent

security. While FWZ encapsulation is specific to FireWall-1, similar

attacks using other VPN encapsulation techniques may be more widely

applicable -- GRE, IP protocols reserved for IPsec, and even IPv6

tunnelling in IPv4.



5.2 Configuration

-----------------



A few simple rules of thumb:



1. Be sure to run the latest version of FireWall-1 possible.



2. Disable implicit rules, including those for DNS, administrative control

   connections, and ICMP.



3. Be as specific as possible in defining rules -- no ``any'' source

   or destination IP addresses, deny multicast / broadcast addresses, etc.



4. Enable IP spoofing protection on all interfaces.



5. Pre-filter IP protocol 94 (e.g. with IP Filter or some other mechanism).



6. Separate virtual IP addresses for public services.



7. Use only FWA1 authentication for now.



5.3 Patches

-----------



Check Point released patches to address these problems in time for our

presentation at the Black Hat Briefings. Current service packs,

hotfixes, and alerts are available at:



	http://www.checkpoint.com/techsupport/



6 Acknowledgments

-----------------



We would like to thank Check Point for their timely, thorough response

to our independent security review, and for their exceptional

professionalism in dealing with these issues.