A Stateful Inspection of FireWall-1

[blackhat () DATAPROTECT COM]

                 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.