Checkpoint-1 and other firewall vulnerability - The low-down of it is fooling a firewall into opening "a TCP port of your choice" against an FTP server. Or, if you're running an evil FTP server, having it open ports against clients accessing the server.
d3c08340f210729ab1830b529790957de036e964233c20d7dcad334c181bc68a<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<BODY BGCOLOR="#000000" TEXT="#FFFFFF"><PRE>
<FONT COLOR="#CC0000">COMMAND</FONT>
Firewall-1
<FONT COLOR="#CC0000">SYSTEMS AFFECTED</FONT>
Firewall-1
<FONT COLOR="#CC0000">PROBLEM</FONT>
Following text by Mikael Olsson will be used as introduction for
something more by John McDonald. The low-down of it is fooling a
firewall into opening "a TCP port of your choice" against an FTP
server. Or, if you're running an evil FTP server, having it open
ports against clients accessing the server.
There are several "flaws" and assumption in this idea, so it is
likely to NOT work with several FTP servers and firewalls. On
the other hand, it might work with some. Now, the idea.
Assume we're accessing an FTP server that is protected by a
firewall of some kind. The firewall is monitoring our command
channel, port 21, for "PASV" messages sent by the server. Upon
receipt of such messages, it will open a channel to the port
number specified in the message. Now, what if we'd be able to
send fake "PASV" message to the server, and have it echo them out
through the firewall? We'd be able to access arbitrary TCP ports
on the FTP server. (23, 139, 6000?)
Breaking through a stateful inspection FTP ALG
----------------------------------------------
One if the ideas has to do with stateful inspection firewalls.
Most of them don't reassemble the connection completely, but
rather trust that the FTP server will send the "PASV" message as
the first string in a new packet - this is usually what will
happen? What if we "get" a file called
<FONT COLOR="#00FF00">
AAAAAAA[about 100 A]AAAAPASV 123, 123, 123, 123, 0, 139
</FONT>
where "123, 123, 123, 123" is the public address of the FTP
server. It is somewhat likely that the FTP server will send us
an error message stating that this file name is illegal. Now,
WHAT if we were to decrease the TCP MSS in this connection (easily
done) to something like.... 100 bytes?
Wouldn't we be able to calculate just how many 'A's we'd have
to add to the beginning of the file name until the "PASV" command
becomes the first string in the packet following the error message
with all the 'A's ?
Wouldn't the firewall then obey our fake PASV command that the
server just echoed for us? Of course, you might get lots of
garbage after the echoed PASV command, like a trailing quote
and maybe bits and pieces of the error message. But that
might not matter (assuming that the firewall simply does
something along the lines of sscanf() to get the parameters after
having found the "PASV" text in the beginning of the packet).
This all assumes that the firewall isn't completely reassembling
the stream, but rather looking at the contents of individual
packets.
Breaking through a "proxy" FTP ALG
----------------------------------
There's another case here, and that is where the firewall
completely reassembles the TCP stream before analyzing it. Call
it a "proxy", call it whatever. This is a LOT harder, but it
could maybe work with some FTP servers?
You'd have to be able to coax the FTP server into sending
multiple lines (CRLF terminated) in order to have it look like a
real PASV command. You might also have to mimic a legitimate GET
request from the client before having the firewall accept the PASV
command from the server. As said, this is nowhere near easy, but
someone will come up with an FTP server that can be coaxed into
doing this, and a way to fool the firewall.
Breaking through to a client
----------------------------
This is not as feasible an attack. You'd have to have an FTP
server of your own, and make people connect to it. (As if this
can't be done by mailing HTML mail to people containing an IMG
SRC pointing to an FTP location?) Anyhow, applying all the theory
above with different types of firewall, it ought to be possible to
make the client echo bogus "PORT" commands, which the firewall
would interpret and result in ports being opened through the
firewall.
This is nowhere near as likely as the server cases above. It is
a lot more likely that you might coax a server into echoing
things than fooling a client into echoing things.
Btw, another thing about the server cases above. If the firewall
accepts any IP address in the PASV command from the server, not
just the address of the FTP server itself, you might be able to
fool the firewall into opening holes to pretty much any server
and port behind it (long shot).
John McDonald based on above added following. The basic idea of
the described attack is to subvert the security policy implemented
by a stateful firewall. This is done by triggering the generation
of a TCP packet that, when inspected by the firewall, will change
the firewall's internal state such that an attacker is able to
establish a TCP connection to a filtered port through the
firewall. This packet is the server response to a PASV user
request during a FTP session. He has also come across this
attack, and were in the process of preparing a more comprehensive
advisory, including other FireWall-1 security issues he has
documented. The idea was to notify Check Point of these problems
and give them time to develop a software update. However, since
the general form of this vulnerability was independently
documented by Mikael Olsson he did that earlier that planned.
Check Point FireWall-1 is vulnerable to an attack involving the
stateful support for the FTP protocol, specifically the handling
of the PASV command. Typically, a user will send an FTP server
the PASV command, and the response from the FTP server will be
the 227 message specifying to which destination IP address and
destination port the client is expected to connect for the next
data connection.
FireWall-1 monitors the packets sent from the FTP server to the
client, looking for the string "227 " at the beginning of each
packet. Upon a match, FireWall-1 will extract the destination IP
address and the destination port given in the packet payload,
verify that the specified IP address corresponds to the source
address of the packet, and allow an incoming TCP connection
through the firewall according to the destination IP address and
the destination port extracted from the datagram.
There are several restrictions on this connection which limit its
utility. Data can only travel in one direction and it cannot be
to a port that is listed in FireWall-1's list of well-known TCP
services. It is important to note that FireWall-1 version 3 does
not have this limitation, connections can be made to any port, and
the flow of data is not managed.
In order to trick FireWall-1 into allowing a connection to a port
on the FTP server, we must have the server send the "227 " string
as the first four bytes in a packet that, according to its source
port, belongs to a FTP control connection. We can typically
accomplish this by using the error handler of the FTP daemon,
in conjunction with limiting the MSS of our TCP connection.
This is easy to do by setting the MTU of our interface to a small
value we can work with, before we establish a control connection
to the victim FTP server. This causes the return packets from
the server to be smaller, allowing us to control more easily how
data is split into packets. Thus, we can make the "227 " message
returned by the error handler appear at the beginning of a packet.
Another way to accomplish this would be to ACK up to the message
we want to receive, and then have the server retransmit the data
we want to be contained in an isolated packet.
Here is an example of an attack based on this technique. There is
a FireWall-1 machine between gumpe and the 172.16.0.2 server,
which only permits incoming FTP connections. 172.16.0.2 is a
default Solaris 2.6 install, with the Tooltalk Database
vulnerability. We send the datagram directly to the service's
TCP port, in spite of this port being blocked by the firewall.
Note that since there is no response expected, the one-way
restriction doesn't affect this attack.
All testings were done on a Nokia IPSO machine running FW-1
version 4.0.SP-4.
<FONT COLOR="#00FF00">
[root@gumpe /root]# strings hackfile
localhost
""""3333DDDD/bin/ksh.-c.cp /usr/sbin/in.ftpd /tmp/in.ftpd.back ; rm -f
/usr/sbin/in.ftpd ; cp /bin/sh /usr/sbin/in.ftpd
[root@gumpe /root]# /sbin/ifconfig eth0 mtu 100
[root@gumpe /root]# nc -vvv 172.16.0.2 21
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 21 (?) open
220 sol FTP server (SunOS 5.6) ready.
...........................................227 (172,16,0,2,128,7)
500 '...........................................
[1]+ Stopped nc -vvv 172.16.0.2 21
[root@gumpe /root]# cat killfile | nc -vv 172.16.0.2 32775
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 32775 (?) open
sent 80, rcvd 0
[root@gumpe /root]# nc -vvv 172.16.0.2 21
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 21 (?) open
220 sol FTP server (SunOS 5.6) ready.
...........................................227 (172,16,0,2,128,7)
500 '...........................................
[2]+ Stopped nc -vvv 172.16.0.2 21
[root@gumpe /root]# cat hackfile | nc -vv 172.16.0.2 32775
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 32775 (?) open
sent 1168, rcvd 0
[root@gumpe /root]# nc -vvv 172.16.0.2 21
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 21 (?) open
id
uid=0(root) gid=0(root)
</FONT>
There is an easier way to perform a similar attack on this setup,
since the default Solaris FTP daemon allows a bounce attack, but
this should suffice to demonstrate the potential severity of this
problem.
So, if you have a FTP server behind a FireWall-1, it is possible
for an attacker to open TCP connections to certain ports on the
machine, and perform limited communication with those services.
If you are running FireWall-1 version 3, you should consider your
FTP server to have no TCP filtering. Solving this problem is
inherently difficult, but there are simple steps to take to
minimize this risk. If the machine is properly hardened, i.e. if
there are no services available on it, apart from FTP, this makes
this vulnerability have little significance.
Some proxy based firewalls have problems with this bug, and even
more so than packet inspecting firewalls. Proxy based firewalls
looks at the FTP protocol TCP stream and doesn't usually care
about packet boundaries. The reply from wuftpd STAT can be
forged to look like a seeminly valid FTP control reply.
<FONT COLOR="#CC0000">SOLUTION</FONT>
You can also disable the PASV handling in the FireWall-1 GUI.
However, this breaks your configuration for passive FTP clients.
So, proper hardening is some kind of solution, but not the
solution.
According to CheckPOint minimizing the possible threat:
<FONT COLOR="#00FF00">
- Do not enable PASV FTP if not needed
- Use the FTP Security Server or HTTP security server for PASV
FTP connections to internal FTP servers
- Those running publicly accessible FTP servers should follow
good host security practices (e.g., not running additional,
possibly unnecessary and vulnerable services, keeping up
with OS and/or application patches)
- For those using stateful inspection of passive FTP, the
following patch has been supplied
</FONT>
The patch consists of a new $FWDIR/lib/base.def file that includes
a fix to the problem (the file is compatible with Firewall-1 4.0
SP-5, other platforms will be released as soon as possible). The
fix involves an enforcement on the existence of the newline
character at the end of each packet on the FTP control connection,
this will close off the described vulnerability. It should be
noted that this may cause connectivity problems (i.e., blocked FTP
connections) in the following scenarios:
<FONT COLOR="#00FF00">
1. If FTP control messages larger than the MTU (e.g., large
PWD) are exchanged
2. If some FTP clients/servers does not put newline at the end
of the line
3. When passing FWZ encrypted traffic through an intermediate
Firewall gateway
</FONT>
The enforcement can be easily disabled by commenting the following
line in the base.def file (or by restoring the original base.def
file): #define FTP_ENFORCE_NL
The patch described above does not sound as though it will 'fix
the problem'. The enforcement of a newline at the end of the
packet might still open the possibility of exploitation through
at least few methods.
Even with the best firewall in the world, you need an ftp server
that implements the FTP protocol correctly before you have a hope
of handling PASV correctly.
</PRE></BODY>
</HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed