Issue: Firewalls that support FTP without fully reassembling the FTP
command channel can have their rulesets bypassed. Again.
Also documented as a CERT vulnerability note:
http://www.kb.cert.org/vuls/id/328867
However, the current revision (53) of the vuln note talks about SACK
options, which is inaccurate. No SACKs are used. [1]
Outline:
This attack resembles the techniques used in early 2000 in that it
forces the trusted point to output fake data channel commands in the
control channel, although the approach is slightly different.
This attack uses partial segment acknowledgement to cause the victim
to resend control strings supplied by the attacker, that a vulnerable
firewall will erroneously parse as a legitimate command.
It also theoretically bypasses some of the bandaids put in place
to protect against the attacks from 2000. Those attacks resulted
in packets in the command channel that weren't CRLF terminated.
This one doesn't.
Attacking a server on port 5000:
Attacker: Connect to FTP server and log on (anonymously?)
Attacker: "RETR 227 Connect to me at (192,168,0,10,19,136)\r\n" [2]
Server : "5xx No such file: 227 Connect to me at ([...])\r\n"
Attacker: Sends TCP ACK for the (here) 18 first bytes, i.e.
"5xx No such file: ", NOT the whole packet, which leaves
the "227 Connect to me" string lying in the send queue
of the server. This will soon be retransmitted:
Server : "227 Connect to me at (192,168,0,10,19,136)\r\n"
Note how all strings sent are properly CRLF terminated.
At this point, a vulnerable firewall will pick up the "227.." string
and open an inbound hole to port 5000 on the vulnerable system.
I specifically chose a private IP in the example, because this is
not a problem for the attacker: the firewall will handle address
translation and send back a string containing the public IP and a
different port. All one needs to do is connect to the public IP and
the given port, and you'll end up on port 5000 of the server.
This does however require that you know the private IP beforehand,
unless the firewall is unusually broken. A very broken firewall[3]
on the other hand might even allow you to open connections to systems
other than the FTP server itself.
Attacking a client on port 5000:
This requires getting the client to attempt to retreive a path of your
choosing. This is most easily done through a web page or HTML mail with
an appropriate URL / IMG SRC, e.g.:
<img src="ftp://evilserver.int/PORT 192,168,17,55,19,136">
and having the _server_ despool part of the incoming RETR request,
which would cause the client to send out "PORT 192,...".
Again, this depends on knowing the client IP beforehand, unless the
firewall is very broken and lets you open connections to any host
behind the firewall.
Note that the above depends on the fact that the victim TCP stack will
despool partial segments. Most do. I am currently only aware of one
TCP stack that doesn't: the TCP stack used in recent Linux kernels.
This means that Linux-based FTP servers/clients cannot themselves be
used to coerce the firewalls protecting them.
The above technique was cooked up by me, <mikael.olsson@clavister.com>,
and I would like to thank ICSA labs for taking the time to verify it
against their certified products in spite of me having no hard evidence
to support my theories.
In closing, this technique can very likely be abused for other protocols
that use ephemeral data channels, although I have personally done no
research in that area. Examples of such protocols (exploitable or not)
include but are not limited to: IRC DCC, SQL*Net, H.323, SIP, Real Audio,
etc ...
I should also mention that I have a sneaking suspicion that this can be
further extended/modified to affect some firewalls that were not
vulnerable to the first incarnation, so now is a very good time to get
a handle on those protocols in your networks.
Take care, all
/Mikael Olsson
PS. No proof of concept exploit. It's cumbersome enough to set up that
no sysadmin would do it, i.e. I'd only be helping the k1dd13Z.
--
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50 WWW: http://www.clavister.com
"Senex semper diu dormit"
[1] Also disregard the vendor reports from ftpd vendors. This is not
an attack against FTP daemons themselves. It attacks firewalls.
Also, note that some firewall vendors seem unwilling to add their
statements to the CERT vuln note. Call them and whine; many have
known about this since June.
[2] Note that the exact command used in attacking the server will vary
depending on FTP server.
Some servers echo the arguments of RETR commands in error messages.
Some servers echo the arguments of CHWD commands.
Some servers even echo the "user name" of USER commands.
[3] This was not tested; I do not know if there are such firewalls,
or if so, how many there are. It would indeed be "interesting"
to test this as well.
