COMMAND
FW-1
SYSTEMS AFFECTED
FW-1
PROBLEM
Following paper was written by Thomas Lopatic, John McDonald and
Dug Song. 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, authors summarize theirr 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/
Their research was conducted against a Nokia IP440 running
FireWall-1 version 4.0 Service Pack 5. Check Point later provided
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.
1 Authentication
================
In the examination of any security product, the administrative
control channels are often the weakest link -- and the most
security critical. Indeed, authors found that FireWall-1, in a
typical distributed deployment, was susceptible to several trivial
attacks against its inter-module authentication protocols.
Their 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. Authors were able to verify this under version 4.0 by
using binary load to upload an ``allow all'' policy. Their
attacks bypass authentication to issue an unload command, which
is easier to implement, and more portable between versions.
1.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.
1.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.
1.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.
1.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.
Authors 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.
Authors 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 attack, authors 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, authors 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.
2 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.
2.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. Authors demonstrated
mapping a network using the -g and -sF options in nmap.
2.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 authors 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.
2.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 demonstration, authors 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.
3 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.
3.1 FTP Data Connections
========================
3.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 authors presentation, they 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.
Authors 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.
Authors 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.
3.1.2 FTP PASV
==============
Authors originally intended to disclose this attack at our
presentation, but it was independently discovered and published
by Mikael Olsson. This vulnerability can be be found at:
http://oliver.efri.hr/~crv/security/bugs/Others/fw-14.html
FireWall-1 violates a basic layering abstraction in its inspection
of TCP application data within discrete IP packets, allowing for a
simple insertion attack. Authors 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 they generate themselves.
To demonstrate, they used our ``ftp-ozone'' tool to open up a
direct connection to the ToolTalk daemon on the FTP server,
allowing them to execute a buffer overflow attack.
3.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.
3.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 unable to exploit this
vulnerability in versions 4.1 and later, authors 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.
3.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,
authors 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.
SOLUTION
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.
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.
Check Point released patches to address these problems. Current
service packs, hotfixes, and alerts are available at:
http://www.checkpoint.com/techsupport/
Several of the referenced vulnerabilities rely on manually editing
the control.map file to weaken authentication. This kind of
reconfiguration is not and has never been recommended by Check
Point. Specifically, Check Point does not recommend using
"127.0.0.1: */none" in control.map; and FWN1 is not supported,
documented, or recommended as an alternative to the standard FW-1
inter-module authentication and encryption mechanisms (S/Key and
FWA1 are supported, and FWA1 is strongly recommended).
Check Point has released service packs VPN-1/FireWall-1 4.0 SP7
and VPN-1/FireWall-1 4.1 SP2 that eliminate each of these
vulnerabilities. For VPN-1 Appliances (IPSO) running version
4.0, the service pack is version 4.0 SP5 Hotfix.