Multiple firewalls ruleset bypass through FTP. Again. (CERT VU#328867)

[Mikael Olsson <mikael.olsson () clavister com>]

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

-- 
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.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards